CPCWiki forum

General Category => Programming => Topic started by: m_dr_m on 23:26, 09 January 21

Title: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 23:26, 09 January 21
I'd like to port Smalltalk/Joy/Nim/J or any neat language to CPC.
It could reuse Orgams for nice IDE experience.


Goals:
* Fun
* Functions
* Having a langage better, faster and more pleasant than Basic.
* Learning
* Well, fun, mainly.


Anyone is interested? By the result and/or the work?

Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: gurneyh on 00:30, 10 January 21
hi,
I like the smalltalk language, but...
It sounds very ambitious, I'm not sure there is a place for these languages on CPC or other 8-bit computers.
I'll follow the progress anyway.

And seriously, J language ?  :o




Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 01:43, 10 January 21
The smalltalk ecosystem is huge, but the langage is small (i.e. syntax fitting on a stamp).


If it's more powerful, neater and faster than BASIC, of course it has its place!
Useful for prototyping, pre-computation, glue langage, etc.


Thanks for the feedback, anyway !


J is fun and terse. Perfect for CPC :)

Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: AMSDOS on 03:39, 10 January 21
Why do you criticize structured BASIC coding?
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 16:27, 10 January 21
Good question.
I don't see it as structured. Relying on side effects, no propers functions, no modules, no libraries, no typing, no pattern matching, etc.
Fixing that would give kind of a bloated langage. Visual Basic has its qualities, but I don't want to port that.


I guess I'm not fond of BASIC: quaint, imperative, error-prone, verbose. No nice ways to extend the langage (the locomotive BASIC is convenient due to built-in commands).


I'd rather work on something sexier !


Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Targhan on 17:26, 10 January 21
I have no experience in the languages you mentioned, but does it mean you could compile the code and use it along any ASM program, just like some people use C? If yes, that is interesting.
But could you compete with the (CPC) C speed?

What about LUA?
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: reidrac on 17:31, 10 January 21
The main constraint is always going to be memory. Languages that are very dynamic tend to have a heavy runtime. For example, trying to run a Lisp is very difficult (although not impossible: https://www.cpc-power.com/index.php?page=detail&num=6043 ; a different matter is if it is useful to build software with it).

The most promising "modern" proposal I know is this one: https://github.com/KarolS/millfork

I know people making games with it and they say the generated code is pretty decent (mostly for 6502, assuming the Z80 is on par).
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 17:59, 10 January 21
High Ghan, the steps would be:
The good thing with high level languages is that the latter steps might be unnecessary. Let's say you have an array my_table and you want to transform each element through my_function. I want to write something like:

my_table2 = my_table map my_function

Then even if this assignment is still interpreted via bytecode, it would just boil down to calling a fast mapping.
That's another reason I don't like BASIC or C: for loops are so ridiculous.


Lua is a good candidate. I know it's great at extension+embedding. Yet I don't know why! I hope it's not because it's not high level enough.
Unless someone else is interested by working on the port, it wouldn't be my first option, though.




Hi reidrac!


Thanks for the links, quite appreciated.
I don't see memory as an issue.

Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 18:05, 10 January 21
Here the options I can think of for Smalltalk (I would be similar for any language, though):

Find CP/M versionPort from 8080
https://winworldpc.com/product/digital-smalltalk/12-dos (https://winworldpc.com/product/digital-smalltalk/12-dos)  (dos version, only the executable?)

Port from Rosetta / Z80 exidy (improved smalltalk-72)
Rosetta Smalltalk presentation (http://esug.org/data/HistoricalDocuments/Misc/RosettaSmalltalk.pdf)(16k, unoptimised, bubble sort 7x slower than BASIC version on the same machine).
Hard might be hard find (this guy has a prototype (https://macgui.com/usenet/?group=26&id=7467), though).
To See: https://squeak-dev.squeakfoundation.narkive.com/6Vzis5X4/smalltalk-for-z80-processor (https://squeak-dev.squeakfoundation.narkive.com/6Vzis5X4/smalltalk-for-z80-processor)
Port from 6502
According to the link above a 6502 version exists.

Port from smalltalk-80 on Atari-ST

Compile existing VM to Z80
From C++ to Z80, should be something.
https://github.com/michaelengel/crosstalk (https://github.com/michaelengel/crosstalk)url]  VM C++ for raspberry!

Rewrite VMWriting a transpiler from Smalltalk-Bytecode to PIU-Bytecode
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 18:11, 10 January 21
Oh yes one middle-term goal would be to compete with existing CPC-C solutions.
All the ones I've seen are awful (no inlining, bloated preludes for function --even when just passing 1 parameter).
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Targhan on 18:25, 10 January 21
Wouldn't it be better to directly compile SmallTalk (or any other language) into ASM? Many people use C to manage their high-level stuff. Yet as you pointed out, the generated C on CPC is terrible.
I think there's something to be done here, there would be a real need. Faster than C and nicer to look at? Count me interested.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: SRS on 19:18, 10 January 21
You could use JAVA.
The software needs some improvement, so why not start there:
https://www.cpcwiki.eu/forum/programming/another-way-to-get-java-on-the-cpc/
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 19:44, 10 January 21

Compile to ASM: not necessarily better (see figure 1). Also, makes debugging and introspection harder.
Ultimately, for the dynamic features (e.g. method dispatch), you end up putting part of the interpreter in the generated ASM.It is a noble goal though: tying the knot, unifying static and dynamic facets, for instance having the same compilation phase for JIT or ahead of time compiling.


JAVA: the langage is awful and one of the least CPC-ish of all (scientific fact), the VM is great. Rather have Kotlin or Clojure!
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 20:00, 10 January 21
SRS: Thanks for the link. Note that my goal is to have a language on the CPC, not to cross-dev!
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Targhan on 20:32, 10 January 21
Kotlin is an awesome language, I use it every day.

However, I'm not sure I'll find many users if you're still living in the "no cross-dev" dark age.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 21:12, 10 January 21
Let put it that way: it could be cross-dev, but it must be native-dev as well.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Targhan on 23:56, 10 January 21
Quote from: m_dr_m on 21:12, 10 January 21Let put it that way: it could be cross-dev, but it must be native-dev as well.
That would be perfect indeed! Best of the two worlds.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: AMSDOS on 00:24, 11 January 21

Perhaps you could use Forth instead?


You have to remember:-


* The Amstrad CPC range are a series of Microcomputers from 1984/5
* Z80 Assembly is it's sole language
* Languages for it (Compiled or Interpreted) pre-date by 15 to 20 years
* New Languages emerge when Computers become more powerful and have a CPU capable of easily supporting newer things


As an example C Language from 1970/1 has required adusting to suit CPC since it came from a Minicomputer and even the likes of Small C had to be 1st compiled on a larger computer system to produce that COM file, fortunately Ron Cain made it so future versions could be Compiled from previous version.


All the newer language which in some way produce the Z80 code, do it through another platform, which I think try to produce efficent Z80 code or based it on how a Z80 would handle it, though even a Z80 is limited and has a limited set of instructions. For example the IBM Compatables began with the PC followed by XT,286,386,486 and so on or whatever, and even though each processor is compatable with the previous, each processor Intel brought out included a new set of instructions, which in many cases made Assembly more efficent than it's preassessor and why newer Languages are allowed to progress because all of a sudden something which might of required 4 instructions on a XT, came down to 1 instruction on a 286.


I had a look at Some of the languages you've mention, which to me looks like Forth (J for example), Nim looks more of a variation of Pascal, while I can't make Head or Tail of SmallTalk, perhaps it's just Fortran?
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 01:31, 11 January 21
Forth is interesting. A bit raw tough. When I want to juggle with the stack, I'd rather programming directly in assembler!


Nim's syntax ressemble Pascal's, but they are quite apart. Very importantly, Pascal doesn't have functions as first-class values. People obsesses over syntax, but that's a minor aspect of a language. Other differences (copied from there (https://forum.nim-lang.org/t/592)):
Macro system inspired by Lisp.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: zhulien on 15:42, 15 January 21
if smalltalk was made for cpc or another similar high level language, it will be nice if the developer allows for complete memory usage, not just 64k or 128k.  Perhaps utilising a ram driver system.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: zhulien on 15:45, 15 January 21
Quote from: m_dr_m on 16:27, 10 January 21
Good question.
I don't see it as structured. Relying on side effects, no propers functions, no modules, no libraries, no typing, no pattern matching, etc.
Fixing that would give kind of a bloated langage. Visual Basic has its qualities, but I don't want to port that.


I guess I'm not fond of BASIC: quaint, imperative, error-prone, verbose. No nice ways to extend the langage (the locomotive BASIC is convenient due to built-in commands).


I'd rather work on something sexier !


do you want to finish the vb5/vb6 c4oss compiler for cpc?  i can give you the source...  its can compile itself... To retarget to cpc hosted... And only the code generation bit is left to finish.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: funkheld on 17:41, 15 January 21
millfork has not cpc.


greeting
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: toms on 10:10, 21 January 21
If you are interested in this topic, you might also be by this article published on 64 NOPs written by Madram: Rosetta Sugar. J'apprends à coder AVEC mon CPC. (https://64nops.wordpress.com/2021/01/21/rosetta-sugar-japprends-a-coder-avec-mon-cpc/) (french title but english content)
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Targhan on 10:23, 21 January 21
Yup, just noticed it. Interesting!! I'd love a spoiler to know if it ends with a new and efficient language :).
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 00:55, 25 April 21
For the curious, I've compiled different VMs. Just the main `toto_vm.c` file, so that's a lower bound, the final executable would take much more place.


The unit is the number of lines of (ugly) z80 assembler code generated.
With a lot of IX/IY, you could count *3 to have an estimate of the binary size (I didn't bother assembling them, I prefer au doigt mouillé).
So, right now, it is not viable.
The generated code is quite bad. See this extract:



  ld  de, 0
  add iy, de
  push  ix
  ld  de, -992
  add ix, de
  ld  l, (ix + 0)
  ld  h, (ix + 1)
  pop ix
  ld  (iy), l
  ld  (iy + 1), h
  ld  de, -990
  push  ix
  pop hl
  add hl, de
  push  de
  ld  e, (hl)
  inc hl
  ld  d, (hl)
  dec hl
  ex  de, hl
  pop de



Planned (25th May, for now I take a break):




Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: Nemo59 on 09:09, 25 April 21
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) :

https://www.youtube.com/watch?v=nci7r6bi6J8 (https://www.youtube.com/watch?v=nci7r6bi6J8)
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] (hpgcc3.org) (https://newrpl.wiki.hpgcc3.org/doku.php)

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'

or

« 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 }


etc.

Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 15:36, 25 April 21
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:
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]
[/color]Also, I don't believe we should restrict ourselves to tiny languages. The CPC is powerful enough.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: zhulien on 07:30, 26 April 21
want to work with me to finish the code generator on the VB6 compiler and JS compiler?
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 13:25, 27 April 21
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.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: zhulien on 14:35, 27 April 21
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?



Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 20:16, 09 July 21
Both VB and JS seems too big and cumbersome for the CPC.
But I'd happily follow your progress on the subject!
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 20:18, 09 July 21
Since https://64nops.wordpress.com/2021/01/26/compiling-c-to-neat-z80-is-that-even-possible/ (https://64nops.wordpress.com/2021/01/26/compiling-c-to-neat-z80-is-that-even-possible/),
* 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, https://github.com/jacobly0/llvm-project (https://github.com/jacobly0/llvm-project), 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:
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).
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 00:57, 10 July 21
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:

BB0_2:
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
BB0_7:
ex de, hl
pop ix
ret


There are other exemples where the generated code is simpler to ... simplify.
Title: Re: Porting Smalltalk/Joy/Nim/J ... on CPC?
Post by: m_dr_m on 11:23, 13 July 21
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: http://www.z80.eu/pas-compiler.html
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