x64 address indexed by 32-bit address

[wolfgang kern]

Hi.
I am using a slightly modified GCC 3.2.3
to generate x64 code, and using PDPCLIB
and running under Linux x64.

...
...

printf("as negative is %x\n", p[-1]);
        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]

Post by wolfgang kern
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:
...

Post by Paul Edwards

Post by wolfgang kern
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.

Post by Paul Edwards
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]

Post by wolfgang kern

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.