Dhrystone compiled on BBQL with Digital C SE

Anything QL Software or Programming Related.
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Dhrystone compiled on BBQL with Digital C SE

Post by bwinkel67 »

Ok, given this table...things in {} are each element's value. The number at the top is the record struct's address. The first element of each struct (PtrComp) takes on that address, the next element (Discr) would have an offset of address+4 since the first element (PtrComp) is a 4-byte address.

Code: Select all

                     a)                 b)                 c)
                 +->100             +->200             +->300
                 |                  |                  |
PtrParIn{100}----+  PtrComp{200}----+  PtrComp{300}----+  PtrComp{null}
                    Discr{0}           Discr{0}           Discr{0}
                    EnumComp{0}        EnumComp{0}        EnumComp{0}
                    ...                ...                ...
Articulating my understanding verbally so you can correct me if I'm wrong:

When you do PtrParIn->PtrComp->PtrComp you are getting value 300. When you de-reference it (via &) you should be getting address 200 since the de-reference operator asks for the address instead of the value of that variable. Thus you are able to change its value (by re-referencing it via *) from 300 to some other value, i.e. *200 says go to address 200 and change the value contained at that address

(Note that *200 is not valid C syntax since you obviously never put * in front of a literal numeric address, you'd put it in front of a variable containing that address...I just did that to demonstrate my point...for those that haven't seen how de-reference/re-reference works in C, look at the last code snippet that shows how it's used.)

Code: Select all

addr1 = PtrParIn->PtrComp;              /* addr1 equals 200 */
addr2 = PtrParIn->PtrComp->PtrComp;     /* addr2 equals 300 */
addr3 = &PtrParIn->PtrComp->PtrComp;    /* addr2 equals 200 since you are asking for address of who's pointing to it */
Similarly

Code: Select all

NextRecord = PtrParIn->PtrComp; 
addr1 = NextRecord;              /* addr1 equals 200 */
addr2 = NextRecord->PtrComp;     /* addr2 equals 300 */
addr3 = &NextRecord->PtrComp;    /* addr3 equals 200 again */
If this is correct then it would seem version 1.1 of Dhyrstone had a bug since it does this:

Code: Select all

Proc3(PtrParIn->PtrComp->PtrComp);

...

Proc3(PtrParOut)
RecordPtr * PtrParOut;
{
   *PtrParOut = 400;     /* this would change what is at address 300 */
}
Whereas version 2.0 of Dhrystone does this (note the & in the Proc3 function call):

Code: Select all

NextRecord = PtrParIn->PtrComp;
Proc3(&NextRecord->PtrComp);

...

Proc3(PtrParOut)
RecordPtr * PtrParOut;
{
   *PtrParOut = 400;     /* this would change what is at address 200 */
}
Last edited by bwinkel67 on Tue Aug 09, 2022 1:01 am, edited 7 times in total.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Dhrystone compiled on BBQL with Digital C SE

Post by tofro »

bwinkel67 wrote: (Note that *200 is not valid C syntax since you obviously never put * in front of a literal numeric address, you'd put it in front of a variable containing that address...I just did that to demonstrate my point.)
*200 is in fact (sort of) valid C if you decorate it with some type cast, e.g.;

Code: Select all

  *((RecPtr)200) = 0;
bwinkel67 wrote:
If this is correct then it would seem version 1.1 of Dhyrstone had a bug since it does this:
Too late for me to really verify... But I guess for a benchmark it is somewhat irrelevant what pointer exactly is read or modified - the benchmark simply wants to check how fast the dereferencing code in a compiler runs.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Dhrystone compiled on BBQL with Digital C SE

Post by bwinkel67 »

tofro wrote: *200 is in fact (sort of) valid C if you decorate it with some type cast, e.g.;

Code: Select all

  *((RecPtr)200) = 0;
Oh, you can actually do that...well that is why we all just love C! :-)
tofro wrote:Too late for me to really verify... But I guess for a benchmark it is somewhat irrelevant what pointer exactly is read or modified - the benchmark simply wants to check how fast the dereferencing code in a compiler runs.
I need to see if it could impact the timing. When it does struct copies it does use the size of the struct, so it shouldn't copy more or less. It doesn't reset the variables after the first of 50,000 iterations and it does use some struct fields to make decisions on paths through the code, so conceivably it could cause issues. But I suppose if it hasn't come up before likely that wasn't the case.

Anyways, for the QL, it does cause issues since it's writing to screen memory for my Digital C SE compilation. Not sure why Metacomco's compilation doesn't. I just want to be sure I'm comparing apples to apples with Digital C SE vs Metacomco and the latter isn't taking any shortcuts due to that bug.


mfro
ROM Dongle
Posts: 5
Joined: Sun Jun 13, 2021 7:38 am

Re: Dhrystone compiled on BBQL with Digital C SE

Post by mfro »

bwinkel67 wrote:... On a 64 bit system, short would be 16 bits, int would be 32 bits, and long would be 64 bits...
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.

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.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Dhrystone compiled on BBQL with Digital C SE

Post by tofro »

mfro wrote: 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.
By that measure, unfortunately none of the QL C compilers except cross-gcc qualify as "reasonably modern".


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Dhrystone compiled on BBQL with Digital C SE

Post by bwinkel67 »

The rule of thumb with regard to bit size is short <= int <= long <= long long, etc... But yes, it's much easier when dealing with old systems since on the QL via Digial C SE it's 16 bits for int and 32 bits for long. Always good to know the compiler and platform one compiles on.


User avatar
XorA
Site Admin
Posts: 1358
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Dhrystone compiled on BBQL with Digital C SE

Post by XorA »

bwinkel67 wrote:The rule of thumb with regard to bit size is short <= int <= long <= long long, etc... But yes, it's much easier when dealing with old systems since on the QL via Digial C SE it's 16 bits for int and 32 bits for long. Always good to know the compiler and platform one compiles on.
That’s not a rule of thumb it’s literally what’s in the spec but specified in greater than terms.


User avatar
bwinkel67
QL Wafer Drive
Posts: 1187
Joined: Thu Oct 03, 2019 2:09 am

Re: Dhrystone compiled on BBQL with Digital C SE

Post by bwinkel67 »

Maybe it's greater than in the current spec but that's not always been the case. I have certainly used compilers where short and int were the same size.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Dhrystone compiled on BBQL with Digital C SE

Post by mk79 »

mfro wrote: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. :D
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. But this is it:

Code: Select all

#ifndef _STDINT_H_
#define _STDINT_H_

typedef char int8_t;
typedef short int16_t;
typedef long int32_t;
typedef long ssize_t;
typedef long intptr_t;

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;
#ifndef _SIZE_T
#define _SIZE_T
typedef unsigned long size_t;
#endif
typedef unsigned long uintptr_t;

#endif


User avatar
XorA
Site Admin
Posts: 1358
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: Dhrystone compiled on BBQL with Digital C SE

Post by XorA »

bwinkel67 wrote:Maybe it's greater than in the current spec but that's not always been the case. I have certainly used compilers where short and int were the same size.
Short and int may be the same size and that has always been allowed. Since 1978 spec short mist be shorter or equal in size to long.

In 1988 short must be shorter or equal in size to int which must be shorter or equal in size to long.

In newer specs which i dont have to hand i think they turned it around so long >= int >= short.

But i think the concept predates the QL significantly. So i return to my statement, its NOT a rule of thumb.


Post Reply