Hacker News Reader

Comment by PaulHoule | Hacker News Reader

Personally I see the use of a cross-compiler and other dev tools on a bigger machine as even more retro than running them in an 8-bit micro because it is what many software vendors did at the dawn of the microcomputer age.

Also if you like the Z80 you should try

https://en.wikipedia.org/wiki/Zilog_eZ80

Which is crazy fast not to mention the only 8-bit architecture that got extended to 24-bit addressing in a sane way with index registers. (Sorry the 65816 sucks)

View on HN

> because it is what many software vendors did at the dawn of the microcomputer age.

They really didn't have any choice if they wanted to actually accomplish something.

The 8-bit machines of the day, CP/M running 1-2MHz 8080s, 2-4MHz Z80, with no memory, and glacial disk drives (with not a lot of capacity).

Go ahead and fire up a CP/M simulator that lets you change the clock rate, and dial it down to heritage levels (and even then it's not quite the same, the I/O is still too fast). Watching the clock tick by as you load the editor, load the file, make your changes, quit the editor, load the compiler, load the linker, test the program, then back to the editor. There is friction here, the process just drrraaagggsss.

Turbo Pascal was usable for small programs. In memory editor, compiling to memory, running from memory. Ziinng! Start writing things to disk, and you were back to square one. The best thing Turbo did was eliminate the linking step (at the cost of having to INCLUDE and recompile things every time).

It was a different time.

As someone who lived through that, we simply didn't know any better. Each generation got incrementally faster. There were few leaps in orders of magnitude.

But going back, whoo boy. Amazing anything got accomplished.

Yeah, all my learnings were from books, bought or local library, computer magazines, and occasional demoscene meetings.

I was able to connect to BBS only during the summer internship I did, at the end of my vocational school training in computer programming.

When I afterwards arrived into the university, Gopher was still a thing.

Lots of paper based programming, and wild guessing, there was no Stack Overflow to help us out.

But you could learn BASIC, or Pascal, or C from one pretty thin book. And you could learn pretty much all of the language from that thin book.

There was less to learn, and so you could learn it pretty thoroughly from more meager resources.

That was the easy part, coming up with algorithms, data structures (what is that?), and the actual hardware and OS mappings, was already beyond that book.

Until I got hold of Input magazines collection, I was pretty much stuck with my Timex 2068 manual, and its set of demos.

It is like learning a foreign language from a dictionary without anything else, until someone else shows the structure of the sentences.

So true. My first parser was for a little text adventure I wrote. I didn't know parsing was a thing people might write about, so I just muddled through some text manipulation in Atari BASIC it until it worked. Even sorting was something you just had to figure out - I managed to come up with bubble sort on my own, presumably like many others did in those days, unaware that sorting was well-trodden territory.

Android development with an emulator on my 8-core 64Gb desktop system feels a bit like this nowadays

I gave up on Android side projects, however during the time I still cared, I always had the impression the Android team must use gamming rigs maxed up for their development, our desktops never seem to be good enough, and the irony is that I can confortably do plain Java development on my oldie 2009 dual core laptop with 16 GB.

One of my dev machines for Android dev is a MacBook Air 2017 (8 GB RAM).

Not super fast obviously, but still okay-ish. Just don't use emulator and debug on real device instead. Well, not that bad.

I got paid to develop some software for a teacher at my school and wrote it in some kind of basic (GWBASIC?) for my IBM PC AT clone, then found out she had a CP/M machine.

I had just read in Byte magazine that there was a good CP/M emulator that ran several times faster than any real CP/M system already in 1988 or so. So I used that software to run a CP/M environment and port the code to some BASIC variant there.

> They really didn't have any choice if they wanted to actually accomplish something.

microsoft in particular did their initial development of altair basic on harvard's pdp-10, using pdp-10 assemblers and debuggers; not only did they not have an altair, nobody had an altair

but an awful lot of pc software was written on pcs. woz wrote integer basic on the apple. bds c was assembled on cp/m. probably the majority of pc developers didn't have access to a bigger computer

those who did had an advantage, but sometimes it backfired. i remember the ucsd p-system as being unbearably slow, and i suspect that part of the reason was that its authors didn't empathize enough with their users' frustration to commit the efficiency hacks used by systems like eumel and basic-80

One of the first CP/M C's was BDS-C. It's claim to fame was that it compiled the source in-memory, so it was at least that part was nice and fast.

Certainly compared to Whitesmiths C for CP/M, and not just for the $700 price vs $150 for BDS-C. Whitesmiths was real, official C, direct from P. J. Plauger and V6 Unix. But each compile went through many, many, many passes on the poor floppy (including pseudo-assembly "A-Natural" for the 8080 that then translated to real assembly). Everybody complained that while very professional, it just took too long to go through the cycle.

Contemporary BYTE recommendation was to develop & iterate on BDS-C, then at the end re-compile on Whitesmiths to squeeze the best performance.

Which if you come to think of it, fits quite naturally 40 years later, in having combined JIT / AOT toolchains for most compiled languages.

Pity that only Visual C++ seems somehow close to Energize C++ and Visual Age for C++ v4, for that kind of incremental development experience. Live++ and ROOT aren't that widespread.

Also D has a similar approach, use dmd for development, ldc or gdc for release.

Heh. My favorite was at my first job (late 1980s). A small Xenix system was used for development, with PCs as terminals. Since the Xenix box didn't have that much horsepower, our compiles involved shooting intermediate code down the serial line, having the compiler second pass run on the PC, and shoot the .OBJ back up the line for linking - yes, it was faster to do that. We had our own compilers, which were dreadfully obsolete by that time; for instance, the C compiler used UNIX V6-style arithmetic, with library functions to deal with calculations for types other than int.

Reply on news.ycombinator.com