How many times is this going to happen? Sometimes I lose a whole day or more having to reinstall everything, that is to say when they not only manage to nerf the updates, but they implode the system restore points. Hopefully, they didn't do to much damage this time. Otherwise, UCSD Pascal is getting closer to actually being able to compile programs for the Propeller or maybe for one of those 100Mhz 6502 things, or whatever - so that while a NOR computer would certainly be interesting, an FPGA-based something or another would be more likely.
As expected, the fact that the UCSD compiler has some deeply nested procedures, which because of the nature of the language might also be recursive, does present an interesting challenge - since C/C++ does not allow "local functions" that it otherwise considers illegal. So an interesting question therefore is whether it is even possible to convert some Pascal programs without extensive re-architecting of the overall design of an application, such as by requiring the use of lambdas, or tables of function pointers, (which I like - but not if we don't have that level of sugar coating available for use with microcontrollers - yet) - or adding a passed parameter for frame tracking to each and every function - which is a pain in the ass - as when let's say - procedure A calls nested procedures B and C recursively, as if to implement 99 bottles of beer on the wall on the stack, and then when an "out of beer" exception should occur, either the "pull one down" or "pass it around" functions have to call some other functions, let's call them D and E and F, where E and F are inside of D, which is also inside of A, and then a callback to A might result in - well you get the idea, a fresh call to B or D - and then the compiler has to somehow generate code that preserves the invocation record for the entire call history, so that just in case the latest E wants to access a variable from the most recent B or C, is that even possible? What a mess!
So when I ask is it possible, I mean is it possible to go into a Pascal program and simply use find and replace to replace all of the BEGINs and ENDs with curly braces, and otherwise simply pour a little sugar on where it is needed to deal with WITH statements and the rest - but otherwise leave the body of the Pascal procedures exactly as written, that is to say so that most of the re-write can be done with find and replace in a word processor?
Interestingly enough - it appears that the answer is YES - and that something like this does the trick!
class DECLARATIONPART::USESDECLARATION:
public DECLARATIONPART
{
protected:
struct SEGDICT
{
DCREC DANDC[MAXSEG];
ALPHA SEGNAME[MAXSEG];
int SEGKIND[MAXSEG];
int TEXTADDR[MAXSEG];
int FILLER[128];
};
bool FOUND;
int BEGADDR;
CTP LCP;
LEXSTKREC LLEXSTK;
ALPHA LNAME;
SYMBOL LSY;
OPERATOR LOP;
ALPHA LID;
protected:
USESDECLARATION(bool MAGIC);
void GETTEXT(bool &FOUND);
};
So in the original Pascal source "USESDECLARATION" is a procedure that takes exactly one BOOLEAN parameter called "MAGIC", and then "USESDECLARATION" needs to be able to call a nested function called "GETTEXT" which in turn needs to be able to access some of the local variables that were previously declared in the outer procedure, which of course is being called from another outer procedure called "DECLARATIONPART", and then there are other examples where the mess just might turn out to be as bad, or worse than trying to implement ninety-nine bottles of beer on the wall using recursion for the functions "pull", "pass", "sip", etc., and get a bunch of "customer" objects, "bottle" objects, and others to work nicely with each other - that is until you run out of beer, or diet soda!
So apart from running these posts on popcorn, pizza, and Diet Coke while Windows takes an occasional respite, the approach that I am now taking is to go ahead and continue with trying to devise an even more generic programming route with the design for the APIs that I am eventually going to be running entirely on the Propeller "standalone" - even though we don't have C++ for the Propeller yet - but as stated in an earlier post - if it does indeed appear that technically we don't need floating point, or strings or any data type other than perhaps BYTE or WORD - and yet C++ is powerful enough that with templates, macros, and operator overloading it is actually possible to define REAL. and SETS, and RANGES, and generate a "close to the metal" implementation that should work on any platform - including the so-called "NOR" computer!
Then why not?
void DECLARATIONPART::TYP::FIELDLIST::ALLOCATE(CTP FCP)
{
bool ONBOUND;
ONBOUND=false;
// WITH FCP^) {
if (PACKABLE(FCP->IDTYPE))
{
if ((NUMBITS + NEXTBIT)>BITSPERWD)
{
DISPL=DISPL + 1;
NEXTBIT=0;
ONBOUND=true;
}
FCP->FLDADDR=DISPL;
FCP->FISPACKED=true;
FCP->FLDWIDTH=NUMBITS;
FCP->FLDRBIT=NEXTBIT;
NEXTBIT=NEXTBIT + NUMBITS;
}
else
{
DISPL=DISPL + ORD(NEXTBIT>0);
NEXTBIT=0;
ONBOUND=true;
FCP->FISPACKED=false;
FCP->FLDADDR=DISPL;
if (FCP->IDTYPE!=NULL)
DISPL=DISPL + FCP->IDTYPE->SIZE;
}
if (ONBOUND&& (LAST!=NULL))
// WITH LAST^
if (FCP->FISPACKED)
if (FCP->FLDRBIT==0)
FCP->FISPACKED=false;
else if ((FCP->FLDWIDTH<=8)&&(FCP->FLDRBIT<=8))
{
FCP->FLDWIDTH=8;
FCP->FLDRBIT=8;
}
} /*ALLOCATE*/
So THIS is how the Pascal compiler allocates the data structures needed to handle packed arrays at compile time. Except this is C++ - and it compiles! Stay tuned!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.