4 ms·

They wrote this in two months? In assembly? Impressive! I wonder if they used code generators or wrote plain assembly?

compiler-guy 5y ago
Everyone wrote plain assembly in those days. If you were lucky your assembler did nice things like symbolic constants. It was a skill pretty much everyone knew.
jll29 5y ago
It's fair to assume this is handcrafted and hand-optimized code, as machines back then were typically too small to use for many tasks. Any code generated would have added bloat making the whole project untenable.
PaulHoule 5y ago
Assembly language isn't that hard. I wrote a FORTH interpreter with a pretty good standard library in 3000 lines of 6809 assembly that pretty much worked right the first time. Today you could spend as much time getting the build to work with npm or maven for something very simple. Macro assemblers are nowhere near as much fun on the x86 (and other 80's era micros) as they are on something like the IBM 360 or AVR8 with a big register file... If you've got 32 registers you can write macros where the register names are parameters and avoid a lot of the meaningless activity involved in "calling conventions" in programming languages like C.
- Mountain_Skies 5y ago
  Was the FORTH interpreter for your own use or did you sell it? I ask because it's always fun to see someone on HN that wrote products I saw in the pages of Rainbow long ago.
  - PaulHoule 5y ago
    It was for my own use. It was unusual in quite a few ways. For one thing it was subroutine threaded which made it a little faster than most FORTHs, also it used self-modifying code in an inner loop to save a cycle in an important place. Most FORTHs at the time used block-based disk I/O because you could do that without a real operating system and have some nice benefits such being able to copy a block of source code to the screen buffer to edit in place, easy memory allocation, etc. OS-9 had a handle-based API for filesystem access basically the same as UNIX and MS-DOS 2.0 so my FORTH used that. OS-9 had a choice of text editors, including a vi clone so I didn't feel the need to embed an editor in the interpreter.

Everyone wrote plain assembly in those days. If you were lucky your assembler did nice things like symbolic constants. It was a skill pretty much everyone knew.

jll29 5y ago

It's fair to assume this is handcrafted and hand-optimized code, as machines back then were typically too small to use for many tasks. Any code generated would have added bloat making the whole project untenable.

PaulHoule 5y ago

Assembly language isn't that hard. I wrote a FORTH interpreter with a pretty good standard library in 3000 lines of 6809 assembly that pretty much worked right the first time. Today you could spend as much time getting the build to work with npm or maven for something very simple. Macro assemblers are nowhere near as much fun on the x86 (and other 80's era micros) as they are on something like the IBM 360 or AVR8 with a big register file... If you've got 32 registers you can write macros where the register names are parameters and avoid a lot of the meaningless activity involved in "calling conventions" in programming languages like C.

Mountain_Skies 5y ago
Was the FORTH interpreter for your own use or did you sell it? I ask because it's always fun to see someone on HN that wrote products I saw in the pages of Rainbow long ago.
- PaulHoule 5y ago
  It was for my own use. It was unusual in quite a few ways. For one thing it was subroutine threaded which made it a little faster than most FORTHs, also it used self-modifying code in an inner loop to save a cycle in an important place. Most FORTHs at the time used block-based disk I/O because you could do that without a real operating system and have some nice benefits such being able to copy a block of source code to the screen buffer to edit in place, easy memory allocation, etc. OS-9 had a handle-based API for filesystem access basically the same as UNIX and MS-DOS 2.0 so my FORTH used that. OS-9 had a choice of text editors, including a vi clone so I didn't feel the need to embed an editor in the interpreter.