Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Porting Smalltalk/Joy/Nim/J ... on CPC?

Started by m_dr_m, 23:26, 09 January 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I'm very interested and curious about your project.
I took some time to explore Turbo Modula on the CPC. It can generate Byte Code or native Z80 code.
A test here (in french) :

But I still prefer for the moment to use the good old Turbo Pascal 3. TP3 allows complex data structur, pointers, lot of memory, easy call to asm from pascal, easy call of pascal from asm. I wrote a sprote editor and Gomoku game and have a lot of project

you wrote :
my_table2 = my_table map my_function

Why not NewRpl without all the mathematical stuff?. Very exotic but so powerful! I like very much this langage. It's an HP calculator langage, a very coherent mix of Forth and Lisp.
Your example in RPL syntax is

my_table   « myfonction » MAP
About NewRPL : start [newRPL User Manual] (

For example :

{ 1 2 3 4 5 } « 2 * » MAP
will return { 2 4 6 8 10 }

{ 1 2 3 4 5 } 2 *
{2 4 6 8 10 }

{ 1 2 3 } { 4 5 6 } *
-> { 4 10 18 }

{ "a" "b" "c"} "Z" +
-> { "aZ" "bZ" "cZ" }

'a+b' 2 *
-> '(a+b)*2'


« 2 * » 'Double' STO

{ 1 2 3 } Double
-> { 2 4 6 }

{ 1 2 3 } { 3 2 1 } +
->  { 4 4 4 }

{ 1 2 3 } REVLIST
{ 3 2 1 }


CPC 6128+ / CPM+/ Turbo PASCAL v3


Sweet! Modula and TurboPascal were ahead of their time.

Would you be interested by porting TurboPascal on Amsdos? Even better, reusing Orgams Editor, for the following features:

  • On the fly syntax checking

  • Immediate access to

    • erroneous lines

    • label usages

    • label/routine definition

      • with immediate return to call site

    • Persistence across resets
    • A lot more

Then, I wonder if it would more less or more work than porting a modern language

[/color]Thanks for the pointers, newRPL looks neat, I love the automatic mapping/broadcasting, but it seems to have to same drawback than Forth: you have to play with the stack.[/color]Don't get me wrong, that is a mind opening exercice, and I encourage everyone to try stack-based/concatenation languages.[/color]But I find it boring in the long run.
[/color]Also, I don't believe we should restrict ourselves to tiny languages. The CPC is powerful enough.

  • [/color]


want to work with me to finish the code generator on the VB6 compiler and JS compiler?


Quote from: zhulien on 07:30, 26 April 21compiler

Theses projects sound great! Is there a place to follow their advancement?
For now, my priority is to port a language **on CPC**, not only **for CPC**.
That is, having the whole toolchain on CPC, including the editor, frontend, compiler, etc.
IIUC, your compilers would stay on PC.


well, the VB5/VB6 (extensive subset) cross compiler does the parsing and an interim XML structure... it can parse itself - which was an intention to allow it to retarget, so it could be hosted on a CPC.  there is partial code generation... unfinished.

the JS (subset) compiler doesn't intend to cross compile itself, has an interim JSON structure.  there is partial code generation... unfinished.

The VB cross compiler well, VB is not the most popular 'current' language - so hard to find a new audience for it.

The JS has some newer ideas in it that could allow you to write code once, run it in a browser, and also run it natively compiled on a CPC (when the code generator is finished).

In both cases, I am not decided on how I want to handle or pass parameters to functions.  I am leaning in JS towards allowing direct register assignment (sacrificing recursion and gaining performance)... what do you think?


Both VB and JS seems too big and cumbersome for the CPC.
But I'd happily follow your progress on the subject!


* Krusty has made a rust version of the donut. The generated Z80 code is quite bloated.
* Drill has made a D version, but I didn't even dare to try the cross-compilation: the D runtime is huge (garbage collection and co.), and it's unlikely to give better results.
Note: since those tests, douzains of improvement were made to LLVM-Z80,, so it can be worth re-trying.

Anyway, what I wish to try right now is to compile the LUA compiler (Lua source → Lua bytecode), for use on the CPC directly.
If it fits, another step would be to port the interpreter (Lua bytecode → well, code actually being executed).
Otherwise, I plan to try wren or gravity.

Is there anyone interested by that? Is there anyone interested enough to help me investigating?
There are a lot questions to be answered, such as:

  • How to force a simpler calling convention globally?
  • How to force the use of HL (potentially with INC) rather than copying it in IY?
  • What the heck with the infinite loop in BB0_5 and the rest of the code?
Helping with that would also leverage this LLVM-Z80 toolchain for cross-developing from any supported language (ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Dylan, Fortran, Graphical G, Halide, Haskell, Java bytecode, Julia, Kotlin, Lua, Objective-C, OpenCL, PostgreSQL's SQL and PLpgSQL, Pure, Ruby, Rust, Scala, Swift, Vuo, Xojo and other).


Quote from: m_dr_m on 20:18, 09 July 21How to force the use of HL (potentially with INC) rather than copying it in IY?

For exemple in this passage:

push hl
ld l, (ix + 4)
ld h, (ix + 5)
ex (sp), hl
pop iy
ld de, 0
ld a, (iy)
cp a, 120
jq nz, BB0_7
ld a, (iy + 1)
or a, a
jq nz, BB0_4
ld (hl), e
inc hl
ld (hl), d
ex de, hl
pop ix

There are other exemples where the generated code is simpler to ... simplify.


Quote from: Nemo59 on 09:09, 25 April 21t I still prefer for the moment to use the good old Turbo Pascal 3
Which version do you use? Do you have a download link?

On this site there is a JRT TurboPascal 4 for CP/M:
But I guess it doesn't follow Borland versionning.

By the way, have you written some articles about your explorations? The videos are nice, but not very handy to search for specific infos.

Powered by SMFPacks Menu Editor Mod