This reads very much like the same journey I made recently when reviving my old OS, only Oscar went much further than I did and wrote a working browser as well, which - even though the browsers back then were much simpler - is extremely impressive. I still have a stack of disks from those days, I should probably find a way to read them to see what's on there.
edit: I sent DJ Delorie a short note, I should have done that years ago, without him I would have never managed.
I love the website still looks exactly like I remember it (even though I'm sure it isn't) https://www.delorie.com/djgpp/
The code of the O.P. is actually not so bad for a teenager; however, the variables in Spanish do not help: "[isq]" and "[der]" probably stood for "isqierda" and "derecha", so the index of the left and right subtree of an expression.
Speaking of Transputers, Dr. Tim King, founder of Perihelion, was another big name of the Transputer times; he sadly passed away last month (he also wrote Tripos, which turned into AmigaDOS).
"Worst, it required two more programs: Flex and Bison."
In the early 80s I had the idea to port a C compiler to a new machine (I forget if this was K&R or pcc, but those were the only two C compilers you could get the source for at the time, legal issues aside...). At some point I had that same realization: uhh...this thing needs two other pretty big things: yacc and lex. The "first catch your fish" of compilers: "first port the parser-generators".
"Those take less space than lex/yacc so of course not".
"The source code for a work means the preferred form of the work for making modifications to it."
For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms. Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time.
> For lex and yacc, that means the original .y and .l files. You don't have a choice if you want to be compliant with the terms.
Okay? I don't say "drop .y and .l files", I say "throw in the .h and .c produced from them as well into the tarball distribution".
> Also, shipping the .h and .c files in addition also ends up confusing the build systems of the time.
How?! If it were true, then merely having them in the source directory after running "make" for the first time would also break the build which obviously is not something that ever happened.
You also have to ensure that every time you update the .y file, you update another file in the source tree, when it’s really part of the build.
It’s annoying and would be similar to the maintainer mode builds that used to happen and confuse people.
It can be done, but the benefits are low. Most systems back in the day had lex and yacc available. Systems that didn’t, but also that needed a compiler were rare, and the vast majority of the time you just cross compiled in those situations.
No, it's not.
c-parse.o : $(srcdir)/c-parse.c $(CONFIG_H) $(TREE_H) c-lex.h $(GGC_H) intl.h \
$(C_TREE_H) input.h flags.h system.h toplev.h output.h cpplib.h
$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) -c $(srcdir)/c-parse.c
$(srcdir)/c-parse.c: $(srcdir)/c-parse.y
(cd $(srcdir) && $(BISON) $(BISONFLAGS) -o c-p$$$$.c c-parse.y && \
mv -f c-p$$$$.c c-parse.c)
$(srcdir)/c-parse.y: c-parse.in
echo '/*WARNING: This file is automatically generated!*/' >tmp-c-parse.y
sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \
-e "/^ifc$$/d" -e "/^end ifc$$/d" \
$(srcdir)/c-parse.in >>tmp-c-parse.y
$(SHELL) $(srcdir)/move-if-change tmp-c-parse.y $(srcdir)/c-parse.y
$(srcdir)/tradcif.c: $(srcdir)/tradcif.y
(cd $(srcdir) && $(BISON) $(BISONFLAGS) -o tr$$$$.c tradcif.y && \
mv -f tr$$$$.c tradcif.c)
srcdir=.
top_srcdir=../..
cgram.c: $(srcdir)/cgram.y
$(YACC) $(YFLAGS) -d $(srcdir)/cgram.y
mv -f y.tab.c cgram.c
mv -f y.tab.h cgram.h
scan.c: $(srcdir)/scan.l
$(LEX) $(LFLAGS) $(srcdir)/scan.l
mv -f $(LEX_OUTPUT_ROOT).c scan.c
$(OBJS): $(HDRS) external.c cgram.c
cgram.o: cgram.c
$(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ cgram.c
scan.o: scan.c
$(CC) $(CF0) $(CFLAGS) $(CPPFLAGS) -c -o $@ scan.chttps://www.gnu-pascal.de/standards.html (from 2000.)
"Naturally, all the source files must be in the distribution. It is okay to include non-source files in the distribution, provided they are up-to-date and machine-independent, so that building the distribution normally will never modify them. We commonly include non-source files produced by Bison, lex, TeX, and makeinfo; this helps avoid unnecessary dependencies between our distributions, so that users can install whichever packages they want to install."
https://en.wikipedia.org/wiki/AMD_Am29000
"Based on the seminal Berkeley RISC, the 29k added a number of significant improvements... One design element used in some of the Berkeley RISC-derived designs is the concept of register windows, a technique used to speed up procedure calls significantly."
Some of the models had normal bus that didn't require unusual things like dual ported memory controller or other weirdness.
Oh poor soul...
https://github.com/nanochess/Am29000
This is cool, it's very Motif like.
Worth to read
It's an amazing feat of teenage engineering.
I hope you have a job working with code somewhere!
Gracias!