mORMot Open Source

Thanks. Perhaps if you also blogged about which patterns in DCC trigger the most weird code generation lapses, it also would be of benefit.

OTOH  i feel likeyou tend to "old school" programing, avoiding language features that missed from D5/D7 era... Delphi tries to be more high-level, and you have choses your own ground and don't move nether up nor down.

But how can it be that dynamic arrays would work correctly in Delphi ? I think we missed some details. What if we would just change the index?

SetLength(dmDBXSaveErr, 3);

{$T-} p_e := @dmDBXSaveErr;

{$T-} p_e := @dmDBXSaveErr[1];

{$T+} p_e := @dmDBXSaveErr[1];

{$T-} p_e := @@dmDBXSaveErr[1];

//remember? this compiles fine... or should i say "this at least compiles" ?
{$T+} p_e := @@dmDBXSaveErr[0];

// SUDDENLY! 
{$T+} p_e := @@dmDBXSaveErr[1]; // [DCC Error]  E2010 Incompatible types: '_PEventErr' and 'Pointer'

Type compatibility is different for 0th and 1st elements

CurrencyFrames.pas.681: {$T-} p_e := @dmDBXSaveErr[1]; 
0AB5EA85 8B45F4           mov eax,[ebp-$0c]
0AB5EA88 8B8060030000     mov eax,[eax+$00000360]      // so we're fetching the address of the 0th element....
0AB5EA8E 8B4008           mov eax,[eax+$08]                   // and screw it overwriting it by 1st element value
0AB5EA91 8945F8           mov [ebp-$08],eax

CurrencyFrames.pas.683: {$T+} p_e := @dmDBXSaveErr[1];  // same as above
0AB5EA94 8B45F4           mov eax,[ebp-$0c]
0AB5EA97 8B8060030000     mov eax,[eax+$00000360]
0AB5EA9D 8B4008           mov eax,[eax+$08]
0AB5EAA0 8945F8           mov [ebp-$08],eax

CurrencyFrames.pas.685: {$T-} p_e := @@dmDBXSaveErr[1];
0AB5EAA3 8B45F4           mov eax,[ebp-$0c]
0AB5EAA6 8B8060030000     mov eax,[eax+$00000360]    // so we're fetching the address of the 0th element....
0AB5EAAC 83C008           add eax,$08                          // and just correctly shift it to the next element!
0AB5EAAF 8945F8           mov [ebp-$08],eax                 // but as usual, to get a correct valuewe had to kill type safety :-/

Outcome of pointers math

{$T-}
  p_e := @dmDBXSaveErr;
  p_e := @@dmDBXSaveErr[1];

  p_e := @dmDBXSaveErr[1];
{$T+}
  p_e := @dmDBXSaveErr[1];



CurrencyFrames.pas.678: p_e := @dmDBXSaveErr;  {$T-}
092FEA3D 8B45F4           mov eax,[ebp-$0c]
092FEA40 0560030000       add eax,$00000360  // Correct result, but type-unsafe
092FEA45 8945F8           mov [ebp-$08],eax   

CurrencyFrames.pas.679: p_e := @@dmDBXSaveErr[1]; {$T-}
092FEA48 8B45F4           mov eax,[ebp-$0c]
092FEA4B 0560030000       add eax,$00000360  // Correct result, but type-unsafe
092FEA50 8945F8           mov [ebp-$08],eax    

CurrencyFrames.pas.681: p_e := @dmDBXSaveErr[1];  {$T-}
092FEA53 8B45F4           mov eax,[ebp-$0c]
092FEA56 8B8060030000     mov eax,[eax+$00000360]   // WRONG!!! Value instead of address! but "type-safe"
092FEA5C 8945F8           mov [ebp-$08],eax

CurrencyFrames.pas.683: p_e := @dmDBXSaveErr[1];  {$T+}
092FEA5F 8B45F4           mov eax,[ebp-$0c]
092FEA62 8B8060030000     mov eax,[eax+$00000360]    // WRONG!!! Value instead of address! but "type-safe"
092FEA68 8945F8           mov [ebp-$08],eax

Then i tried to address Watches window - it failed to calculate values like @dmDbxSaveErr[0] and
@@dmDbxSaveErr[0]   

I made one of the arrays dynamic - just to see if it counts - and suddenly Wathes started to work with both dynamic and static arrays

In XE2 assembler is screwed, sometimes it just inverts the logic in your code

http://qc.embarcadero.com/wc/qcmain.aspx?d=105876

and still not-fixed http://qc.embarcadero.com/wc/qcmain.aspx?d=105877

AFAIR that was not the case in C++

Sorry for bumping old thread.
I think lack of Unicode in Delphi was more vocal than wide request.

While it was pity, it is still too much exagerrated.
Those who needed it had Tnt, but when Tnt ceased and were sold out, were there developers to frk and continue TnT as free project ? no.
Maybe there was some large widget library, who choosed Tnt mechanics as a base to grow their large wiget sets unicode-aware ? no.
So, frankly, no one cared mostly.

1st version of Windows NT - NT 3.1 - was in 1993. It was not in 1999. If Delphi needed Unicode support - they could start as early as Delphi 2 release - but back then next to no one though about Unicode, every one though about RAM economy. It was RAM prices going down as well as obsoletion of Windows 9x/ME familiy and MS Unicode Services for Win98 that made Unicode a feasible "least common". And it was not until somewhere around 2005, that old Windows line-up could be completely forgotten.

Yes, Delphi is a bit late to jump onto Unicode train. But they did not planned to make two EXE's from same sources, ANSI and Unicode, they wanted one-time swtch. And they wanted all 3rd-party VCL ecosystem to switch as well. And it would rather not done too  early.

> KOL is not compatible with the IDE designer

KOL is not, but KOL-MCK is.
And KOL w/o MCK existed for very short time far far ago.

Last KOL release was yeas ago, but news on the site shows changes as recent as Feb 2012.
Though probably KOL-MCK is more ambitious and requires more work.

The problem maybe is that both projects are little known

But it's GUI is kinda spaghetti. Unreal Commander, having no need for backward compatibility, is sometimes easier and more straightlined to use.
Though in general TC seems to be more featured.

talking about performance, how would you like this ? good, it is legacy compatibility bridge. Pure insanity....

Main.pas.49: lblJvIPAddressValuesAddress.Caption := IntToStr(AddressValues.Address);
00563B20 8B45F8           mov eax,[ebp-$08]
00563B23 8945E0           mov [ebp-$20],eax
00563B26 8B45E0           mov eax,[ebp-$20]
00563B29 8945F4           mov [ebp-$0c],eax
00563B2C 8B45F4           mov eax,[ebp-$0c]
...
Main.pas.50: lblJvIPAddressValuesValue1.Caption := IntToStr(AddressValues.Value1);
00563B52 8B45F8           mov eax,[ebp-$08]
00563B55 8945DC           mov [ebp-$24],eax
00563B58 8B45DC           mov eax,[ebp-$24]
00563B5B 8945F0           mov [ebp-$10],eax
00563B5E 8B45F0           mov eax,[ebp-$10]
00563B61 8945D4           mov [ebp-$2c],eax
00563B64 8B45D4           mov eax,[ebp-$2c]
00563B67 BA04000000       mov edx,$00000004
....

> to handle CF in case of negative number
that means SHL - "*2". And only if range checking on.

In case of "div 2" CF would be oddity bit. IOW only need checking in "mod 2". Which probably be taken as "and 1". "Shr" 1 for "mod 2" or Odd(x) or Even(x) seems to be too clever trick for DCC.

Truly, i can't think of single practical use of CF after shift, that has any difference between signed and unsigned.

Also i ain't sure that CF is used at all for opcodes other than RCR/RCL. Just do not remember.
http://en.wikibooks.org/wiki/X86_Assemb … and_Rotate - this tells they are not, but i do not know how authoritative this source is. I remember well RCL but don't remember SCL at all. Though by logic it should exist for 64-bit integers in 32-bit mode and 32-bit integers in 16-bit one.

I have no access to Delphi 5 now, but at least i chanced to find respective line in XE2-produced 32-bit code.

TPoint is made of signed integers, isn't it ?

So, that's not just inconsistent but plain wrong :-)
Perhaps You've just forgotten {$O+} in DEBUG profile ?
Mmmm, in XE2 it still uses SAR even in $O- mode. If would not forget at spring should re0check in D5. I just can't believe in such inconsistency as a primary feature, not a bug in some particular compiler build.

i would not search for TurboPascal 5.5 or 7; and Virtual Pascal proves nothing here, but i feel like i saw SAR opcode in generated code.

Anyway, given that RTL/VCL strongly dislikes Cardinal and such, it must be EXTREMELY lame limitation to use SHR but not SAR

Is there QC on this ?