Hi Bart (or anyone else who may be able to figure it out).

According to this:

https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#callercallee-saved-registers

https://sourceforge.net/p/mingw-w64/wiki2/MinGW%20x64%20Software%20convention/#:~:text=There%20are%2016%20general-purpose%20registers%2C%20and%2016%20xmm,for%20gcc%20-%20Must%20be%20preserved%20by%20callee

rbx is meant to be preserved by the called function.

And some mingw-generated code appears to do exactly that:

0000000000000000 <xmalloc>:
0: 53 push %rbx
1: 48 83 ec 20 sub $0x20,%rsp
5: 89 ca mov %ecx,%edx
7: 48 89 cb mov %rcx,%rbx
a: 48 8d 0d 00 00 00 00 lea 0x0(%rip),%rcx # 11 <xmalloc+0x11>
11: e8 00 00 00 00 call 16 <xmalloc+0x16>
16: 48 89 d9 mov %rbx,%rcx
19: e8 00 00 00 00 call 1e <xmalloc+0x1e>
1e: 48 8d 0d 14 00 00 00 lea 0x14(%rip),%rcx # 39 <xmalloc+0x39>
25: 48 89 c3 mov %rax,%rbx
28: 48 89 c2 mov %rax,%rdx
2b: e8 00 00 00 00 call 30 <xmalloc+0x30>
30: 48 85 db test %rbx,%rbx
33: 74 09 je 3e <.L4>
35: 48 89 d8 mov %rbx,%rax
38: 48 83 c4 20 add $0x20,%rsp
3c: 5b pop %rbx
3d: c3 ret

You can see that it is checking rbx:

30: 48 85 db test %rbx,%rbx

after a call to printf.

Here is the C code:

void *xmalloc(size_t size)
{ printf("in xmalloc with %d\n", (int)size);
void *p = malloc(size);

printf("p is %p\n", p);
if (p == NULL)
{
printf("about to call fprintf\n");
fprintf(stderr, "Failed to allocate memory!\n");
exit(EXIT_FAILURE);
}

return (p);
}

Now printf is actually being resolved to eventually call cc64 code,
so I needed to mark printf as $callback, and that appears to have
been done successfully. But since it still didn't work, I took a look
at the assembler code I am using, and:

..globl m$pushcallback
m$pushcallback:
incd [ncallbacks]
xor rbx, rbx
mov ebx,[ncallbacks]
shl ebx,6 #8x8 bytes is size per entry
lea rbx,[rbx+callbackstack]

mov [rbx],rbx
mov [rbx+8],rsi
mov [rbx+16],rdi
mov [rbx+24],r12
mov [rbx+32],r13
mov [rbx+40],r14
mov [rbx+48],r15
ret

I can see that rbx is clobbered, not preserved!

I thought it might be separately preserved outside, but no:

0000000000000090 <printf>:
90: 55 push %rbp
91: 48 8b ec mov %rsp,%rbp
94: 48 83 ec 10 sub $0x10,%rsp
98: 48 89 4d 10 mov %rcx,0x10(%rbp)
9c: 48 89 55 18 mov %rdx,0x18(%rbp)
a0: 4c 89 45 20 mov %r8,0x20(%rbp)
a4: 4c 89 4d 28 mov %r9,0x28(%rbp)
a8: e8 00 00 00 00 call ad <printf+0x1d>
ad: 48 8d 45 10 lea 0x10(%rbp),%rax
b1: 48 8d 40 08 lea 0x8(%rax),%rax
b5: 48 89 45 f8 mov %rax,-0x8(%rbp)
b9: 48 83 ec 20 sub $0x20,%rsp
bd: 48 83 ec 20 sub $0x20,%rsp
c1: e8 6a ff ff ff call 30 <__gtout>

Now x64supb.asm is code I constructed myself, but it was
based on this:

m$pushcallback::
inc dword [ncallbacks]
mov A4,[ncallbacks]
shl A4,6 !8x8 bytes is size per entry
lea D4,[A4+callbackstack]

mov [D4],rbx
mov [D4+8],rsi
mov [D4+16],rdi
mov [D4+24],r12
mov [D4+32],r13
mov [D4+40],r14
mov [D4+48],r15
ret

with almost no change (I had to change it slightly
because of restrictions on the assembler being used).

Did I stuff up the register assignment by using rbx?

Here is what I based it off, and you can see that D4 = rbx:

The Intel register name is the one after the ! character:

("d0", 8, r0), !rax d0..d9 are for general use
("d1", 8, r1), !r10 d0..d2 are volatile in ABI
("d2", 8, r2), !r11

("d3", 8, r3), !rdi d3..d9 are preserved across funcs in ABI
("d4", 8, r4), !rbx
("d5", 8, r5), !rsi
("d6", 8, r6), !r12
("d7", 8, r7), !r13
("d8", 8, r8), !r14
("d9", 8, r9), !r15

("d10", 8, r10), !rcx d10..d13 are win64 ABI register passing regs
("d11", 8, r11), !rdx ..
("d12", 8, r12), !r8 ..
("d13", 8, r13), !r9 ..

("d14", 8, r14), !rbp frame pointer
("d15", 8, r15), !rsp stack pointer

dstack is an alias for D15/rsp.
dframe is an alias for D14/rbp.

A0..A15 are 32-bit registers.
W0..W15 are 16-bit registers
B0..B15 are 8-bit registers.

So D0 is just rax.

Am I missing something?

Thanks. Paul.

On 06/09/2023 14:46, Paul Edwards wrote:
> Hi Bart (or anyone else who may be able to figure it out).

> .globl m$pushcallback
> m$pushcallback:
> incd [ncallbacks]
> xor rbx, rbx
> mov ebx,[ncallbacks]
> shl ebx,6 #8x8 bytes is size per entry
> lea rbx,[rbx+callbackstack]
>
> mov [rbx],rbx
> mov [rbx+8],rsi
> mov [rbx+16],rdi
> mov [rbx+24],r12
> mov [rbx+32],r13
> mov [rbx+40],r14
> mov [rbx+48],r15
> ret
>
>
> I can see that rbx is clobbered, not preserved!

> Now x64supb.asm is code I constructed myself, but it was
> based on this:
>
> m$pushcallback::
> inc dword [ncallbacks]
> mov A4,[ncallbacks]
> shl A4,6 !8x8 bytes is size per entry
> lea D4,[A4+callbackstack]
>
> mov [D4],rbx
> mov [D4+8],rsi
> mov [D4+16],rdi
> mov [D4+24],r12
> mov [D4+32],r13
> mov [D4+40],r14
> mov [D4+48],r15
> ret

Where did you get this code from? In the BCCLIB.ASM version used by bcc,
A2/D2 are used not A4/D4. Registers D0,D1,D2 in my naming scheme are
volatile.

D2 corresponds to Intel register R11

> ("d2", 8, r2), !r11

Hmm, if I look inside a file called CC64.C (I don't know if it's the
same as yours, but it's dated Nov 2020), the string representing
bcclib.asm uses D4 too. A recent CC.C file seems OK.

What I will do is try and regenerate the cc64.c file with one from 2023.

I'll investigate where the rogue version may have came from.

On Wednesday, September 6, 2023 at 11:35:20 PM UTC+8, Bart wrote:

> > I can see that rbx is clobbered, not preserved!

> > mov A4,[ncallbacks]
> > shl A4,6 !8x8 bytes is size per entry
> > lea D4,[A4+callbackstack]

> Where did you get this code from?

From the bcclib.asm that is produced when running the
only public domain cc64.c I have ever seen posted.

> In the BCCLIB.ASM version used by bcc,
> A2/D2 are used not A4/D4. Registers D0,D1,D2 in my naming scheme are
> volatile.
>
> D2 corresponds to Intel register R11

Thanks. I have modified my code to the below and it seems to
work now.

..globl m$pushcallback
m$pushcallback:
incd [ncallbacks]
# xor r11, r11
mov r11,[ncallbacks]
shl r11,6 #8x8 bytes is size per entry
lea r11,[r11+callbackstack]

mov [r11],rbx
mov [r11+8],rsi
mov [r11+16],rdi
mov [r11+24],r12
mov [r11+32],r13
mov [r11+40],r14
mov [r11+48],r15
ret

..globl m$popcallback
m$popcallback:
# xor r11,r11
mov r11,[ncallbacks]
shl r11,6 #8x8 bytes is size per entry
lea r11,[r11+callbackstack]
mov rbx,[r11]
mov rsi,[r11+8]
mov rdi,[r11+16]
mov r12,[r11+24]
mov r13,[r11+32]
mov r14,[r11+40]
mov r15,[r11+48]
decd [ncallbacks]
ret

ncallbacks:
.space 8

BFN. Paul.

On 06/09/2023 17:24, Paul Edwards wrote:
> On Wednesday, September 6, 2023 at 11:35:20 PM UTC+8, Bart wrote:
>
>>> I can see that rbx is clobbered, not preserved!
>
>>> mov A4,[ncallbacks]
>>> shl A4,6 !8x8 bytes is size per entry
>>> lea D4,[A4+callbackstack]
>
>> Where did you get this code from?
>
> From the bcclib.asm that is produced when running the
> only public domain cc64.c I have ever seen posted.
>
>> In the BCCLIB.ASM version used by bcc,
>> A2/D2 are used not A4/D4. Registers D0,D1,D2 in my naming scheme are
>> volatile.
>>
>> D2 corresponds to Intel register R11
>
> Thanks. I have modified my code to the below and it seems to
> work now.

I've put a revised version of cc64 here:

https://github.com/sal55/langs/tree/master/mcc

(As the file cc64_06sep23.c). I suggest this is only used to extract the
current version of bcclib.asm:

* Delete bcclib.asm (or start somewhere with no version)
* Build cc64_06sep23.c
* Run it with no inputs, it should write bcclib.asm

('mcc' is the name of the product that replaces 'bcc'.)

On Thursday, September 7, 2023 at 12:46:10 AM UTC+8, Bart wrote:

> I've put a revised version of cc64 here:
>
> https://github.com/sal55/langs/tree/master/mcc

Thanks for that. I have downloaded it.

I'll wait until you have a stable version of mcc before
using it, as I now have a working environment and
other things are a higher priority at the moment (like
a "dir" command in UCX64).

BFN. Paul.

On 06/09/2023 16:35, Bart wrote:
> On 06/09/2023 14:46, Paul Edwards wrote:
>> Hi Bart (or anyone else who may be able to figure it out).
>
>> .globl m$pushcallback
>> m$pushcallback:
>>     incd [ncallbacks]
>>          xor rbx, rbx
>>     mov ebx,[ncallbacks]
>>     shl ebx,6                    #8x8 bytes is size per entry
>>     lea rbx,[rbx+callbackstack]
>>
>>     mov [rbx],rbx
>>     mov [rbx+8],rsi
>>     mov [rbx+16],rdi
>>     mov [rbx+24],r12
>>     mov [rbx+32],r13
>>     mov [rbx+40],r14
>>     mov [rbx+48],r15
>>     ret
>>
>>
>> I can see that rbx is clobbered, not preserved!
>
>> Now x64supb.asm is code I constructed myself, but it was
>> based on this:
>>
>> m$pushcallback::
>>     inc dword [ncallbacks]
>>     mov A4,[ncallbacks]
>>     shl A4,6                    !8x8 bytes is size per entry
>>     lea D4,[A4+callbackstack]
>>
>>     mov [D4],rbx
>>     mov [D4+8],rsi
>>     mov [D4+16],rdi
>>     mov [D4+24],r12
>>     mov [D4+32],r13
>>     mov [D4+40],r14
>>     mov [D4+48],r15
>>     ret
>
> Where did you get this code from? In the BCCLIB.ASM version used by bcc,
> A2/D2 are used not A4/D4. Registers D0,D1,D2 in my naming scheme are
> volatile.
>
> D2 corresponds to Intel register R11
>
>> ("d2", 8, r2), !r11
>
> Hmm, if I look inside a file called CC64.C (I don't know if it's the
> same as yours, but it's dated Nov 2020), the string representing
> bcclib.asm uses D4 too. A recent CC.C file seems OK.
>
> What I will do is try and regenerate the cc64.c file with one from 2023.
>
> I'll investigate where the rogue version may have came from.

I suspect that in 2020, before I was using ABI compliance in any of my
compilers, the register mapping used between my D0-D15 register names
and Intel's was different.

So D4 was presumably a volatile register (not RBX) which was suitable
for the example code above.

When I started being ABI-compliant, I found it convenient to group
together volatile registers as specified by the ABI (D0-D2);
non-volatile (D3-D9); and argument passing (D10-D13).

So the mapping was changed. As was that bit of ASM support code.

What happened here is that the mapping info I supplied was for the new
mapping, not the old. But the support ASM code that you (PE) converted
was the old code. Sorry about that.