News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_m_dr_m

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.

m_dr_m

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?


gurneyh

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





m_dr_m

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 :)


AMSDOS

#3
Why do you criticize structured BASIC coding?
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

m_dr_m

#4
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 !



Targhan

#5
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?
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

reidrac

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).
Released The Return of Traxtor, Golden Tail, Magica, The Dawn of Kernel, Kitsune`s Curse, Brick Rick and Hyperdrive for the CPC.

If you like my games and want to show some appreciation, you can always buy me a coffee.

m_dr_m

High Ghan, the steps would be:

       
  • Pure interpretation from bytecode (POC).
  • [Optional] Crude asm extension (e.g. calls to fixed address).
  • [Optional] RSX-like extension.
  • Proper extension with neat FFI (foreign function integration).
  • Embedding (the other way around: using the high level language from assembler).
  • JIT compilation.
  • Native compilation.
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.

       
  • Apollo 11 Computer had 2048 words of erasable magnetic-core memory and 36 kilowords of read-only core rope memory.
  • It can be optimised afterward (e.g. preallocating space for transient local variables, à la C but smarter).


m_dr_m

#8
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  (dos version, only the executable?)

Port from Rosetta / Z80 exidy (improved smalltalk-72)
Rosetta Smalltalk presentation(16k, unoptimised, bubble sort 7x slower than BASIC version on the same machine).
Hard might be hard find (this guy has a prototype, though).
To See: 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/crosstalkurl]  VM C++ for raspberry!

Rewrite VMWriting a transpiler from Smalltalk-Bytecode to PIU-Bytecode

m_dr_m

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).

Targhan

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.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

SRS


m_dr_m


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!

m_dr_m

SRS: Thanks for the link. Note that my goal is to have a language on the CPC, not to cross-dev!

Targhan

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.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

m_dr_m

Let put it that way: it could be cross-dev, but it must be native-dev as well.

Targhan

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.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

AMSDOS


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?
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

m_dr_m

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):
Macro system inspired by Lisp.
  • Export marker taken from Oberon.
  • Argument passing semantics taken from Ada.
  • distinct[/size] types inspired by Ada.[/font]
  • Syntax also heavily influenced by Python.
  • Generics inspired by C++.
  • The 3 pointer like types [/size]ptr, [/size]ref, [/size]var taken from Modula 3.
  • [/size]async / [/size]await stolen from C#.
  • [/size]let taken from ML.

  • [/size]Oh, in the Programming Languages Constellation, SmallTalk could difficultly be further from Fortran!

    [/size]Now, regarding the constraints: it's not a problem for me. On the contrary, it makes the challenge more interesting.
    [/size]Limited instruction set: non-issue. You can do more optimised code on RISC CPUs. Ok, the Z80 isn't nowhere as elegant and slick as an ARM.
    [/size]Also, that's where high-level functional languages can shine: instead of describing the "how", you describe the "what". It leaves more freedom for an interpreter or compiler to generate neat optimised code.

    You advice to remember why it would be a difficult project. I take the opposite stance. To learn, it's better to forget. Forget what (you think) you know, and forget about limitations, including yours.

zhulien

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.

zhulien

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.

funkheld


toms

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. (french title but english content)

Targhan

Yup, just noticed it. Interesting!! I'd love a spoiler to know if it ends with a new and efficient language :).
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

m_dr_m

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é).

       
  • lua (lvm.c): 40496 lines
  • wren (wren_wm.c): 23608 lines
  • gravity (gravity_vm.c): makes clang crash
  • csom (universe.c): doesn't compile
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):

       
  • Try more recent version of llvm-z80 (tested version is from January)
  • Try to apply some peepholes optimisations
  • Try elua vm
  • Try to port a simplified vm





Powered by SMFPacks Menu Editor Mod