Hi,
I was testing how bin arm-wince lcl applications are and wanted to test with
smartlinking.
First try: using LD as linker
This didn't work, because even if I do make rtl OPT="-CX", no lib*.a files are
created.
Second try: using internal linker, which presumably doesn't need the lib*.a fil
>
>
> Op Mon, 15 May 2006, schreef ???:
>
>> > Suppose you have an array of b. Then, with a size of 12, there would
>> be no
>> > guarantee that an access to b.ab is aligned. So, the compiler pads the
>> > record to a multiple of the largest field.
>> >
>> > Dani?l
>>
>> I didn't state
Op Mon, 15 May 2006, schreef ???:
> > Suppose you have an array of b. Then, with a size of 12, there would be no
> > guarantee that an access to b.ab is aligned. So, the compiler pads the
> > record to a multiple of the largest field.
> >
> > Dani?l
>
> I didn't state that it's
> Suppose you have an array of b. Then, with a size of 12, there would be no
> guarantee that an access to b.ab is aligned. So, the compiler pads the
> record to a multiple of the largest field.
>
> DaniКl
I didn't state that it's useless. It's just unexpected as it is.
The result is the same
Op Mon, 15 May 2006, schreef ???:
> b= record
> ab: int64;
> c: longword;
> end; // 12 expected
> writeln(sizeof(b)); // 16???
Suppose you have an array of b. Then, with a size of 12, there would be no
guarantee that an access to b.ab is aligned. So, the comp
On 5/15/06, Пётр Косаревский <[EMAIL PROTECTED]> wrote:
begin
writeln(sizeof(a)); // 12 ok!
writeln(sizeof(b)); // 16???
writeln(sizeof(c)); // 14 ok!
writeln(sizeof(d)); // 16???
writeln(sizeof(e)); // 12 ok!
end.
// I don't know the numbers on other platforms/systems
Linux, i386, FPC
It seems, that docs are outdated.
Default data alignment in records is expected to be wordly (i386, win32).
But if a record has int64 (or qword) element, I get unexpected overheads.
It's easily avoidable (with {$PACKRECORDS 1} or {$A1}; even with {$A-} [which
is expected to work only on MAC, ac
