TUNIX

[pixel]

I'm struggling with finding words so:

Just a fake to spark some motivation. The terminal will have more chars in the end.

With the Lisp heap working (most idiotic misplacement of an init line it's been) and some hope of progress therefore, the plan of bringing on a self-hosting C compiler came into new light. Lots of a C compiler's code that is written in C itself must be generated unless you're blessed with a stash of diet pills in store. Oscar64 for example has tons of generated code in it, but not the generators as far as I could figure out. Did I download it from cheeky github!?!?!?
A Lisp interpreter makes that task much easier. So a Lisp interpreter it is. With no garbage collection. And it could also be the system's shell with a dedicated input mode: shell syntax if a line does not start with a parenthesis.
(I already wrote a working Lisp compiler so that's no challenge.)
Most nerds I've met just vomit "Bah! All those parens!". That's why "nerd" translates to "specialized idiot" in German (Fachidiot), I guess. In conjunction with the cregex library it'll make TUNIX dangerous.

The directory structure is now reminiscent of Unices and that's what we want on the final system. I'd like the build system to be able to run various compilers over it to target more platforms. Linux included for additional convenience. (And I'm wondering if one day someone will collaborate.)

EDIT: If you clone https://github.com/SvenMichaelKlose/tunix.git you must NOT forget to do a "git submodules update --init --recursive" before doing anything else.

[pixel]

Oh! One more thing: there is a directory called "playground" waiting for your ideas and Request For Comments. Be inspiring. Degrees in Computer Science: such people we don't want around.

[akator]

This is very impressive. I hope someone picks up the torch and writes some software for it.

[pixel]

This is very impressive. I hope someone picks up the torch and writes some software for it.

It's not only for the VIC (I forgot to mention explicitly). Up to the IBM-PC with 8088/8086 range of computers this could be interesting. Banked memory is a must. Or segmented, in the Intel case. What I wouldn't want is hardcore optimisations that spoil portability and educational purpo... ermh maintainability. That's why those >3500 lines of assembly have to go; better sooner than later. It was a mistake but a nice ride.

[srowe]

EDIT: If you clone https://github.com/SvenMichaelKlose/tunix.git you must NOT forget to do a "git submodules update --init --recursive" before doing anything else.

Or just specify submodules need to be also cloned

Code: Select all

$ git clone --recurse-submodules https://github.com/SvenMichaelKlose/tunix.git

[pixel]

Code: Select all

$ git clone --recurse-submodules https://github.com/SvenMichaelKlose/tunix.git

Yes! And I didn't mention VFORTH yet which would also be awesome to have it integrated – just a feeling as I still don't code in FORTH, which seems to be a pity.

As for the fear of doing Lisp, some 'playground' example (human-readable only (meaning bug-ridden) sketch):

Am carrying around the Dragon Book Part 1, which I found on the streets of Berlin. (My own copy was lost.) Because I want to see a sketch of a parser generator based on this. It'll be amazingly compact.

[groepaz]

Damn Lisp.... There also was a Lisp implementation Input64 mag, if you want to look at it

[pixel]

Damn Lisp.... There also was a Lisp implementation Input64 mag, if you want to look at it

Sure. Am hacking away with C tho. No tricks.

EDIT: There was an ad for it from '88, saying: "Now with Lisp compiler!". Oops.

[pixel]

Looking good. There's no reason to cons (create lists cells that need cleaning up) for the interpreter, a compacting garbage collector can take multiple turns until completion and byte numbers can be stored in pointers, so they don't blow up the show GCing all the time. The tail of the call stack can be swapped out and there's still READ/PRINT (and the Bielefeld DB) to shoot records to outer space. The one-block heap can be saved/loaded as an image and of course an app can be split up into smaller ones. All that in <1000 lines of code (empty lines, red tape, comments). Yee-hah! Now we're talking.

[pixel]

With implementing the built-ins the question is what movie to watch for soft entertainment. After a stomach-churning week (which isn't over yet) completing the GC isn't very inviting. The GC should always work as long as there're three free bytes on the heap.

Source codes: https://github.com/SvenMichaelKlose/tun ... c/lib/lisp and https://github.com/SvenMichaelKlose/tun ... c/bin/lisp

I forgot to mention that his interpreter is not a TUNIX-only thing. It would be nice if the hires terminal wouldn't have to be compiled in. Could be compiled to any platform cc65 supports (obvious exceptions ignored).

[pixel]

The 40x24 char terminal had to go. It's still a 10K binary (cc65-compiled).

[pixel]

Et voilà. Compacting mark-and-sweep GC with relocation and low memory needs. Here's the code: https://github.com/SvenMichaelKlose/tun ... /lisp/gc.c I like it.
Symbol look-ups of READ take ages with a full heap. That's bad. Also bad: in the end there'll be no more than 24K heap and each list cell needs five bytes. ~5000 conses is not a lot.

[pixel]

I'd like to be able to switch between the unnamed VI clone and the yet unnamed Lisp interpreter. "VIC VI" is unbelievably worse than "VIC-20" spoken in German and before naming things: why waste time baptizing along when it's in the TUNIX package? TUNIX-VI, TUNIX-Lisp should do, shouldn't it?

For the rare record: I've found one C compiler written in Lisp, which is "Zeta-C" running on Zeta-Lisp. The usual LIST of CONS of porting it APPLY. http://www.bitsavers.org/bits/TI/Explorer/zeta-c/ Probably an idea drowned in sugary gossip.

This time I've added a disk image with the UltiMem burn/dump/test tools, the VI clone and the Lisp interpreter which both run on any VIC with +35K. No Ultimem required. (Job of the kernel to care about it.) I picked the Markdown format for all sorts of documentation.

VI will not tell you if a file write was successful (which suddenly has become a need). The Lisp will read from file 'env.lisp' and exit. Just enough to boot a set of practical user-defined functions/basic tests. The GC does not pass a stress test (obligatory release milestone).

If you want to stay up to date with that steady stream of updates, or want to join development: that just a

Code: Select all

git clone https://github.com/SvenMichaelKlose/tunix.git
cd tunix
git submodule update --init --recursive
make clean all test

away with build-essentials and cc65 installed beforehand. On Linux, not that CP/M on steroids.

Here's your disk image:

[Wilson]

Are you aware of Soci's vi65?
I don't think the source is currently available (and I dunno if Soci would be open to sharing it), which, as a tool, makes it kind of a deal breaker for me. Nonetheless, might be worth looking into depending on how much time you want to sink into editor development. I thought it was impressive last time I played with it.

[pixel]

Are you aware of Soci's vi65?
I don't think the source is currently available (and I dunno if Soci would be open to sharing it), which, as a tool, makes it kind of a deal breaker for me. Nonetheless, might be worth looking into depending on how much time you want to sink into editor development. I thought it was impressive last time I played with it.

If your point is that you want something "impressive" I'm afraid I'm going to disappoint you for a very long time.