TUNIX Lisp (continued)

Other Computers and Game Systems

Moderator: Moderators

Post Reply
User avatar
pixel
Vic 20 Guru
Posts: 1548
Joined: Fri Feb 28, 2014 3:56 am
Location: Bielefeld, Germany

TUNIX Lisp (continued)

Post by pixel »

I didn't post recent releases as it's working on POSIX-compatibles and the C64 only. https://github.com/SvenMichaelKlose/tun ... angelog.md

TUNIX Lisp https://github.com/SvenMichaelKlose/tun ... /manual.md is an interpreter designed to run on systems with next to no CPU stack, like the 6502, and it's written in ANSI-C (cc65). Unless it can compile itself to bytecode it's too slow to for even small apps on CBMs or CP/Ms or whatever else in danger of getting sucked up by the vacuum cleaner. Theoretically it could all be running on any slide rule with an ANSI-C compiler's support. The development history will probably entertain mental health professionals for decades to come. It'll be great. 8) Because:

# Autoloader

Works very well. Throw out macros and functions if running out of heap and have things re-loaded on demand. Priceless on constrained systems and bringing more comfort.

# 6502 assembler

I've been using my own Lisp-based assembler where no-one should have. A new way of integrating it into Lisp, with no messy parsing, is simplifying the task a lot and that's fun to hack with. Especially when it comes to generate speed code. No compiling Lisp to native code intended (yet). Ideal for a constrained system.

# Dot-notation

Having been around for ages (in tré) it helps to muffle 1B transformer comments like "too many parens": (car x) is x., (cdr x) is .x, (cadr x) is .x, (cddr x) is ..x, and so on and object.method translates to "(slot-value object 'method)" which is actually "(cdr (assoc 'method object))".

# Object system

SLOT-VALUE treating associative lists is no accident. It's the basis for a weirdly inheriting nerd-typed object system (if you poke it and it bites it's a nerd). Also done with a handful lines of code. Here comes the cute thing: the tré Lisp compiler is using STRUCTs. It's super-noisy code for which I deserve to get bitch-slapped around, and it has no object system for its Common LISP target. So that object system is going in to tré as well. That's already working compiler code becoming available for TUNIX more readily.

# Packaging

You can have symbols of a package prefixed with the package name to make a relative path for AUTOLOAD, so apps can be placed in subdirectories of the environment. Also, just a handful of code.

# What to do with it?

You can launch the C64 version, type "(test-all)" into it and meditate for 15 minutes, or launch the Linux version for more heap and actual development.
You're also welcome to rant and recommend. https://github.com/SvenMichaelKlose/tunix/tree/main.

The C64 version is seconds away from becoming ultra-slow to keep things simple until we get our bytecode compiler to remove performance issues anyway.

Have fun!
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
User avatar
pixel
Vic 20 Guru
Posts: 1548
Joined: Fri Feb 28, 2014 3:56 am
Location: Bielefeld, Germany

Re: TUNIX Lisp (continued)

Post by pixel »

Road map for the next five minutes: revive bytecode backend in tré to bootstrap the TUNIX Lisp compiler on the bytecode VM and throw away that massive evaluator which is a bitch with a 4kt butt, because of lexical scope. Compiler roadmap: https://github.com/SvenMichaelKlose/tun ... ompiler.md

Question: How much bytecode will the compiler compile itself to? Guess: same size as the interpreter's evaluator. Compiler code: https://github.com/SvenMichaelKlose/tun ... p/compiler
Basically tré's little sister. A self-hosting lisp compiler on a 6502 would be kinda mean. Now that's the best what I can come up with for that direction.

The damage is source-level debugging gone.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
Post Reply