Looking further at my Digital C SE implementation of Dhrystone, since it seems to be writing to screen memory when running on my actual BBQL (i.e. I get little dots in the middle of my screen), I went over the code to figure out why. So in both of Franz Krojer's implementations of Dhrystone, version 1.1 (compiled with Metacomco) and version 1.2 (compiled with C68), it has the following code snippet (I marked up the two lines of interest with /* <-- ??????? */):
Code: Select all
struct Record {
struct Record* PtrComp;
Enumeration Discr;
Enumeration EnumComp;
OneToFifty IntComp;
String30 StringComp;
};
typedef struct Record RecordType;
typedef RecordType* RecordPtr;
...
void Proc1(PtrParIn)
REG RecordPtr PtrParIn;
{
#define NextRecord (*(PtrParIn->PtrComp))
structassign(NextRecord, *PtrGlb);
PtrParIn->IntComp = 5;
NextRecord.IntComp = PtrParIn->IntComp;
NextRecord.PtrComp = PtrParIn->PtrComp;
Proc3(NextRecord.PtrComp); /* <-- ??????? */
if (NextRecord.Discr == Ident1) {
NextRecord.IntComp = 6;
Proc6(PtrParIn->EnumComp, &NextRecord.EnumComp);
NextRecord.PtrComp = PtrGlb->PtrComp;
Proc7(NextRecord.IntComp, 10, &NextRecord.IntComp);
} else
structassign(*PtrParIn, NextRecord);
#undef NextRecord
}
...
void Proc3(PtrParOut)
RecordPtr* PtrParOut; /* <- this is equivalent to having 2 asterisks, i.e.: struct Record** PtrParOut; */
{
if (PtrGlb != NULL)
*PtrParOut = PtrGlb->PtrComp; /* <-- ??????? */
else
IntGlob = 100;
Proc7(10, IntGlob, &PtrGlb->IntComp);
}
Looking at this code, I was confused by the lines marked with /* <-- ??????? */ because in Proc3() you have a pointer to RecordPtr (i.e. RecordPtr*) and in Proc1() you are only sending a RecordPtr (i.e. the types misalign). That's critical because in Proc3() you then re-reference that pointer to set it -- but you never de-referenced it when calling the function, so it never gets updated in Proc1() and any subsequent code that uses that variable (it's tied to a global) may be looking at a NULL pointer, which could cause things to speed up a bit since you may now no longer follow a linked-list of record pointers (I need to figure out if that's the case).
Looking here at some original source with comments:
https://github.com/Keith-S-Thompson/dhr ... ces/dhry-c
It verifies my hunch as in Proc1() they add a de-reference operator to the Proc3() call:
Code: Select all
Proc_1 (Ptr_Val_Par)
REG Rec_Pointer Ptr_Val_Par;
{
REG Rec_Pointer Next_Record = Ptr_Val_Par->Ptr_Comp;
structassign (*Ptr_Val_Par->Ptr_Comp, *Ptr_Glob);
Ptr_Val_Par->variant.var_1.Int_Comp = 5;
Next_Record->variant.var_1.Int_Comp = Ptr_Val_Par->variant.var_1.Int_Comp;
Next_Record->Ptr_Comp = Ptr_Val_Par->Ptr_Comp;
Proc_3 (&Next_Record->Ptr_Comp); /* <-- ??????? */
if (Next_Record->Discr == Ident_1) {
Next_Record->variant.var_1.Int_Comp = 6;
Proc_6 (Ptr_Val_Par->variant.var_1.Enum_Comp,
&Next_Record->variant.var_1.Enum_Comp);
Next_Record->Ptr_Comp = Ptr_Glob->Ptr_Comp;
Proc_7 (Next_Record->variant.var_1.Int_Comp, 10,
&Next_Record->variant.var_1.Int_Comp);
}
else
structassign (*Ptr_Val_Par, *Ptr_Val_Par->Ptr_Comp);
}
That code changed it a bit to get rid of that ugly #define that, when expanded, causes a messy looking procedure call in the first code example, i.e.
Code: Select all
Proc3((*PtrParIn->PtrComp).PtrComp);
...which is equivalent in C to:
Code: Select all
Proc3(PtrParIn->PtrComp->PtrComp);
...yes, not very pretty code.
Just curious if I'm mis-reading the QL Metacomco C and C68 code here? Anyone with a good C background that has used either of these QL C compilers have an idea if I'm right or wrong here?