[OT] 8-bit machines (was: double vs float vs int)

[David Given <dg@...>]

Jay Carlson wrote:
[...]
> Knowing what we know now about language design, user interfaces, and 
> extensibility, what kind of programming environment would we create for 
> the 8-bit microcomputers?

Way off topic, but this is something I've often thought about. I do actually 
own an NC200, a Z80-based laptop with 128kB of RAM, a 1MB solid-state disc and 
a 720kB floppy drive; it runs a proprietry OS, but I keep wondering about 
writing my own modern OS on it. It would make an ideal test-bed, and would be 
perfect for teaching embedded systems programming. Alas, I doubt Lua would run 
on it.

Incidentally, there will *always* be a market for 8-bit micros. They just get 
smaller and cheaper as time passes. You tend to find them in places where you 
wouldn't expect to find computers: digital watches, clocks, remote controls, 
anything that might need to watch inputs and control an output. These days, 
rather than designing a logic circuit to do the job, it's easier to stamp out 
an 8-bitter and do it in software. It won't be long until nanotechnology makes 
them *really* small.

(Has the 4004 finally died?)

[...]
> Scaling down is important.  Let's say we have a luxurious 16k of 6502 
> ROM, and have to do *something* useful in 16k of RAM.  (I'm picking 16k 
> because the VIC-20 was sorta hopeless, and you needed about 12k to use 
> Applesoft.)  Oh, and secondary storage may be slow and far away---don't 
> count on software virtual memory, as the user may only have a tape drive.

The main thing to do is to determine when speed is more important than size. 
Check this out:

http://www.6502.org/source/interpreters/sweet16.htm

It's a 16-bit VM implemented in 300 bytes by Woz himself for the Apple II, 
designed to allow easy interleaving of Sweet16 code with native 6502 
instructions. It allows you to take the non-speed-critical parts of your 
program and shrink them vastly. Not only does this give you more code and data 
space, Sweet16 is far easier to write. It's got sixteen 16-bit registers and 
most opcodes are one byte.

> Before you ask, FORTH is not acceptable, as it's too easy to blow up the 
> machine.

But on an 8-bit machine, it's *always* easy to blow up the machine. Forth is 
ideal for these devices: it's small (compiled Forth programs are typically 
*smaller* than native machine code versions), it's fast, it's portable, it's 
scalable, it's easily integrated with native code, and it's easy to write. (If 
you have the right mindset. I don't, and personally, I can't stand it. I tried 
to teach myself Forth at one point and I found myself spending all my time 
fighting the stack rather than working with it.)

Alas, modern programming languages don't fit these machines well. I have a C 
compiler for my Z80 machine which produces foul code. (The Z80 has no 
stack-relative addressing mode, and C uses the stack heavily... sigh.) 6502 C 
compilers tend to be even worse. What fast, compiled languages are there for 
these machines?

--
[insert interesting .sig here]