Re: x64 address indexed by 32-bit address

[wolfgang kern]

On 19/01/2024 14:42, Paul Edwards wrote:
> Hi.
>
> I am using a slightly modified GCC 3.2.3
> to generate x64 code, and using PDPCLIB
> and running under Linux x64.
...
> Now I have this code:
...
> printf("as negative is %x\n", p[-1]);

> which is generating (for that last line):
>
> LM1873:
>         movl    $4294967295, %eax
>         addq    -64(%rbp), %rax
>         movsbl  (%rax),%esi
>         movl    $LC445, %edi
>         movb    $0, %al
>         call    _printf

> That first instruction - the movl - has
> negative 1 as an unsigned value.

of course because it's just the lower part of RAX
where the upper part become zeroed by a move to EAX.

> I tried manually changing the generated assembler
> to $-1 but the result appears to be the
> same (I may have stuffed up the test).

you have to make RAX -1
XOR RAX,RAX
DEC RAX
but what's wrong with: DEC instead of ADD -1
__
wolfgang

[wolfgang kern]

need smaller part as index ?

BO FF AL=-1
48 0f be c0 MOVSXB RAX,AL
__
wolfgang

[Paul Edwards]

On 30/01/24 17:14, wolfgang kern wrote:
> you have to make RAX -1
> XOR RAX,RAX
> DEC RAX
> but what's wrong with: DEC instead of ADD -1

It is compiler-generated code. And not trivial
to change the compiler.

I managed to work around the problem by getting
it to make short/int/long 64-bit.

But then I replaced gcc itself with cc64 and have
a new solution.

BFN. Paul.

[wolfgang kern]

On 02/02/2024 09:12, Paul Edwards wrote:
...

>> but what's wrong with: DEC instead of ADD -1

> It is compiler-generated code. And not trivial
> to change the compiler.

it's well known that compilers rare produce wanted code.
many programmers add inline ASM or modify the gotten.

> I managed to work around the problem by getting
> it to make short/int/long 64-bit.

> But then I replaced gcc itself with cc64 and have
> a new solution.

this reminds me when I started programming PCs decades
ago with ROM BASIC and a bit later with Power-Basic.
I always had to scratch my back around seven corners to
achieve what I wanted.
After enough annoyed by all these delaying detours
which ended up in bloatware I started with inline ASM.
But this wasn't satisfying either because tools were
not aware of all possible code opportunity, so I had
to enter inline code byte by byte (aka DB 0x..).

this finally made my write my own tools and a whole OS.
while doing my tools I learned to code in HEX for almost
all CPUs popular back then [Zilog,Motorola,RCA,NSC,Intel]
__
wolfgang

[Paul Edwards]

On 30/01/24 17:14, wolfgang kern wrote:

>> movl $4294967295, %eax

>> That first instruction - the movl - has
>> negative 1 as an unsigned value.
>
> of course because it's just the lower part of RAX
> where the upper part become zeroed by a move to EAX.

It took me a while to realize this zero extension.
I was looking at code that looked like it should
be 64-bit but was seemingly 32-bit. I had to run
a testcase before I realized that the high 32 bits
were being zeroed.

Regardless, the original problem with the compiler
has been resolved (the way I was building it, I had
missed a define, so indexes were 32-bit instead of
64-bit), and with that resolved, and with a switch
to Win64 conventions, I now have:

D:\devel\gcc\gcc>type foo.s
.file "foo.c"
.text
.p2align 2,,3
.globl foo
foo:
.LFB1:
movsbl -1(%rcx),%eax
ret
.LFE1:

D:\devel\gcc\gcc>


And the compiler (now 64-bit pointers and 64-bit
long) is capable of self-recompilation.

And on my 32-bit Windows 2000 development environment
I can use it to produce 64-bit executables for my
Windows 10 host.

BFN. Paul.