How I developed an Am29000 C compiler and web browser | Hacker News Reader

How I developed an Am29000 C compiler and web browser

nanochess.org

92 pointsnanochess22 comments

Fascinating. DJ Delorie rates a mention, I wonder how he's doing, I owe him a good chunk of my career.

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 remember being probably 13-14 in my bedroom late at night with nothing but the glow of a CRT while poking around with Allegro and DJGPP. I could boot into Mandrake Linux and compile the same code I wrote in Windows. It felt like anything was possible! It is one of those core memories that sticks with me.

I love the website still looks exactly like I remember it (even though I'm sure it isn't) https://www.delorie.com/djgpp/

DJGPP was a revelation. Suddenly I had real build tools, for free, and I was linking to Glide libraries and thinking I was going to be the next John Carmack.

Well done. I agree with the credits to DJ Delorie (and to Stallman, for the original GCC!).

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).

That is sad to hear. I had the pleasure of meeting him once, working with Perihelion as a student. Perihelion were a smart bunch and Helios (quasi UNIX distributed OS for Transputers) was incredibly usable and powerful for its time and hardware (Transputers lacked MMU).

This part brought back memories from an even older time:

"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".

"Can't you just ship the generated .h/.c files with the source distribution?!"

"Those take less space than lex/yacc so of course not".

GCC at the time was under GPL v2, which includes.

"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.

> "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.

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.

The output is stored in the build directory, not the source directory. So now you have to either detect that lex and yacc aren’t available and do something clever or let the user do it. And then wonder why their modifications don’t stick.

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.

> The output is stored in the build directory, not the source directory.

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)

It's all dumped into the same srcdir where the rest of the .c files live. That's how it's always been. Also, PCC does it about the same way:

    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.c

Heh. It's pilot error all the way up at the beginning. GCC releases did ship these files, and they did it by using maintainer mode, which was generally a pain for those not maintainers. Which also explains why I was confused about the build. I definitely built it with the source on read-only file systems back in the day.

https://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."

How closely related is this CPU to SPARC?

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."

They're from roughly the same era (and the same as 68020s/396s/88ks/mips) - 29ks came out of AMD and sadly didn't fly as high as we hoped at the time - their unique stack management may have been part of that

I'd say the insane bus arrangements on released chips (unrelated to ISA itself) had more to say there - the 3 & 4 bus configurations only make sense if you're throwing a bunch of extra chips onto it to make a proper CPU module that will expose sensible single bus to the world. Instead you effectively got a harvard architecture design in way that is least helpful.

I think that has more to do with the amount you could get onto a die at that time, architecturally they had to move the MMU onboard first which left the cache(s) offboard

It's more that they implemented it for higher speed as the split bus meant instruction fetches didn't block data fetches and vice versa - but it meant that without glue logic you turned a von neumann architecture into half-broken harvard one (because there's no support for copying data between the buses).

Some of the models had normal bus that didn't require unusual things like dual ported memory controller or other weirdness.

Both are based on RISC-2 design, yes.

Oscar Toledo, you are simply insane (in a good day). I bow my head in respect at the completely pointless and insanely impressive result.

>Ciega, sordomuda", "Amor de papel", “Laura no esta” and “Barbie girl”.

Oh poor soul...

https://github.com/nanochess/Am29000

This is cool, it's very Motif like.

Amazing and super detailed.

Worth to read

Amazing, you can play chess on an emulated system built in the '90s from technological "mud and straw".

It's an amazing feat of teenage engineering.

I hope you have a job working with code somewhere!

Gracias!

Reply on news.ycombinator.com