Re: How do you interpret this code ?: Modified := Original + 1;



On 14 Mar., 01:12, "Skybuck Flying" <s...@xxxxxxxxxxx> wrote:
Hmm I compared Test1( Byte, Word ) and Test2( Word, Byte )

Same kind of code generated... except one is 8 bit and one 16 bit...

procedure Test1( const Original : byte; var Modified : word );
begin
Modified := Original + 1; // original 255, no problem.
end;

See this is actually where it gets interesting.
If I use Delphi to compile this function and call it with 255 as the
byte value, it returns 256 in the word.
But if I use my (16 bit) microprocessor Pascal compiler to do the same
- it returns 0 in the word.

At first I thought Delphi was wrong here so I spent a few minutes
reading through the Extended Pascal ISO document I had (rule 6.8.1
mentions operator precedence) but nowhere does it state if ":=" has or
has not precedence over other operators. In C, the assignment operator
"=" (equal to ":=" in Pascal) has the lowest precedence of all
operators except for things like "," thats not used in Pascal.

SO - a C compiler would translate this as
temp (byte) gets the value of original (byte) [255]
temp (byte) is increased by one [0]
modified (word) gets the value of temp (byte) [0]
My microprocessor compiler does the same. And this is what I would
expect from that function.

Delphi, though, translates this into
temp (word) gets the value of original (byte) [255]
temp (word) is increased by one [256]
modified (word) gets the value of temp (word) [256]

If assignments has to have any meaning, the ":=" operator must have
the lowest precedence. Play with paranthesis; the statement (a:=b)+1
has no meaning (equal to ":=" having precedence over "+"). But with
this assumption Delphi is wrong. The function must then return 0, not
256 as no 16 bit values exist before the assignment operator is used.

.



Relevant Pages

  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Which Delphi Version To Buy
    ... Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above? ... For example the basic data types processing in Delphi is sensibly superior to .NET's one exactly because is closer to the iron. ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... The vast majority of the games you have to deal with /different/ characters doing /different/ actions in parallel, responding each one to the stimuli which comes from the environment. ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)
  • D7 revival? stirring the old pot + Delphi 64 suggestion
    ... The new compiler, but with the old IDE, the old help. ... You can check other areas of the site and poster stats, it's not that Delphi posters don't use .Net, it's just that they don't use Delphi for .Net work. ... As for the 64bit debugging, a CPU view debugger would be all that is really needed to get things started (this is for fastcode after all), no need for rich source-level debugging, inspectors, etc. early on. ... Validation could be two-ways: one in the fastcode challenge, another made via CodeGear private unit tests. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... > Keep in mind that Delphi is one-pass compiler. ... > limits number of possible optimizations to ones that do not operate ...
    (borland.public.delphi.non-technical)