8-Bit Scheme: What if the C64 was a Lisp Machine?(prog21.dadgum.com)
prog21.dadgum.com
8-Bit Scheme: What if the C64 was a Lisp Machine?
http://prog21.dadgum.com/104.html
5 comments
If you like C, I would suggest you spend some time with assembly. With C your stuck with both the compilers oddity's and the processors oddity's where with ASM you can really dig in and discover a host of occasionally useful but often strange behaviors.
This sounds like superstition, borne of lack of experience with C.
I'm not saying assembly isn't interesting, or worth learning (to some degree). I spent quite a bit of my youth poking at 6510 and 68000 assembly (C64 and Amiga, respectively). But, I don't think it was more enlightening than my first few weeks with K&R, which were eye-opening on a whole other level. It's just misses the point to say C has oddities or whatever; maybe just say that learning a little assembly can be fun and useful, and leave it at that.
I'm not saying assembly isn't interesting, or worth learning (to some degree). I spent quite a bit of my youth poking at 6510 and 68000 assembly (C64 and Amiga, respectively). But, I don't think it was more enlightening than my first few weeks with K&R, which were eye-opening on a whole other level. It's just misses the point to say C has oddities or whatever; maybe just say that learning a little assembly can be fun and useful, and leave it at that.
It's not that hard to find cases in C where x=a+b; y=c+d; is slower than x=a+b; y=c+d;. What that happens has very little to do with C you really do need to dig down a level to understand what's going on. That said, the C compiler was optimized for a range of diffrent CPU's all with their own preferences so it will swap some instructions around to help you along, but it's not prefect which is IMO some of the oddities's associated with C.
68000 assembly is vary different from x86-64. x86-64 has a huge instruction set with a lot of legacy crap, multiple execution units even on a single core chip, does out of order instructions etc. Just poke around http://sandpile.org/ for a few minutes and you will probably learn something new. Then read up on L1 cache which is a vary strange beast that's fast etc.
68000 assembly is vary different from x86-64. x86-64 has a huge instruction set with a lot of legacy crap, multiple execution units even on a single core chip, does out of order instructions etc. Just poke around http://sandpile.org/ for a few minutes and you will probably learn something new. Then read up on L1 cache which is a vary strange beast that's fast etc.
Have you ever tried Forth or Factor?
Hopefully, a Lisp implementation that doesn't use tag bits for type & GC.
At those low machine word lengths, every bit is precious. E.g. if you take 2 bits for type and 1 for GC, you're left with 5 bits, or a total of 32 unique values representable by the machine (30 if you take take out NIL & T.) Useful for a desk calculator, not much else.
At those low machine word lengths, every bit is precious. E.g. if you take 2 bits for type and 1 for GC, you're left with 5 bits, or a total of 32 unique values representable by the machine (30 if you take take out NIL & T.) Useful for a desk calculator, not much else.
Some of us did have 8 bit LISP machines, in my case AcornSoft LISP on a BBC master (a Cray compared to a c64).
http://en.m.wikipedia.org/wiki/Acornsoft_LISP
The implementation was pretty bare but it was fast and very useful.
http://en.m.wikipedia.org/wiki/Acornsoft_LISP
The implementation was pretty bare but it was fast and very useful.
but imagine if that was all you had; no basic, just lisp. would be an interesting parallel universe.
I'd wee myself with delight.
The world would be a better place.
The world would be a better place.
Could an 8 bit lisp in 64k (more like 32k once video memory and things were taken care of) offered competitive gaming performance? If not, the machine would have ripely sunk without a trace. I can't imagine the performance would be acceptable, in a world of cycle-specific algorithms, which would often keep track of te current position along a scan line. But, perhaps, I have insufficient lisp imagination.
On the one hand I love the high-level abstraction of Clojure. I love its homoiconicity. I love functional programming, being able to map, reduce, apply, etc.
On the other hand is C, where I can handle the raw power of the computer. Where I know exactly what I'm doing. Where I can play with single bits and dribble pointers around. Where there is no magic GC or dynamic type systems to fuck me over at just the wrong time.
I'm constantly trying to reconcile those two worlds; making my C code as functional as possible (libdispatch and blocks are a great addition to the language).