Can anyone spot where this compiler:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/cc64/cc64.c

is preserving registers?

I am getting code generated that clobbers A3 (edi), but
the same happens with different code where D3 (rdi)
is clobbered.

The at&t syntax of a modified version is:

C:\devel\pdos\pdcc\cpplib>type symtab3.asm
..text
..globl symtab_destroy_symtab
symtab_destroy_symtab:
push %rbp
mov %rsp,%rbp
push %rdi
mov %rcx,0x10(%rbp)
mov %rdx,0x18(%rbp)
jmp fred
fred:
mov 0x10(%rbp),%rbx
# These used to have rex
mov 0x8(%rbx),%edi
mov %edi,%eax
dec %edi
mov %edi,0x8(%rbx)
# end of rex
cmp $0x0,%eax
jne fred
pop %rdi
pop %rbp
ret

(I added the push and pop of rdi manually to make it work)

Now I need that push and pop to happen automatically.

I don't mind if there are two push rdi to keep the stack
16-byte aligned.

Hell - I don't even particularly care if all registers that are
meant to be preserved are pushed and popped
unconditionally (ie even if not used).

I just need it to work.

I've looked (and am still looking) in the source code to
try to find where this could be done.

Thanks. Paul.

`symtab_destroy_symtab::
push Dframe
mov Dframe, Dstack
sub Dstack, 16
mov [Dframe+16], D10
mov [Dframe+24], D11
! -------------------------------------------------
jmp L11
L12:
sub Dstack, 32
mov D0, [Dframe+16]
mov A13, [D0+8]
push D13
mov D10, KK1
pop D11
call `printf*
add Dstack, 32
mov D0, [Dframe+16]
mov A0, [D0+8]
cmp A0, 7
jnz L13
jmp L10
L13:
mov D13, 0
mov [Dframe-16], D13
mov D0, [Dframe+16]
mov D0, [D0+0]
mov D1, [Dframe+16]
movsx D1, word32 [D1+8]
mov D0, [D0+D1*8]
mov [Dframe-8], D0
sub Dstack, 32
mov D10, KK2
mov D11, [Dframe-8]
call `printf*
add Dstack, 32
jmp L16
L17:
mov D0, [Dframe-8]
mov D0, [D0+16]
mov [Dframe-16], D0
sub Dstack, 32
mov D10, KK3
mov D11, [Dframe-8]
call `printf*
add Dstack, 32
sub Dstack, 32
mov D10, [Dframe-8]
mov D0, [Dframe+24]
call D0
add Dstack, 32
L14:
mov D0, [Dframe-16]
mov [Dframe-8], D0
L16:
mov D0, [Dframe-8]
cmp D0, 0
jnz L17
L15:
L9:
L11:
mov D1, [Dframe+16]
mov A3, [D1+8]
mov A0, A3
dec A3
mov [D1+8], A3
cmp A0, 0
jnz L12
L10:
sub Dstack, 32
mov D10, [Dframe+16]
mov D10, [D10+0]
call `free*
add Dstack, 32
sub Dstack, 32
mov D10, [Dframe+16]
call `free*
add Dstack, 32
L8:
! -------------------------------------------------
add Dstack, 16
pop Dframe
ret

align 16

I stumbled across something promising, and I think I have the push now.

C:\devel\pdos\cc64>git diff .
diff --git a/cc64/cc64.c b/cc64/cc64.c
index 525e5f2b..eebf3477 100644
--- a/cc64/cc64.c
+++ b/cc64/cc64.c
@@ -22166,6 +22166,9 @@ static void cc_genmcl_genprocentry(i64 fbytes,i64 pbytes) {
if (!!(fbytes)) {
cc_libmcl_pushstack(cc_libmcl_roundto(fbytes,(i64)16));
};
+ /* 1 is rax, 5 is r10, 3 is rsi, 4 is rdi */
+ cc_libmcl_genmc((i64)6,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
+ cc_libmcl_genmc((i64)6,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
} else {
cc_libmcl_pushstack((i64)8);
};

C:\devel\pdos\cc64>

0000000000000000 <symtab_destroy_symtab>:
0: 55 push %rbp
1: 48 8b ec mov %rsp,%rbp
4: 57 push %rdi
5: 57 push %rdi
6: 48 89 4d 10 mov %rcx,0x10(%rbp)
a: 48 89 55 18 mov %rdx,0x18(%rbp)
e: e9 00 00 00 00 jmp 13 <symtab_destroy_symtab+0x13>
13: 48 8b 5d 10 mov 0x10(%rbp),%rbx
17: 48 8b 7b 08 mov 0x8(%rbx),%rdi
1b: 48 8b c7 mov %rdi,%rax
1e: 48 ff cf dec %rdi
21: 48 89 7b 08 mov %rdi,0x8(%rbx)
25: 48 83 f8 00 cmp $0x0,%rax
29: 75 e8 jne 13 <symtab_destroy_symtab+0x13>
2b: 5d pop %rbp
2c: c3 ret

With this:

C:\devel\pdos\cc64>git diff .
diff --git a/cc64/cc64.c b/cc64/cc64.c
index 525e5f2b..7e3216bd 100644
--- a/cc64/cc64.c
+++ b/cc64/cc64.c
@@ -22166,6 +22166,9 @@ static void cc_genmcl_genprocentry(i64 fbytes,i64 pbytes) {
if (!!(fbytes)) {
cc_libmcl_pushstack(cc_libmcl_roundto(fbytes,(i64)16));
};
+ /* 1 is rax, 5 is r10, 3 is rsi, 4 is rdi */
+ cc_libmcl_genmc((i64)6,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
+ cc_libmcl_genmc((i64)6,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
} else {
cc_libmcl_pushstack((i64)8);
};
@@ -22970,6 +22973,10 @@ void cc_libmcl_genreturn(i64 fbytes,i64 pbytes) {
iscallback = cc_libmcl_iscallbackfn(cc_decls_currproc);
cc_libmcl_retbeforeblock = (i64)1;
if ((!!(fbytes) || !!(pbytes))) {
+ /* first parameter: 6 is push, 7 is pop */
+ /* second parameter: 4 is rdi */
+ cc_libmcl_genmc((i64)7,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
+ cc_libmcl_genmc((i64)7,cc_libmcl_genreg((i64)4,(i64)8),(struct cc_libmcl_opndrec *)(0));
if (!!(fbytes)) {
cc_libmcl_popstack(cc_libmcl_roundto(fbytes,(i64)16));
};

C:\devel\pdos\cc64>

I get the desired generated code:

C:\devel\pdos\pdcc>cc64-fudge -c -out:cpplib/symtab2.obj cpplib/symtab2.i
Compiling cpplib/symtab2.i to cpplib/symtab2.obj

C:\devel\pdos\pdcc>objdump -d cpplib/symtab2.obj

cpplib/symtab2.obj: file format pe-x86-64

Disassembly of section .text:

0000000000000000 <symtab_destroy_symtab>:
0: 55 push %rbp
1: 48 8b ec mov %rsp,%rbp
4: 57 push %rdi
5: 57 push %rdi
6: 48 89 4d 10 mov %rcx,0x10(%rbp)
a: 48 89 55 18 mov %rdx,0x18(%rbp)
e: e9 00 00 00 00 jmp 13 <symtab_destroy_symtab+0x13>
13: 48 8b 5d 10 mov 0x10(%rbp),%rbx
17: 48 8b 7b 08 mov 0x8(%rbx),%rdi
1b: 48 8b c7 mov %rdi,%rax
1e: 48 ff cf dec %rdi
21: 48 89 7b 08 mov %rdi,0x8(%rbx)
25: 48 83 f8 00 cmp $0x0,%rax
29: 75 e8 jne 13 <symtab_destroy_symtab+0x13>
2b: 5f pop %rdi
2c: 5f pop %rdi
2d: 5d pop %rbp
2e: c3 ret

C:\devel\pdos\pdcc>

and cc64 even rebuilds itself, with byte exact, and my original
application now appears to work if I only compile the one
source file with the issue.

However, when I compile everything, the new compiler hangs.

Any ideas about that?

Thanks. Paul.

I have isolated the test case.

It is presumably related to the return of structs.

They presumably occupy the same area that I just
did two push rdis to.

But this is the compiler hanging, not the code being compiled.

BFN. Paul.

C:\devel\pdos\pdcc\yyy>type expr.i
typedef struct {
char aaa[9]; /* 9+ hangs, 8 does not */
} zzztype;

static zzztype number_trim(zzztype rrrr, int ppp)
{ return (rrrr);
}

static zzztype append_digit(zzztype num,
int mary,
int john,
int yyy)
{ zzztype result;

result = number_trim(result, yyy);

return (result);
}

C:\devel\pdos\pdcc\yyy>doit

C:\devel\pdos\pdcc\yyy>cc64-fudge -c -out:expr.obj expr.i
Compiling expr.i to expr.obj
Terminate batch job (Y/N)? y

C:\devel\pdos\pdcc\yyy>

On 03/09/2023 04:07, Paul Edwards wrote:
> Can anyone spot where this compiler:
>
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/cc64/cc64.c
>
> is preserving registers?

I very much doubt anyone here could answer that (not even me).

You may have posted on email about this but I don't check that all the time.

There is one big restriction in this compiler that I used to keep
pointing out but maybe you missed it:

It is not fully ABI-compliant. This affects 'callback' functions, which
here means cc64-compiled functions being called from any code that is
not cc64-compiled.

(A simple example is calling qsort() with a pointer to a local function.)

It necessary to mark such functions like this:

$callback int fred(int a, int b) {return a+b;}

or (better as code is then acceptable elsewhere) like this:

#pragma $callback
int fred(int a, int b) {return a+b;}

This will save and restore registers the ABI says are volatile. It
applies to the following function only.

There is also a compiler option -callback which effectively applies this
to every function. But that will slow things down (the register-save
code is not efficient), and is only intended to identify whether a
missing $callback was a problem.

(As I said I'm replacing the code generator.)

The original intention of the bcc project was that most programs would
consist of code compiled with itself, and not statically linked to
externally compiled code. So callbacks applied to only a small number of
functions.

On Sunday, September 3, 2023 at 5:43:35 PM UTC+8, Bart wrote:

> There is one big restriction in this compiler that I used to keep
> pointing out but maybe you missed it:
>
> It is not fully ABI-compliant. This affects 'callback' functions, which
> here means cc64-compiled functions being called from any code that is
> not cc64-compiled.

All code has been compiled with cc64 with the exception
of C90 routines in msvcrt.dll.

However, what I can do is statically link my own C library
(compiled with cc64) to see if that solves the problem.

I only use a handful of kernel32 calls, none of them
involving callbacks as far as I am aware.

> It necessary to mark such functions like this:
>
> $callback int fred(int a, int b) {return a+b;}
>
> or (better as code is then acceptable elsewhere) like this:
>
>
> #pragma $callback
> int fred(int a, int b) {return a+b;}
>
> This will save and restore registers the ABI says are volatile. It
> applies to the following function only.
>
> There is also a compiler option -callback which effectively applies this
> to every function. But that will slow things down (the register-save
> code is not efficient), and is only intended to identify whether a
> missing $callback was a problem.

Actually, I'll try this first - thanks!

> The original intention of the bcc project was that most programs would
> consist of code compiled with itself, and not statically linked to
> externally compiled code. So callbacks applied to only a small number of
> functions.

I'm not sure why you think I have externally compiled code.

BFN. Paul.

On Sunday, September 3, 2023 at 6:03:06 PM UTC+8, Paul Edwards wrote:

> > There is also a compiler option -callback which effectively applies this
> > to every function. But that will slow things down (the register-save
> > code is not efficient), and is only intended to identify whether a
> > missing $callback was a problem.

> Actually, I'll try this first - thanks!

That created some heap allocation error when I ran
the cc64 built with cc64 with that option.

> However, what I can do is statically link my own C library
> (compiled with cc64) to see if that solves the problem.

Building this (without the rdi fudge), has the same
behavior as the rdi fudge (ie crashes - I previously
incorrectly thought it was hanging rather than
crashing). So I think this problem is unrelated to my
rdi fudge.

C:\devel\pdos\cc64>objdump -x cc64-new.exe | grep -i dll
DllCharacteristics 00000140
vma: Hint Time Forward DLL First
DLL Name: kernel32.dll

C:\devel\pdos\cc64>

C:\devel\pdos\pdcc\yyy>type expr.i
typedef struct {
char aaa[9]; /* 9+ hangs, 8 does not */
} zzztype;

static zzztype number_trim(zzztype rrrr, int ppp)
{ return (rrrr);
}

static zzztype append_digit(zzztype num,
int mary,
int john,
int yyy)
{ zzztype result;

result = number_trim(result, yyy);

return (result);
}

C:\devel\pdos\pdcc\yyy>doit

C:\devel\pdos\pdcc\yyy>del expr.asm
Could Not Find C:\devel\pdos\pdcc\yyy\expr.asm

C:\devel\pdos\pdcc\yyy>rem rem cc64-fudge -c -out:expr.obj expr.i

C:\devel\pdos\pdcc\yyy>rem cc64 -s -out:expr.obj expr.i

C:\devel\pdos\pdcc\yyy>\devel\pdos\cc64\cc64-new -s -out:expr.obj expr.i

C:\devel\pdos\pdcc\yyy>rem \devel\pdos\cc64\cc64-new -callback -s -out:expr..obj expr.i

C:\devel\pdos\pdcc\yyy>rem cc64 -s -out:expr.obj expr.i

C:\devel\pdos\pdcc\yyy>dir expr.asm
Volume in drive C has no label.
Volume Serial Number is 4E58-AF11

Directory of C:\devel\pdos\pdcc\yyy

File Not Found

C:\devel\pdos\pdcc\yyy>

BFN. Paul.

Sorry - I stuffed something up.

Let me reevaluate and I'll give an update.

Thanks. Paul.

On Sunday, September 3, 2023 at 5:43:35 PM UTC+8, Bart wrote:

> (A simple example is calling qsort() with a pointer to a local function.)

You got it exactly right - I was calling atexit() with a function
that hadn't been appropriately marked up.

And my previous test stuffed up because I had some dummy
routines to resolve unresolved external references (from
kernel32) that I thought (correctly, it seems) weren't being used,
and the push and pop had inadvertently got into there.

I have now created proper push/pop routines, similar, but not
identical, to yours (because I found an assembler limitation,
separately reported to the author) and now everything works.

Thanks a lot for your assistance, and sorry for any noise!

BFN. Paul.

I have had considerable success.

All the tools were able to be compiled, but:

1. I haven't tested on real hardware.

2. There were a few compiler errors that I bypassed
(meaning a runtime error will occur) rather than fix
immediately.

3. bootx64.efi is still built with mingw64. cc64 can
build it, but I haven't put that in yet.

4. Testing under qemu shows that most things don't
work.

5. Only a minimal number of functions in msvcrt.dll have
been provided so far, so it's only meant to display the help
for each tool.

Anyway, at http://pdos.org there is ucx64.zip. Source can
be found on uc386.zip.

You can do:

pdcc.exe --help
pdas.exe --help doesn't crash, but doesn't do much
pdld.exe --help also doesn't crash or do much

Most other executables seem to crash.

But overall, this looks completely viable. There is no
evidence of something fundamental that will prevent
the bugs from being found and fixed/worked around
with minimal changes to the original source code.

Not a bad result for my second solar cycle.

https://en.wikipedia.org/wiki/Solar_cycle_(calendar)

BFN. Paul.

In article <0326a8ca-a0ce-43a6-93f7-6081fe7c9054n@googlegroups.com>,
Paul Edwards <mutazilah@gmail.com> wrote:
>Sorry - I stuffed something up.
>
>Let me reevaluate and I'll give an update.

Take it to email? This has little to do with C.

- Dan C.