TUNIX

[Wilson]

Just shining some light on a potentially symbiotic project
Whatever brings you joy! Really just a matter of if you prefer to devote your hours to writing Vi or the OS. I haven't used Vi65 in any real way, so maybe I am a liiiittle selfishly curious to know how it would hold up to real usage.

Anyway, cool stuff.
I seem to have some build issues. They look legitimate?

Code: Select all

# Making world.
/Library/Developer/CommandLineTools/usr/bin/make -C src all
/Library/Developer/CommandLineTools/usr/bin/make -C contrib
/Library/Developer/CommandLineTools/usr/bin/make -C exomizer-3.0.2/src
Generating dependencies
Compiling match.c
Compiling search.c
Compiling exo_main.c
Compiling optimal.c
Compiling output.c
Compiling membuf_io.c
Compiling chunkpool.c
Compiling radix.c
Compiling exo_helper.c
Compiling exodec.c
Compiling progress.c
Compiling asm.tab.c
Compiling lex.yy.c
Compiling parse.c
Compiling expr.c
expr.c:36:15: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
void expr_init()
              ^
               void
expr.c:41:15: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
void expr_free()
              ^
               void
2 warnings generated.
Compiling pc.c
Compiling vec.c
Compiling named_buffer.c
Compiling map.c
Compiling desfx.c
Compiling 6502emu.c
Compiling exo_util.c
Compiling areatrace.c
Compiling exo_raw.c
Compiling getflag.c
Compiling log.c
Compiling membuf.c
Linking exoraw
ld: warning: -s is obsolete
Compressing sfxdecr.s
Compiling b2membuf.c
ld: warning: -s is obsolete
Compiling sfxdecr.c
Linking exomizer
ld: warning: -s is obsolete
Compiling bas_main.c
Compiling bprg_renumber.c
Compiling bprg_link_patch.c
Compiling bprg_trampoline.c
Compiling bprg.c
Linking exobasic
ld: warning: -s is obsolete
rm exoraw b2membuf
/Library/Developer/CommandLineTools/usr/bin/make -C lib
/Library/Developer/CommandLineTools/usr/bin/make -C bdb
cc -Wall -Werror -DTESTS -ggdb -g -O0 -c bdb.c -o bdb.o
cc -Wall -Werror -DTESTS -ggdb -g -O0 -c cache.c -o cache.o
cache.c:78:19: error: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Werror,-Wconstant-conversion]
    char mask = 1 << 7;
         ~~~~   ~~^~~~
cache.c:80:9: error: variable 'new' is uninitialized when used here [-Werror,-Wuninitialized]
        new <<= 1;
        ^~~
cache.c:77:13: note: initialize the variable 'new' to silence this warning
    char new;
            ^
             = '\0'
2 errors generated.
make[3]: *** [cache.o] Error 1
make[2]: *** [bdb] Error 2
make[1]: *** [lib] Error 2
make: *** [world] Error 2

[pixel]

Just shining some light on a potentially symbiotic project

It took me three hours to assemble an answer. So much for my state of mind at the moment. External cause.

Whatever brings you joy! Really just a matter of if you prefer to devote your hours to writing Vi or the OS. I haven't used Vi65 in any real way, so maybe I am a liiiittle selfishly curious to know how it would hold up to real usage.

Am cautious myself. vi65 is a lot better but that'll change and be a far better pick on the long run for a portable(!) OS. The VIC is just ideal to start with.

Anyway, cool stuff.
I seem to have some build issues. They look legitimate?

Code: Select all

# Making world.
2 errors generated.

I dare saying no. :p There was a ld65 config file missing for VI (now in the repo) but it compiles nicely without errors with gcc11-0.4 and -Werror – which compiler are you using?

EDIT: If figured it must be clang, so I fixed it right away and guess what? – I'll switch to clang because gcc really shouldn't have missed these.

That's what I call a contribution! Thanks!

[Wilson]

Happy to help! ;D

[pixel]

I went too far down the source tree for too long, missing that that stuff in the README is already older than a Unix beard.

Objective: build an OS for "home computers" with banked memory expansion (VIC first ) that actually has practical use, is self-sufficient
and will last by being open and well-documented. No, I'm sober. Just for this.

Plan: A Lisp interpreter mimics the system shell for quick user interaction and is used for all sorts of scripting and *drum roll* compiles C in micro-passes in order to build the kernel and whatever else ends up in the source tree, assisted by an embedded database. To really knock it off a Linux compatible (as much as it can be) terminal with variable width fonts, graphics capabilities and document mode make the GUI: very much like a web browser and server.

Wow! This took only 2.5h to write. Guess there'll be no book. But if you want to set my ass on fire please contribute whatever ten-liner you can spare.

[pixel]

Some progress with the Lisp:

* Garbage collector passes stress tests (HOT!) Impressed by myself the code size increased a bit. ;p
* Symbols are also strings. READ won't do look-ups for re-use when they are double quoted.
* Function LOAD to include files is working and can be nested (up to three times).
* Added a stash of I/O functions and guess what? I think I didn't get no grasp on KERNAL I/O up to this day.
* There's no manual you wanna lick.

The prospective heap size when finished (RAM123 and BLK5 and unused) is 16K. On the other hand the interpreter hasn't been optimized yet (goes for both speed and size).

[pixel]

The VIC brightening the day running this for three minutes:

Code: Select all

(var c 10000)

(fn block-test ()
  (out "Looping...")(terpri)
  (block nil
    tag
    (setq c (-- c))
    (? (== 0 (% c 100))
       (& (print c) (terpri)))
    (? (not (== c 0))
       (go 'tag))))

(block-test)

It *is* slow, no question about that. On the other hand Lisp programs normally don't care too much about numbers. This loop creates a new number object for each arithmetical operation. Looks OK for decent scripting though. BLOCK is also a TAGBODY (GO works).
A version in assembly would be amazing.

[pixel]

[pixel]

After loading "env.lisp" there's now a REPL. You'll drop back to the top-level on errors.

Added all targets (c64, c128, plus4, vic20) to the archive.

[pixel]

Performance has been upped by 40%. The CPU stack use has also been halved almost. Doing recursions is actually a bad thing at the moment.

That's the perfect opportunity to turn beautiful code (c'mon I'm using cool-retro-term) into a trigger for panic. But I'll head out for sun light and ice cream instead because I'm convinced that there's an elegant solution.

Latest disk images for all your Commodores:

tunix-tools.2024-05-26.cbm.zip

(69.11 KiB) Downloaded 34 times

[pixel]

A third stack with one-byte return tags has been introduced to jump around inside the evaluator instead of having it call itself. That doubled the number of recursions before the CPU stack is running out. The "problem" are the built-in functions that call the evaluator. Difficult enough to procrastinate for a day.

+24K RAM is all that's used, by the way.

[pixel]

I've added target 'unix' (it even makes a d64 image for it which is of course nonsense). The Lisp runs on it and the VI is probably next to become Linux-terminal compatible. Had trouble with the stack-optimization for built-ins and some elephant in the room. With no optimization a gcc'ed Lisp is 3500x faster on a mobile Intel i5. With -O3 it's 40,000x faster. That's 12h on a VIC for what takes a second on a soon to be outdated laptop. Performance dropped about half as the peephole-optimization with cc65 doesn't oomph it but it seems to be a fair estimation of the end result. Numbers have been upped to 32 bit signed out of necessity. I'm adding macros.

[pixel]

Am bringing that truck load of retro stuff people say would be mine back home. Found some moments to inline the BLOCK special form and most built-ins use a generalized type checker for their arguments. Performance dropped to 03:40 for the BLOCK-TEST (32-bit signed integer numbers now). MAKE-COUNT makes it to 200 (more than double the number of recursions). That's still not enough to feel safe. A bit of cleaning up, not optimizations really, should shrink the stack needs further. Would be nice if it'd keep being fast enough to operate a shaver. Stacks are pre-allocated and not part of the heap (which is also the scratch pad for relocations of dynamic size).

Am curious what this can be used for on zero cent controllers.

Here's something to play but if I had to wait I'd wait until macros are in. For C128, C16, C64, plus4, VIC-20:

[pixel]

I checked with the doctor ("C'mooon! At least some weed!?") but it still looks doable to bring on the C compiler natively on the VIC. How could I possibly arrive at that conclusion?
Well, here's the size of the "tré" Lisp transpiler which can compile down to assembly level (with stack allocations and lexical scope):

Code: Select all

lib: 806
front-end: 513
middle-end: 428
back-end: 373

That's right. These numbers are lines of code, excluding empty lines and comments. 'lib' is a bunch of getters and setters for common data structures, lists and hash tables, and the function info structure that holds expressions and the rest of the data together. A bytecode/asm generator is no more than another 100 lines. Only the exceptionally badly written EXPRESSION-EXPAND reaches almost 200. Each pass fitting into the heap along with a top-level expression to compile is all we need to compile Lisp to bytecode or asm with lexical scope even. The very, very good news here is: the already existing tré compiler code can be reused. That's win-win for both projects as tré needs type. What's missing to chew away on C code is the lexer and parser and type information, checks and casts. Ok then. I'll re-write the kernel in Lisp notation(!) with type added. Makes the thing a multitude more flexible and I can use all help I can get.

I like the interpreter very much and ran out of new items for the wish list. I've banged together some kind of manual and ran the Markdown through Pandoc and the eisvogel template.

TUNIX-Lisp-Manual-2024-06-08.zip

(253.71 KiB) Downloaded 6 times

Please comment!

[pixel]

This nightly build *yawn!* fixes a lot of bugs only early releases have to offer. I/O works much better.

EDIT: Some more bug fixes plus some macro- and quasiquote-expansion code.

[pixel]

Am almost done with macro expansion. Added user-defined special forms: functions whose arguments aren't evaluated, e.g. for QUASIQUOTE. Had to add the +3K area to have some heap left. The VIC allows for a neat optimization that boosts performance but we're not interested in optimizing yet, are we? :p No.

If you want a hand-optimized 6502-CPU version of 4K in size you're welcome to fork off and take the fame. Just saying. Life is short. I'm more into improving compiler optimizations.

Next nightly build with macros working for sure.