Small-C running on the VIC – here's how

[pixel]

Small-C ran on the Intel 8080, 8085, 6809, 68000, VAX and I might be missing one or two other CPUs. It can handle a subset of the C programming language, but the best part of it all: that subset is powerful enough to have Small-C compile itself. That's what I want on the VIC.

I have refurbished the code and put it on https://github.com/SvenMichaelKlose/small-c so you can join tinkering with it. Very new to this version is that it comes with quite some documentation that was created during code review. There is also a road map. So, if you wanna join the ride, you don't have to bang your head on the thing to get started.

It's still lacking an assembler.

[pixel]

Kay. Now it is generating some IR/object kind of thingy. 76 virtual instructions now need to get translated to tested assembly macros. A direct translation to machine code would basically make a linker. That's a hell of a lot of test cases, ideal to be eaten away in small increments as a hobby project. This one's got its own BLOG along READMEs and stuff too for a less informal view over the edge.

[groepaz]

You could just port the atari version (which later became cc65)

[pixel]

You could just port the atari version (which later became cc65)

News to me. Also just found David Wheeler's 6502 language page which has "news". https://dwheeler.com/6502/

But take a look at this:

The tiny C fragment got compiled to byte code at the bottom which the 'ir2txt' program translates to the pseudo-assembler to the left and that just needs to run through a set of asm macros that does the targeting. No boring with details (yet). Both formats offer quite some playground and grow room. Hard-targeted asm generators should give everybody the curlies. Source lines and symbol info could also stream in just in case somebody wants to wedge in an optimizer later on.

Anyway, how long did the BBC version take to compile itself?

[pixel]

Oh dude. What a heritage tree. Makes it hard to apply a version number. One repo with all versions in it should be least one could do about it. Could just happen in a minute (minutes v1.0).

The BBC thing seems to have very, very useful additions that are dearly missing in the VIC version.

* Separate preprocessor: that's what any 8-bit version of Small-C requires due to memory constraints. (I am separating the back end on the other side). Taken.
* Parametrized macros: Macros with arguments. The classic tool to improve readability without sacrificing performance (as the come with "inlining" by definition).
* Hash tables for symbol look-up: A classic. And one of those things that should not be there more than once but it is. The VIC version will use "database" files. I was thinking more of b-trees (requiring no stack to iterate) as they are more all-purpose. Won't work with a drive that DOS not support random r/w access.
* Forward declarations and typed return values. That's huge.

Doabouts:

* Using the BBC preprocessor instead *should* be no problem. Will lead to another grand clean-up, thanks to the more powerful macros that allow removing tons of dupe expressions.
* I'll go for b-trees just in case the VIC needs a file-based database :p... wanted a lib for that a couple of times already.
* Type-checking: Yo. Nerd to see what things look like when cleaned up with macros. There's spaghetti to be expected until then.

Thanks for pointing out that there's that version, groepaz. I'll just celebrate that by putting all versions I have in a single repo for preservation.

[orac81]

Good old Dr Dobbs Small-C! A port from a BBC version seems a good fit for the VIC20 - both 32K in normal max memory config. But what you are trying to do is ambitious. Would it also compile on a PC so it can act as a cross compiler?

Back in the day, in early BYTE magazines Small-C was advertised by a user group for the KIM-1 on paper punch tape! I wonder how many 2102 (1kx1) RAM chips you needed on your KIM to run that?

[pixel]

Good old Dr Dobbs Small-C! A port from a BBC version seems a good fit for the VIC20 - both 32K in normal max memory config. But what you are trying to do is ambitious. Would it also compile on a PC so it can act as a cross compiler?

Back in the day, in early BYTE magazines Small-C was advertised by a user group for the KIM-1 on paper punch tape! I wonder how many 2102 (1kx1) RAM chips you needed on your KIM to run that?

I've gathered some more version. (Please let me know if you know more and where to get them.)

smallc-v3.0r1.1-6809,68000,8080,vax is the one I started out with. Good idea as it's multi-platform and I want it to stay that way. Might one day reuse the targets.
smallc-plus-v1.06a-TMS9900-99000 & smallc-plus-v1.0-z80-cpm know doubles and floats. Oh yeah! Not the most urging issue though. Target reuse might happen here as well.
To "just" port smallc-bbc-v0.73-6502-selfhosting wouldn't work for the VIC (the ROM was also used on the BBC) and as I said I want the compiler to be as flexible as possible. You never know... the apocalypse is nearing... when you're desperate for compiling VAX code with only your VIC left.
smallc-byte-v1.0-8086-dos, smallc-v1.0-8086-cpm & smallc-v1.2-8086-dos-to-cpm also have targets for reuse.

This version (which needs a name) *is* a cross-compiler. Won't take that feature away.

[pixel]

Did some thorough clean-ups and the code is more fun to read now. Header files have been added because no-one wants to code without forward declarations unless sitting on a stash of diet pills.
https://github.com/SvenMichaelKlose/sma ... master/src
Looking at 'expr.c' one can spot how this can make serious use of the tokenizer that's been added (but not completed).
I'm seeing something table-driven.

I also peeked into cc65 with the newly acquired view on compiler writing. It has an assembler built-in which is a bit of a misfortune. For some meta level between assembly and "code entries" (half-assembled lines) about 500 code snippets would need to be abstracted and bad surprises aren't priced in yet. And that's just spadework for a real code generator. What I really don't like, and it might be a mental dysfunction of mine or something, is the bloated code style of cc65. IMHO comments should be used exclusively if the life of a developer depends on them but at least never tell what the code is already screaming about.

For now I'm curious what some IDE instead of VIM+sh can help with...

[groepaz]

IMHO comments should be used exclusively if the life of a developer depends on them but at least never tell what the code is already screaming about.

Hopefully you never write any software that someone else has to work with

[pixel]

Hopefully you never write any software that someone else has to work with

You're the first to complain. I promise to not touch cc65.

[groepaz]

I'm not complaining at all. It's just a pretty silly thing to say. Especially about cc65 - it's neither "bloated" nor is it excessively commented. Quite the contrary is true - It's actually lacking a lot in that area.

[pixel]

I'm not complaining at all. It's just a pretty silly thing to say. Especially about cc65 - it's neither "bloated" nor is it excessively commented. Quite the contrary is true - It's actually lacking a lot in that area.

That's a lot of lines for declaring an empty string and an "if". What's the name for this in the "bad code" glossary other than "bloat"?

[pixel]

I hope the latest insanity added https://github.com/SvenMichaelKlose/sma ... owroom/bdb has an OK code style.

That's a key/value database with records of variable length that get moved to a file if memory runs low. The records are indexed by a binary tree in the "file" which is called "storage" because you can store the records anywhere else where space is flat and time runs continuously. Three primitive functions define the storage. There's an example for a symbol table, which brings the
topic back to the compiler. The memory cache is btree-indexed once more for the record IDs. And as there's a LRU list that gets some cache functionality, too. That takes a lot of memory away for each record. Over time unused records idle out to storage unless looked up recently. That's hoped to spare headaches with reference counts. I stopped at the point there the storage layer is using the cache layer to think that through... performance tests have to make up for that lack of brains.

If the cache was flushed, database files could be reused. This is worth an own library, I guess, although I'm having trouble imagining use cases. Please don't suggest adding an SQL layer...

[pixel]

Project has been merged into https://github.com/SvenMichaelKlose/tunix where it is to be found in 'src/contrib/small-c' to get further dissected into smaller apps. The very good looking embedded database "Bielefeld DB", whose tests pass (always a most rewarding experience in return for not panicking with breath held) moved to 'src/lib/bdb'. And the hate-love 6502 kernel is in 'src/sys/kernel'.
An amazingly stupid init error messed up the Lisp + 40x24 terminal. 'cregex' also went in because it's a masterpiece and no OS can live with no regular expressions.

Whatever. End of thread. I'll continue writing in the repo as I'm getting a strong sense of wasting everybody's time here.

[mingle]

Whatever. End of thread. I'll continue writing in the repo as I'm getting a strong sense of wasting everybody's time here.

Not at all...

I'm sure I'm not the only one here who thinks it's very interesting to read this kind of thread.

Just because we don't' always post responses, doesn't mean we're not paying attention!

Keep up the great coding!

Cheers,

Mike.