On 19/01/2024 16:00, Paul Edwards wrote:

printf("argv[0] is %p %s\n", argv[0], argv[0]);
printf("len is %d\n", (int)strlen(argv[0]));
  p = argv[0] + strlen (argv[0]);
printf("p is %p\n", p);
printf("p as string is %s\n", p);
printf("p current is %x\n", p[0]);
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. I tried
manually changing the generated assembler
to $-1 but the result appears to be the
same (I may have stuffed up the test).

Try changing:

movl $4294967295, %eax
to:
movq $-1, %rax

So changing both operands and the opcode.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 16:24, Paul Edwards wrote:

On 20/01/24 00:16, bart wrote:

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

Try changing:

          movl    $4294967295, %eax
to:
          movq    $-1, %rax

So changing both operands and the opcode.

Apologies - I forgot to spell that out.

Yes, I fully expect full 64-bit values to work.

What I would like to know is how it was possible
for GCC 3.2.3 to generate x64 operating systems
back in those days.

ie how did this code ever work?

Bizarrely, it does work. I'm still trying to figure it out; I'll carry
on doing so.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 17:24, Paul Edwards wrote:

On 20/01/24 00:16, bart wrote:

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

Try changing:

          movl    $4294967295, %eax
to:
          movq    $-1, %rax

So changing both operands and the opcode.

Apologies - I forgot to spell that out.

Yes, I fully expect full 64-bit values to work.

What I would like to know is how it was possible
for GCC 3.2.3 to generate x64 operating systems
back in those days.

ie how did this code ever work?

Were operating systems back then restricted
via virtual memory to mask at the 4 GiB
mark to produce the required wrap or is there
something else I'm missing?

Thanks. Paul.

You've only posted bits of your code - try posting it all here. It's
quite possible that you've got undefined behaviour in your code, and
then you've no guarantees at all about what the compiler might do and
what might happen when you run it.

Also, why are you using such an ancient version of gcc? And what
changes did you make to it? If you want to test gcc versions and look
at the generated assembly, I recommend <https://godbolt.org> - though
the oldest gcc it has is 4.1.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul Edwards <mutazilah@gmail.com> writes:

LM1873:
movl $4294967295, %eax

This will _not_ be sign extended,

addq -64(%rbp), %rax

So instead of subtracting one from -64(%rbp),
it adds 4g. Bad generated code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 16:49, bart wrote:

On 19/01/2024 16:24, Paul Edwards wrote:

On 20/01/24 00:16, bart wrote:

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

Try changing:

          movl    $4294967295, %eax
to:
          movq    $-1, %rax

So changing both operands and the opcode.

Apologies - I forgot to spell that out.

Yes, I fully expect full 64-bit values to work.

What I would like to know is how it was possible
for GCC 3.2.3 to generate x64 operating systems
back in those days.

ie how did this code ever work?

Bizarrely, it does work. I'm still trying to figure it out; I'll carry
on doing so.

No, I made a mistake in my test assembly code. rax does get to a large
value.

Now, on x64, you can choose to use a 32-bit address mode so that the top
half of the address is ignored. But the bottom half will be
signed-extended, which I don't think will do it much good here.

Your (OP's) gcc code moreover uses a 64-bit address mode '(%rax)' not
'(%eax)'.

So it maybe it didn't work and was just a bug, that was fixed in a later release.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20/01/2024 15:37, Paul Edwards wrote:

On 20/01/24 00:55, David Brown wrote:

and thus run on UCX64, as it is unlikely
that cc64 can handle the gcc 3.2.3 code,
even though it is C90-compliant.

I wouldn't be able to build it anyway, with any compiler. It's one of
these hard-to-build jobs.

I've had a look at the sources, which include 7000 .c files and over
1000 .h files. But there is the usual configuration and makefile stuff
to navigate first, which will also general some of the header files needed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)