Products > Programming

GCC ARM32 comparison question

<< < (8/8)

ataradov:

--- Quote from: SiliconWizard on June 18, 2022, 05:58:43 pm ---Have you read the rationale document posted by newbrain?

--- End quote ---
Is this for me? If so, yes, I've read this many years ago.

From my point of view, the best way to approach promotions is to allow only non-losing widening promotions. There is a good discussion on that here https://internals.rust-lang.org/t/implicit-widening-polymorphic-indexing-and-similar-ideas/1141

Prohibiting everything results in a lot of pointless castings and doing what C did results in a lot of confusion.

SiliconWizard:

--- Quote from: ataradov on June 18, 2022, 06:07:18 pm ---
--- Quote from: SiliconWizard on June 18, 2022, 05:58:43 pm ---Have you read the rationale document posted by newbrain?

--- End quote ---
Is this for me? If so, yes, I've read this many years ago.

--- End quote ---

No, sorry for not quoting the OP. That was for the OP.
And I'm again not saying that their decision was the right one, but at least we more or less know why C is defined this way.

Siwastaja:

--- Quote from: peter-h on June 18, 2022, 11:29:59 am ---- on CPUs which are mostly not natively int sized (most of the 8/16 bit stuff like the Z80 etc) it bloats a lot of stuff, and slows it down, a lot

--- End quote ---

Of course not! You still don't get it. C is not a "portable assembler". C is a high level language, with the concept of abstract C machine. Compiler is totally allowed to produce optimum code. Compiler only has to prove the result is correct, according to the standard. The problem is you thinking "optimization" as some separate step, as if programmer writes "portable assembler" first, then compiler translates it 1:1 to bloated code, and then optimizer trying to do something about it. It's not like this. Really, programmer gives high-level description of program, using standard language called C. Then compiler produces machine code, the only requirement being it must produce exactly the correct result. It does not matter how the compiler achieves this. Of course compilers try to do this in optimum way.

SiliconWizard:
Compilers build an abstract description of the source code before translating that to assembly.
Only in the very old and simple compilers both steps were more or less combined (like say, with the original Turbo Pascal compiler.)

nctnico:

--- Quote from: peter-h on June 18, 2022, 11:29:59 am ---OK, sure, but nobody answered my question :)

Except in terms of "it is the C standard, so accept it".

ISTM that this "promotion to int of almost everything shorter" is an attempt to prevent bad coding leading to what has since for ever been known in the embedded world (whether manually blowing fusible link PROMs one byte at a time, or asm, or C or whatever) as "integer overflow". The cost of doing this is

- on CPUs which are mostly not natively int sized (most of the 8/16 bit stuff like the Z80 etc) it bloats a lot of stuff, and slows it down, a lot

--- End quote ---
The designers of the C language already thought of that: the size of an int (integer) isn't fixed in C! On 16 bits CPUs an int is typically 16 bit. On 64 bit platforms an int usually is 32 bit.

Navigation

[0] Message Index

[*] Previous page