

8-Bit Scheme: What if the C64 was a Lisp Machine? - shawndumas
http://prog21.dadgum.com/104.html

======
SeoxyS
I find it interesting that two of my favorite programming languages are
complete polar opposites: C and Clojure.

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

~~~
Retric
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.

~~~
SwellJoe
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.

~~~
Retric
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.

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

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

~~~
brianobush
but imagine if that was all you had; no basic, just lisp. would be an
interesting parallel universe.

~~~
gouranga
I'd wee myself with delight.

The world would be a better place.

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

------
etfb
This: <http://imgur.com/vOPuq>

