The Sinclair QL Forum

Posted: **Tue Aug 16, 2022 2:34 am**

So using the -t option in the code generator/linker got me this table:

Functions
~~~~~~~~~

_clunget         81EA
_dosw            81DA
_fpush           8BAE
_getid           844E
_ltoab           891A
_mult_l          8866
_open            836E
_print           89A4
_qstrcpy         87B2
_read            8400
_write           8434
atoi             87C0
ccargc           844A
datastart        8444
delete           8316
exit             80E2
fclose           83D6
fgetc            8202
fgets            8248
fopen            835C
fputc            82D4
fputs            8294
ftoa             8812
get_chanid       845E
get_fd           82FA
getc             8202
getchar          81FE
gets             8232
isdigit          883C
ltoa             898A
main             84BC
printf           8B98
putc             82D4
putchar          82CE
qdos_error       8466
strlen           8854
ultoa            88B6
ungetc           846C


Global variables
~~~~~~~~~~~~~~~~



array2D          84B4

_arg1            8730
_cmd             8732
_cnt             872E
_vec             8706

And 8B4B is 33972 in hex, which matches what the 16 bit values are showing. So at least I know that the 6 value that represents an address for array2D[j][1] is an error. In fact, what 6 here is, is the offset value (i.e. if you add it to 33972 then you'd have the correct array value).

Posted: **Tue Aug 16, 2022 12:00 pm**

I have that updated document (it's actually integrated in the SPC_TXT file that comes with Digital C SE distribution).

So I've narrowed down the problem. It's not an issue with 2D arrays, it's actually an issue with array of structs. So this code will work:

Code: Select all

#include stdio_h

struct record {
   int a;
   int b;
};

struct record list[10];

main ()
{
   list[5].a = 10;
   list[5].b = 20;
   
   printf("%d, %d\n", list[5].a, list[5].b);  /* works using literal values...prints 10 and 20 */
}

But as soon as you introduce variables it will not:

Code: Select all

#include stdio_h

struct record {
   int a;
   int b;
};

struct record list[10];

int i;  /* global variable */
 
main ()
{
   int j;  /* local variable */
   
   i = 5;
   j = 5;
   
   list[5].a = 10;
   list[5].b = 20;
   
   printf("%d, %d\n", list[i].a, list[j].b);   /* doesn't work using variables (doesn't matter if local or global)...prints 0 for both */
}

Of course if you use i and j during the assignment then it works but only because you are accessing uninitalized memory (i.e. for me I'd see some screen corruption). Looking at the addresses, anytime you have a variable as an array subscript, when using an array of structs, it calculates the offset but doesn't add it to the actual address -- so all you are left with is the offset.

I do have the source (from Dilwyn's site) and I emailed Gerry Jackson, who is still active on GitHub. Unfortunately the email he used for Digital C SE is specific to it (qldigitalc@gmail.com) so I may not hear from him. I can't find his email on GitHub, though I could just randomly post/comment on an active project and see if he responds. The Digital C SE source was compiled on QL2K using Digital C SE (pretty cool) so I should be able to create a corrected version if I can figure out where it fails. It's in the parser, and having it narrowed down to the simplest case will hopefully make it easier to figure out.

What I need to do first is compile my sample code on other emulators in case QLAY is doing something funky that's causing this weird issue. I also want to make sure I have the latest version of Digital C SE, in case an older version crept in for me. I'm still hesitant to say there is a bug in Digital C SE, because if it is a bug, that would have been horrible QA by Digital Precision. They basically implemented this struct feature that made it unique from all the other Small C implementations on the QL (i.e. GSC and QL Small C) and failed to check if it actually fully worked...and they specifically had examples in their manual using that feature.

Posted: **Wed Aug 17, 2022 7:44 am**

Same result on Q-emulator with the second, broken program. So structs in Digital C SE are broken. Next, I will look to see if I can find the issue in the parser and see if I can fix it and then recompile it. I don't run QL2K as often as QLAY but it's pretty much the same with sound added.

I'm actually excited about compiling the Digital C SE compiler with the Digital C SE compiler. That's pretty cool and I remember back when I was in college and learning Pascal as a youngster, it blew my mind that Niklaus Wirth compiled his Sheffield Pascal compiler in Sheffield Pascal itself.

The Sinclair QL Forum

Dhrystone compiled on BBQL with Digital C SE

Re: Dhrystone compiled on BBQL with Digital C SE

Re: Dhrystone compiled on BBQL with Digital C SE

Re: Dhrystone compiled on BBQL with Digital C SE