Is Comal lost to time?

[gfoot]

I'm interested in non-BASIC languages that are appropriate for 8-bit computers - I've been meaning to try Forth, but wasn't sure where to start (like, which implementation to begin with); and Comal sounds interesting too if there's again a good reference implementation to start from. So if you make progress I'll be interested to hear it!

[drogon]

gfoot wrote:

I'm interested in non-BASIC languages that are appropriate for 8-bit computers - I've been meaning to try Forth, but wasn't sure where to start (like, which implementation to begin with); and Comal sounds interesting too if there's again a good reference implementation to start from. So if you make progress I'll be interested to hear it!

BCPL of-course

However there is only one 8-bit version I know of and that runs on the BBC Micro - or compatible - I can run the ROM on my Ruby 6502 system. It needs a Beeb compatible filing system to work but the compiler and editor will work directly on a Beeb (or compatible) just fine. The Beeb version supports 16-bit integers and various fixed and floating point formats (in a somewhat clunky sort of way)

I have a 32-bit version that runs on my '816 board. It's a somewhat updated compiler (and has direct support for floating point) but it runs just fine and I can edit and compile directly on the system.

Pascal - e.g. UCSD P-System although I don't think it's easy to port.

There is another Pascal called: "Turbo Rascal Syntax Error" however it's a cross compiler and needs a modern 64-bit system to run..

https://lemonspawn.com/turbo-rascal-syn ... but-begin/

This is also a good read: https://dwheeler.com/6502/a-lang.txt

I have also been looking at TACK - The Amsterdam Compiler Toolkit, however it's been put on he back-burner for now.

https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
https://github.com/davidgiven/ack

And there is a native C for the 6502 - Aztec C - I used it on the Apple II back then. Slow, but sort of worked.
http://aztecmuseum.ca/

There are many others - e.g. PL/M ought to be possible, but who wants to write/port the compiler?

Oh, also APRICOT - my own programmable calculator - currently written in C (and BCPL) but the C version will compile to 6502 with cc65 when I fix one trivial thing. I do plan to make a native 6502 version at some point though:

Example here: https://unicorn.drogon.net/sieve.cot
Stuff on it here: https://projects.drogon.net/apricot/


-Gordon

[hjalfi]

I've looked at PL/M. I wanted to do a LLVM port for it, so I could use the 6502 backend to compile the original CP/M tools. Unfortunately it's got some really weird features, such as the ability to jump out of subroutines with a goto, which make it very hard to work with LLVM.

There's always Cowgol, my own language. It's intended to be a modern type-safe language designed to compile easily for and on small computers. It's self-hosting on the PC, and is theoretically self-hosting on 8-bit machines, but in practice I doubt there's enough RAM: despite my best efforts the compiler binaries are about 45kB each. Also, it's a multistage compiler meaning there's lots of disk activity and it's cripplingly slow. On a PC, of course, it flies. The generated code isn't that bad, either. It supports a whole pile of different platforms. https://cowlark.com/cowgol/index.html

[dmsc]

As hjalfi said before, FastBasic is really close to COMAL already, and could be made more compatible with some changes.

The "small" differences are:
- Multi-line "IF" and the "ELIF" statement don't require the "THEN" keyword.
- "CASE" is not implemented. I did not implement "CASE" as it need to store the value of the CASE to compare with all the WHEN clauses, making it complicated. And, using IF/ELIF/ELSE/ENDIF seems more intuitive to the programmer.
- Procedures don't support "REF" parameters, all parameters are passed by value. Implementing "REF" parameters is possible, creating new variable types (ref-to-*).
- Procedures don't have local variables (i.e., are always "OPEN" in COMAL parlance). Implementing local variables is not difficult, but FastBasic currently has a limit of 256 total variables in a program - this is or performance, as the interpreter uses the variable number as an index into the variable storage.
- Floats can't be converted to integers automatically, you need to use "INT()". This is a personal preference, it avoids a lot of programming errors, and makes the parser faster.

And more fundamental "limitations" are, in order of difficulty of implementation:

- FastBasic does not have "runtime errors", you must check math or I/O errors in your program using the "ERR()" function. The only error is "out of memory", this terminates the program. This is by design, as good programs should check errors and proceed

- There is no "GOTO". This makes the parser simpler and less error-prone. COMAL restricts the GOTO keyword so that you can't transfer into a structured statement, procedure or function, but detecting this in a single-pass parser would be difficult. Also, implementing a GOTO out of a structured statement would mean the parser should emit code depending on the target, also very difficult in a single pass.

- "DATA" statements don't work like BASIC - they simply define arrays in memory with all the data initialized. There is no "READ" statement. IMHO, this is simpler, faster and more useful

- FastBasic does not support multi-dimensional arrays or changing array lower bounds. This is for performance and simplicity, as arrays are stored as pointers to the first element, the parser converts "PRINT A(X)" to "PRINT DPEEK(&A + 2 * X)" directly in the generated code. To support multi-dimensional arrays, the interpreter will need to store the array dimensions in a bloc of memory, and the array stored as a pointer to this array block, so all array accesses would be slower.

- Implementing functions is more complicated, because the FastBasic parser assumes that values in one statement are assigned only once and there are no side effects in the evaluation of expressions. For example, most string functions returns a string in a fixes memory location, and array or string assignments use a register to store the address on which to store the expression value. This means that a function could not contain any assignments.

- Also, recursive functions would need "stack variables". FastBasic currently only has a small evaluation stack - with an 8 bit stack-pointer. Using a bigger stack-pointer would make the interpreter considerably slower. IMHO, recursive functions are a bad idea in an 8-bit computer.

Have Fun!

[barrym95838]

I haven't personally used David Schmenk's PLASMA yet, but it looks quite performant and featureful.

[BigEd]

I'd love to see Cowgol and Plasma out and about in the wild!

[GlennSmith]

There is also GPascal (specific posts on 6502 and the forum) re-ported recently by Nick Gammon for Ben Eaton's SBC. In his documentation he says that it is now his sole copyright but free for use under MIT-style license.

I also am interested in having a relatively structured (and reliable) programming environment on-board my 65C02 system, so peoples' results are of interest to me.

When I've finished tweaking my Workbench Board Computer (thank's Garth) design, I have planned to crank-up GPascal on a simulator to see how it looks - so I can decide what to put in my boot ROM.

[As an aside, I have used a Pascal compiler on the PIC platforms for many years]

[hjalfi]

Re Comal: I was actually wondering whether you could go smarter than a simple tokenised representation... given that it parses lines on entry, then theoretically you could do a lot of precompilation and make execution faster. For example: variables could be allocated at parse time and a reference stored rather than the full name, thus avoiding a lookup at runtime. Expressions could be converted to reverse polish. You could even decompile the bytecode when listing, avoiding the need to store the program text at all (although this would of course require storing REM statements). In turn this means no storage of whitespace. It might even be worth using direct threaded code for maximum speed, but I suspect not --- it would double the size of each token and would only save a few instructions to indirect through a jump table. There are some gotchas which would require careful thought. Does the parser allocate variable storage, or just the atom representing the name? I think the latter, as otherwise it'd make scope handling difficult. Also, disambiguating strings and function calls might be exciting --- consider <code>thing$(1) := "f"</code>...

Eh. Too may projects, not enough time.

GPascal looks really cool! Alas, it's a Small Pascal with no structure support, but still very interesting. Do you know how big it is? As it stands it's designed to go into EPROM, so producing small binaries isn't an issue.

BTW, another potential project is Alan Cox's Fuzix Compiler Kit. It's an ANSI C compiler written in C intended to be self-compiling on the target platforms. It doesn't support the 6502 yet but it'd be interesting to add. https://github.com/EtchedPixels/Fuzix-Compiler-Kit

[GlennSmith]

hjalfi wrote:

Alas, it's a Small Pascal with no structure support, but still very interesting.

I assume you're talking about data structures ?

hjalfi wrote:

Do you know how big it is?

From what I've seen in the package, the binary image is 32k. I haven't yet dug into the sources to see how the space is distributed.

[Paganini]

gfoot wrote:

I'm interested in non-BASIC languages that are appropriate for 8-bit computers - I've been meaning to try Forth, but wasn't sure where to start (like, which implementation to begin with); and Comal sounds interesting too if there's again a good reference implementation to start from. So if you make progress I'll be interested to hear it!

I know there are lots of good FORTH specific books; but my plan, if I ever get that far along, is to study this book: https://www.amazon.com/Threaded-Interpr ... 007038360X and roll my own for that truly retro experience.

[BigEd]

hjalfi wrote:

BTW, another potential project is Alan Cox's Fuzix Compiler Kit. It's an ANSI C compiler written in C intended to be self-compiling on the target platforms. It doesn't support the 6502 yet but it'd be interesting to add. https://github.com/EtchedPixels/Fuzix-Compiler-Kit

Nice! I hadn't seen that before, and it's still in development - the README even mentions 6502 so there might be a sliver of hope.

[hjalfi]

Everyone should write their own Forth interpreter. You're unlikely to want to write in Forth afterwards, but it'll teach you so much about programming. Mine is at https://github.com/davidgiven/fforth --- it's implemented as a single C file which is also a shell script and also contains gawk code and also contains embedded Forth code. Because reasons!

[Broti]

COMAL-80 is getting some love on Forum64 recently.

[BigEd]

(For later adventurers, this thread for example:
https://www.forum64.de/index.php?thread ... rweiterung
)

[hjalfi]

It's been a while, but I now have about 2/3 of the Comal interpreter working: https://github.com/davidgiven/comal65

So far it's missing floating point, CASE..ENDCASE, GOTO, comments, and a bunch of other things, but the core language is working. It byte-compiles on entry and decompiles on listing, so you get entry-time syntax checking and a relatively compact representation. It was also supposed to be quick but after benchmarking it it's slower than I was hoping... some work there to do.