pouët.net

I'd like to use a modern language, existing

or ad-hoc, for and/or on my CPC 6128.

It would be sweet to broaden the scope (Spectrum, C64, toasters, ...) and unite forces.
Check this article for more context/motivation. Comes with donut and irrelevant concerns.[***]

Goal 1: Cross-developing.
Goal 2: Port the compiler/interpreter [**] on the host platform.

Regarding (1), I've started investigating llvm-z80: linky1. compiling-c-to-neat-z80-is-that-even-possible.
Con: Inadequate for goal 2.
Pro: Generating 8 bits asm from Rust is pretty cool.

Goal of this message:
• Connect with interested people.
• Become aware of already existing such projects.
• Start a reovlution.

I am quite picky in terms of programming languages, but since on Tuesdays I prefer humans, I can put my preferences aside for the sake of collaboration. Friendchip wins.

I can also do without the puns, if requested.

[**] I believe a well tuned VM could give better results (size and speed-wise) than the horror currently generated by compilers.

[***]

BB corrected:

I'd like to use a modern language, existing (*) or ad-hoc, for and/or on my CPC 6128.
It would be sweet to broaden the scope (Spectrum, C64, toasters, ...) and unite forces.
Check this article for more context/motivation. Comes with donut and irrelevant concerns. (***)

Goal 1: Cross-developing.
Goal 2: Port the compiler/interpreter (**) on the host platform.

Regarding (1), I've started investigating llvm-z80: linky1. compiling-c-to-neat-z80-is-that-even-possible.
Con: Inadequate for goal 2.
Pro: Generating 8 bits asm from Rust is pretty cool.

Goal of this message:
• Connect with interested people.
• Become aware of already existing such projects.
• Start a reovlution.

(*) I am quite picky in terms of programming languages, but since on Tuesdays I prefer humans, I can put my preferences aside for the sake of collaboration. Friendchip wins.
I can also do without the puns, if requested.

(**) I believe a well tuned VM could give better results (size and speed-wise) than the horror currently generated by compilers.

(***)

java grinder, a transpiler from Java bytecode to various CPUs.


I heard the z80 implementation is not that great, but maybe it's easier to improve than existing compilers?

Didn't look a lot further into it.

On the side of interpreted languages, probably forth will be one of the fastest options, due to the way it can precompile "words" to alrost native code, if I remember correctly. I am also wondering how smalltalk would do, as it ran on not-so-fast hardware from 1976 originally?

Dont forget to try: Obsolete Languages On Modern Computers (OLOMOCO)

Have you seen TRSE by Leuat? (https://lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/)

SDCC makes tolerable, but not amazing z80 binaries out of C code. When combined with timing-critical assembler routines written by hand, the result is usually pretty good with very rapid development times (assuming said assembler routines were written in advance).

z88dk contains its own fork of SDCC as well as another compiler which (afair) generates smaller but uglier code. It also contains tons of library functions written in assembler. I've never been a fan of z88dk as it does "too much", and you really need to learn what it does and how in order to get the most out of it.

The bad side of using C is that, compared to writing everything in assembler, you lose some control which really bites when hitting the memory limits. In real use you will need to know your platform and assembler pretty well in order to use it.

You could compare that with writing a game in ZX Basic and using some assembler routines to speed things up. Except that the "basic" code runs much faster.

And the fact is, z80 architecture predates C, so its design never took it into account.

I could rant about high level languages and describing intent and turning that intent into optimal assembler but that starts to be a tangent of its own... but let's just say that c++ is a wrong language for basically everything.

Fortran comes to mind, if you want to call that modern. Be careful with dots and commas though, as a misplaced one may cause space probes to get lost.

Check out Jason Turner about his work on using C++ for the C64.

Thanks for the pointers, much appreciated!

• java grinder and TRSE: My main aim is goal 2 (port a whole tool chain on Z80/6502). I would happily explore goal 1 as an intermediate step, yet it seems to be a dead end here. Those are very interesting projects, alas quite bound to big computers. E.g. Turbo Rascal isn't coded in Turbo Rascal, which hinders self-port.
  
• I agree about functional / declarative languages! Focusing on the what rather than the how opens room for much more optimisation. Best of both worlds! Oh, I am the one ranting now.
  
• Forth: that's a good lead. There is even Firth is a minimal (~4K) implementation of Forth for the Z80.. A bit raw tough. I encourage everyone to try stack-based/concatenation languages. But I find it boring in the long run. When I want to juggle with the stack, I'd rather programming directly in assembler!
  
• Fortran? Let's revive Fortress on the 8bits instead!
  

I just randomly found this while looking for something completely unrelated: http://cowlark.com/cowgol/

I'll chime in. My interests tend to lie in 8080, specifically Vector-06c, so my research in this area is 8080-centered.

I entertained an idea to use C++ on a 8080 computer and came up with a ZPU emulator that works on a Vector-06c. You can take a look at it here: https://gitlab.com/svofski/zpu8080

You can run a qsort demo (js emulator direct link)
http://sensi.org/scalar/vector06js/?roms/sort4k.rom

I also managed to build and run uIP using this "platform". v06c doesn't support any network cards so I hacked the emulator a bit just to have some fun. It was a curious experiment, but I would not develop for such platform unironically.

Slightly more serious alternatives for 8080 specifically:
* DX Forth, which is a very good Forth. It's closely compatible with gforth, so development can be done on Linux and you will have single source code running on a modern pc and CP/M machine
* Pascal MT+ is a very real Pascal compiler for CP/M
* ACK (Amsterdam Compiler Kit) - it supports multiple frontends but only their C is up to date. It's good enough to build uIP almost without changes, which is a good C compiler test I think.

Siiing it back @bstrr

Thanks again for the suggestions. What I'll try next (unless someone thinks of something smarter):

• Port the lua VM on Z80. Or maybe eLua, although the project seems dead.
  
• If satisfying, try to compile something on IBM-PC, and execute the bytecode on the Z80-based machine.
  
• If satisfying, port the lua compiler!
  

m_dr_m :
the tore is on st or speccy ? or pc ? if it's all it get on a pc then surely a vm on 8 or 16 bit machine is a win
if it's on speccy, if it move at 50fps i'm impressed
even on st
on st (i mean with enough ram) the dots could be subpixeled at no cost (except ram) but of course depending of the routine (ie fixed constant xy of dots then the faster is the routine but impossible to do subpixel) but i forget a thing, doing 16 bit operation on a 8 bit could be as hard as doing 64bit multiplication on 68000
so i don't remember what i was about to say
i m interested
to do a 'super toolchain' that generate code for the crossed platform with a 'vm' that must be the most thin as possible in ram
and in that way do a codegen1 than generate codegen2 on the platform destination that generate codegen3 to calculate the code genere for the demo fx itself, then after the fx ,the codegen2 is the only one remaining in ram witch is generated by the toolchain and done to be compact in ram or a compromise between fast calculation and memory used

Great question!

The tore isn't moving yet. It is a minimal exemple, yet substantiel enough to validate a language's expressivity.

• Locomotive BASIC (42 seconds, ouch).
  
• There are LUA, rust and D version somewhere, but I wasn't able to produce self-sufficient bytecode or Z80 version from them yet.