Dhrystone compiled on BBQL with Digital C SE

[tofro]

That is, btw, a dangerous assumption as it's not generally true. Microsoft, for example, in their ultimate wisdom, decided a 32 bit long is "long enough", even on a 64 bit system.

Sounds strange at first, but Microsoft is all about compatibility and in that context it does make sense. I once had to port 200.000 lines of a 3rd party C++ framework from 32 to 64-bit for work. An external company provided an estimate of cost of 45000€ for this. In the end I did it myself in just one week because due to the choices Microsoft made it's all fairly easy (except the hidden cases where pointers were cast into integers... but Visual Studio's compiler warnings usually helped there a lot, too). And no, I didn't get the 45000€, but it helped reinforcing my image as the local magician.

With a reasonably modern C system, you have the stdint.h include file with definitions of types (like int16_t, for example) for fixed bit length.

True. I use that with my C68 projects, too, but seeing Tobias comment I might have written the stdint.h myself in this case, I don't remember.

stdint.h was introduced with C99 in, well 1999.

C68 proudly states in some documents to be partially compatible to "the ANSI C pre-standard" - which is C89 - from, well '90. we can be just about happy that C++ comments are supported, albeit with the preprocessor choking on them every now and then.

My installation doesn't have a stdint_h - but soon it might, as it's admittedly useful.

[bwinkel67]

So I've been struggling with 2D arrays in Digital C SE. You are supposed to be able to do it using structs (you cannot do so directly), but unfortunately no examples are given in their manual. I implemented it the way I think C would do it...Please correct me if I'm wrong as I haven't had a chance to try it on a real C compiler.

Here is how I thought it should work:

Code: Select all

#include stdio_h

struct dim {
   int col[2];
};

struct dim array2D[2];

main()
{
   int i, j;

   i = 0;
   j = 1;

   array2D[1].col[1] = 10;


   printf("addr: array2D = %lu\n", array2D);

   printf("addr: &array2D[0].col[0] = %lu\n", &array2D[0].col[0]);

   printf("addr: &array2D[1].col[1] = %lu\n", &array2D[1].col[1]);

   printf("i=0; addr: &array2D[i].col[i] = %lu\n", &array2D[i].col[i]);

   printf("j=1; addr: &array2D[j].col[j] = %lu\n", &array2D[j].col[j]);

   printf("value: array2D[1].col[1] = %d\n", array2D[1].col[1]);

   printf("j=1; value: array2D[j].col[j] = %d\n", array2D[j].col[j]);
}

But you can see below in the last printed statement it shows a 0 but the array element should be 10. Note that the pointers are all wrong when using variables to access the arrays. It works with literal numeric values but not variables (the pointers are these smaller values). I actually dug down even deeper and it's the first subscript that doesn't work with a variable, whereas if you do something like array2D[1].col[j] it would work:

The solution is this odd syntax. Again, haven't tired it on a real C compiler, but that cannot be the actual syntax, can it?

Code: Select all

#include stdio_h

struct dim {
   int col[2];
};

struct dim array2D[2];

main()
{
   int i, j;

   i = 0;
   j = 1;

   array2D.col[1][1] = 10;


   printf("addr: array2D = %lu\n", array2D);

   printf("addr: &array2D.col[0][0] = %lu\n", &array2D.col[0][0]);

   printf("addr: &array2D.col[1][1] = %lu\n", &array2D.col[1][1]);

   printf("i=0; addr: &array2D.col[i][i] = %lu\n", &array2D.col[i][i]);

   printf("j=1; addr: &array2D.col[j][j] = %lu\n", &array2D.col[j][j]);

   printf("value: array2D.col[1][1] = %d\n", array2D.col[1][1]);

   printf("j=1; value: array2D.col[j][j] = %d\n", array2D.col[j][j]);
}

Here it finally has the correct addresses for both literal numeric values and variables:

I'm guessing Digital C SE is parsing it this way:

Code: Select all

   (array2D.col[1])[1] = 10;

[tofro]

Before I'd shoot myself into the foot too much with using structs, I'd emulate a 2-dimensional array by a one-dimensional one that has i * j entries, like

Translate

Code: Select all

int i [ROWS][COLUMNS];

i [row][column] = x;

into

Code: Select all

int i [ROWS * COLUMNS];

i [row * COLUMNS + column] = x;

[Derek_Stewart]

Hi,

Digital C SE is a Small C Compiler, as detailed in the SPC manual,

DIGITAL C SPECIAL EDITION is an implementation of the Small-C compiler originally published in Dr. Dobbs' Journal. This compiler, which was originally written to run on Z80 and 8080-based systems has been heavily modified to run on the QL or Thor.

In the Small C Handbook by James Hendrix, Small C is limited to 1D Arrays of up to 32767 elements of char or int.

Structures in SPC Update v2.05 are also detailed , with inly 1D arrays, maybe this is problem.

Why not use C68, this allows multi-dimension arrays.

[bwinkel67]

My initial Dhrystone implementation had a 2601 int array using the formula, but I wanted to give the 2D array method, via structs, a try in Digital C SE. It's one of Digital Precision's additions that differentiates it from Small C and GSC.

I did try it under GCC and indeed, my original method was correct and the 2nd one would not compile. I'm trying to understand what they did, instead of finding the best QL compiler. The concept of a struct was part of K & R back in the mid-80's so I would be shocked if Digital Precision came up with its own syntax. The odd thing is that both ways parse so perhaps their integration into the original small C (i.e. adding to the parser) had some issues and thus the correct way fails on a single case. Just would have been nice to see an example from their manual as to how they thought it ought to work. Digital Precision had a quality software library and I would think they had thoroughly tested the struct addition.

[tofro]

The pointers in your first 3 printf() lines look seriously wrong and are outside any reachable address space of the 68000. Something must have gone wrong with a sign extension here, they look like negative numbers to me (0xffff84b4). And pointers being 32-bit is a feature of the special edition of the compiler (before, they were 16 bits, apparently), maybe what you see here is an omitted change.

[bwinkel67]

The pointers in your first 3 printf() lines look seriously wrong and are outside any reachable address space of the 68000. Something must have gone wrong with a sign extension here, they look like negative numbers to me (0xffff84b4). And pointers being 32-bit is a feature of the special edition of the compiler (before, they were 16 bits, apparently), maybe what you see here is an omitted change.

I do see the size being an issue, but these are the valid pointers. If you do just a simple malloc in Digital C SE you get pointers of that size exactly in that range. I initially thought those were the bad ones since they are at the to of 32 bits (4GB). It's the pointers reading 262144 that are incorrect and though they show no signs on either QLAY or Q-Emulator, on my actual QL they write into screen memory, leaving artifacts (that's in fact how I knew things weren't working, since otherwise it compiles fine). I'm printing them out as lu (long unsigned) so perhaps the top 12 bits need to be masked out since the 68008 has only a 20 bit address range...I will give that a try in my next run as I continue to try and figure out what's going on.

In the end, I don't think I'll use the array2D.col[j] syntax since it's not C, but it would be nice to have to avoid the single array solution since they did supposedly implement 2D via structs in Digital C SE.

[Derek_Stewart]

If you look on Tim Swenson's web site:
http://swensont.epizy.com/

look at the Small C Companion, here Tim talks about 2D arrays on Digital C

http://swensont.epizy.com/SmallC_Compan.pdf

[bwinkel67]

Looking at he manual:

Code: Select all

   A6 base  Base register.   All DIGITAL  C SPECIAL  EDITION addresses
            are relative to this register - see section 4.16.4 . A6 is
            initialised to (task  start address + 32768)  at the start
            of task execution,  and remains unchanged.  If  you use it
            in  a  machine  code  function, be  sure  to  restore  its
            original  value  before leaving  the  function.   Relative
            addresses can be made absolute by adding A6 to them.

So the actual addresses shouldn't be that large. If I treat them as 16 bit values then printing the addresses out as just unsigned integers (i.e. %u in printf), the working version, that doesn't conform to K&R C, looks like this:

...and the broken one, that does conform to K&R C, looks like this (note the 6 as a relative address):

Later on in the manual, it talks about debugging:

Code: Select all

To assist debugging, there is an  unsupported (i.e., don't blame us if
it  doesn't  work -  use it at  your  own  risk) facility  in  the  Code
Generator/Linker.   If   you  include   a  -t   switch  in   the  Code
Generator/Linker'c command line  you will get a  symbol table listing,
with the  base relative address for  each function and  variable name.
This  is output  into  a file  on  the default  device  with a  "_sym"
extension. The addresses are only 16 bit.

[bwinkel67]

If you look on Tim Swenson's web site:
http://swensont.epizy.com/

look at the Small C Companion, here Tim talks about 2D arrays on Digital C

http://swensont.epizy.com/SmallC_Compan.pdf

That's a companion to QL's Small C not QL's Digital C SE. I think both products started with the same code base, added a floating point library, but the former stopped there whereas the latter also made parser changes by adding structs. So Tim's companion PDF talks about how to unwrap a 2D array into a 1D array, something I've already done. I'm trying to understand how Digital Precision implemented their structs to achive a truer 2D array and unfortunately I have not found any examples so far.