DOS ain't dead

I am debugging the AWKA compiler with Watcom 1.9. The stack appears to be corrupted when returning from the awka_insertop() function in da.c.

I compiled da.obj like so:

wcc -q -os -okz -s -bt=dos -ml -fpi87 -i=\watcom\h -i=. -dSTDC_HEADERS -wcd=118 da.c

Here are code listings:

da.c
https://termbin.com/adti

da.lis (wdis da.obj >da.lis)
https://termbin.com/ccvp

code.c:dump_code():

    void
    dump_code()
    {
       if (begin_start)
       { awka_insertop(_BEGIN, NULL, NULL, 0, 0);
       ...

ASM code to call awka_insertop():

    30D7:DC15  dump_code_+00000016
    DC15  xor        ax,ax
    DC17  push       ax
    DC18  push       ax
    DC19  push       ax
    DC1A  push       ax
    DC1B  xor        bx,bx
    DC1D  xor        cx,cx
    DC1F  mov        ax,00B6
    DC22  call       far ptr awka_insertop_

Stack after tracing to the last line of ASM code:

    SS: 4465
    BP: 0000
    SP: FCE4

Stack after entery to da.c:awka_insertop():

    SS: 4465
    BP: 0000
    SP: FCE0

ASM code on entry:

    1F4C  push       dx
    1F4D  push       si
    1F4E  push       di
    1F4F  push       bp
    1F50  mov        bp,sp
    1F52  sub        sp,0008

Stack after tracing through this last line of ASM code:

    SS: 4465
    BP: FCD8
    SP: FCD0

ASM code before return:

    2397  mov       sp,bp
    2399  pop       bp
    239A  pop       di
    239B  pop       si
    239C  pop       dx
    239D  retf      000C

Stack at the first line of ASM code:

    SS: 4465
    BP: FCD8
    SP: FCD0

Stack after tracing to the last line of ASM code:

    SS: 4465
    BP: 0000
    SP: FCE0

The stack is the same as it was on entering awka_insertop(), which is good!

Stack after returning to dump_code():

    SS: 4465
    BP: 0000
    SP: FCF0

The stack is different than it was before calling awka_insertop(), which is bad. SP was FCE4 and now it is FCF0.

I think it would have been OK if Watcom had emitted CB retf, which it did for all the *other* returns in da.c. For some reason, Watcom generated CA 0C 00 retf 0x00c here, and this seems to break the stack.

I skimmed through the code generation options in the Watcom 1.9 cguide.pdf. I tried changing the compiler flag from -okz to -oz. That didn't help.

Any other recommendations?

Thank you!

-Ben

> The stack is different than it was before calling awka_insertop(), which is
> bad. SP was FCE4 and now it is FCF0.

No, that's right, as the retf 0x0c pops the six pushes of the arguments (other functions don't have as many arguments, so they're wholly passed in registers). If you're getting stack corruption, it's not because of that.

> No, that's right, as the retf 0x0c pops the six pushes of the arguments
> (other functions don't have as many arguments, so they're wholly passed in
> registers). If you're getting stack corruption, it's not because of that.

Thanks for the hint, i think it will help.

The awka_insertop() declaration in da.c has 6 arguments:

void
awka_insertop(int op, char *cval, char *carg, int minst, char *file, int line)
{

The awka_insertop() prototype in code.c has 5 arguments:

void awka_insertop(int, char *, char *, int, int);

And dump_code() indeed calls it with 5 arguments instead of 6.

I guess it's GIGO and it's on me to fix it.

Don't forget that common optimizations like -ox are the same as -obmiler -s (and turns off stack checking). Plus, being large model (and not flat), the stack is much smaller (4 kb?).

Have you seen https://github.com/noyesno/awka/ ?

> Have you seen https://github.com/noyesno/awka/ ?

Yes, that's the source code i am in the middle of porting to Watcom.