I'm tempted to work on an improved native Basic (*)
Goals are similar to: smalltalk port (https://www.cpcwiki.eu/forum/programming/i-tried-to-port-smalltalk-to-the-cpc-it-didn-t-work-out-in-the-end/)
- Easier prototyping
- Write fast tools fastly
Three axes:
- New functionalities (E.g. named functions / sub-routines with local variables).
- Faster interpreter / compilation (just in time and/or ahead of time)
- IDE (reuse Orgams goodies like go-to-definition, go-to-next-occurrence etc. Plus step by step debugging).
Now, the most important, choosing the name of the project!
- ACID: Amstrad CPC Intelligent Development
- ACID: Accelerated Creation Integrating DMT
- BASLEV: Basic levitation (ref to Maglev, fastest train on earth).
- BOM: Basic On Mushrooms, "Good" in portuguese
- BRASIC
(*) For now I would be only interested in a collaborative effort.
Nice idea. Maybe it could help to define commands of that new language first. :)
Yeah, I like the idea and a similar approach as in Orgams only with Basic (an advanced compiler)
BOM sounds good in two ways.
BOM sounds great!
Quote from: GUNHED on 23:43, 26 March 24Nice idea. Maybe it could help to define commands of that new language first. :)
I am not sure about that: wouldn't be a brand new language, just incremental changes.
The most important step in my book would be to be able to define multi-lines function. Each variable used in the scope of the function shall be local.
If there are commands you'd like to see, please go ahead!
Do you mean something like this?
First line could be DEFFN repstr$(IN a%, IN b$, OUT result$) if you like this type of structure.
DEFFN repstr$(a%, b$)
result$=""
FOR (j% = 1 TO a%)
results$ = result$ + b$;
NEXT j%
RETURN result$
ENDDEF
and steal DEFPROC from BBC BASIC?
Exactly! With optional ENDDEF (indentation is clearer, cf haskell or python)
I like the idea of reusing DEFFN (must check if the semantic is the same: are the global a% and b$ altered?)
I don't know what DEFPROC brings to the table!
Your example makes me think:
- Generators (cf yield in python) would be great
- The type shouldn't part of the variable (no sigil for Cyril)
What about something like LUA on CPC? It is simple, and can be added "modules" for more features, which could be added later.
Would an adaption of MMBasic make sense? It's designed for microcontrollers with limited RAM. Not sure if it's possible to adapt it for an 8bit processor though.
Well, the above code example already show what I personally dislike regarding programming languages: Lots of needless brackets all over! :-\
Madrams idea is great: The simplicity of BASIC, brackets reserved for math. And some additional (missing) functions / features.
It could help to start with few commands first, then more commands can be added. Also imho the language could be made in a way to be able to run under different CPC-OS from the beginning. This means: Separate two parts: The language itself - and the part to connect to the underlying OS. Imagine a language which can be used under native Firmware, CP/M, SymbOS and FutureOS. :o
Regarding mathematics, especially for SQR and SIN/COS/TAN there are quick routines for the Z80 - way quicker compared to the usual BASIC dialects. :)
Quote from: Targhan on 23:50, 27 March 24What about something like LUA on CPC? It is simple, and can be added "modules" for more features, which could be added later.
Sounds like a great idea! (https://www.cpcwiki.eu/forum/programming/porting-smalltalkjoynimj-on-cpc/)
It has a lot of warts compare to e.g. Nim, but it might be small enough.
I might try to port the VM, following
@PulkoMandy's steps. As GUNHED suggests, with careful separation of system part, to target:
- CP/M? (to benefit a larger community, and CP/M on CPC has become sexy again)
- SymbOs directly? (for less memory constraints?)
Quote from: eto on 08:40, 28 March 24Would an adaption of MMBasic make sense? It's designed for microcontrollers with limited RAM. Not sure if it's possible to adapt it for an 8bit processor though.
The site states: "In its minimal version MMBasic typically compiles to about 94K of flash". Ouch!
It can be good for inspiration, but if I were to port a language, I would prefer start from wren.
@GUNHED. You should try lisp.
Syntax is usually passionately debated, while being the less important aspect, as long as:
- it is consistent
- easy stuff is easy to write and hard stuff is possible to write
Parenthesis are already used for function calls. It makes no sense discriminating user functions from built-in functions, especially if you want to promote functions as first class citizen (ability to store, pass and return functions) and allow generic programming.
Regarding Lua, I forgot I did some preliminary experiment (https://www.cpcwiki.eu/forum/programming/porting-smalltalkjoynimj-on-cpc/msg201124/#msg201124)s. Maybe I should post the results somewhere more visible?
The conclusions were:
- wren seems to have a smaller footprint (while being a more attractyves language)
- it wasn't viable!
But those tests were done with LLVM_Z80, and since then SDCC has improved and generates better code (e.g. calls via register instead of stack handled via IX).
Did you get somewhere with Wren? If I understand correctly, the data format is "evrything is a 64-bit floating point value", with normally unused bits in NaN values to represent non-floating point things.
But I didn't look to see if the languga could be separated from this implementation, and be implemented in a maybe more compact way.
No I didn't try anything. Yep 64 bits would be overkill!
As I said, I'm only interested in a collective effort! So I shall look into smalltalk instead (many thanks for the write-up).
Regarding GC in general: an inefficient one shouldn't matter. Even in 100% dynamic languages, there should be a bit of static analysis for fast allocation/deallocation of local variables.
Best of both world: "stack allocation" like in C for speed, and automatic lifetime analysis not to have to deal with memory ourselves.
I believe you have enough experience to come up with your own language. The Atari ST had its GFA Basic, STOS, etc. Why not a specific one for Amstrad CPC?
I have a few questions for which the answers would help me understand the scope and goals:
-Language-wise, do you intend to be similiar to Locomotive, or intentionally different from it, intentionally similar to some other flavor, or aiming for a novel language variant?
-Feature-wise, do you intent to remain all-purpose (the A in BASIC), or to specialize into a niche? e.g. computing = math functions, games = graphics / sounds, data applications = data structures...
-Development-wise, do you aim for self-hosted development or cross-development? Interpreted or compiled?
-Do you have a specific hardware target in mind? Would you store your BASIC in RAM or ROM. Would you want to work in 64kB of RAM or require 128kB?
-Do you intend to start building directly for CPC, or to first have a portable version running on modern hardware?
Name-wise, ACID is already the Amstrad Cartridge Identification Device, you'll need something different.
Great questions!
My main goal is to have a language that is fast and easy to use (not error-prone, as I don't have all my head), fast to execute, with a good developing environment natively on CPC. There is already much crap on modern computers, i want crap on CPC! Plus, crossdev break my heart.
You can check porting-smalltalkjoynimj-on-cpc (https://www.cpcwiki.eu/forum/programming/porting-smalltalkjoynimj-on-cpc/)for more context!
Under this light, I can answer more precisely.
Language-wise: I'm open to every options! I was thinking of locomotive basic for the 2 benefits in incremental improvements:
- Getting results fast
- Easy to use for CPCists
Feature-wise: Both, my captain. I see it as a design flaw is a language is limiting you unnecessarily.
Development-wise: Native, interpreted, compilable and/or JIT-compiled.
Hardwire-wise: The development environment would make full use of ROMs and additional RAM (like orgams), but the programs built should be able to run on a stock machine. Even on 64k if program+runtime+heap fit.
Bootstrap-wise: Directly on CPC.
Name-wise: It seems "BOM" is bom.
@Targhan I sure will come with my own language (well, 67% sure)! In the meantime, looking for pragmatic solutions that interest more people than just me!
I think an extended Locomotive Basic could be nice.
Old programs would be compatible with it, but a new set of features and instructions for new programs. Also, old instructions could work the same, but be extended with new syntax.
Eg,
PRINT "Hello";
would just display Hello as expected, but
PRINT f"Hello, {name%}";
would work like Python formatted strings. Loads of instructions could be enhanced by optional parameters, and work like in old Basic if those parameters are omitted.
Also, line numbers could still be used internally by the interpreter, but generated from labels by the tokenizer, therefore hidden to the programmer by the editor.
I'm working on a compiler for a language derived from Pascal and targeting the Z80. By aim is for it to be able to self compile at which point it will be able to be hosted on a Z80 (until then it's across compiler). It's not ready for a first release yet but you can see the current state at https://github.com/Bread80/Quiche
BTW my experience is that the majority of the effort is code generation and libraries. Ie. the actual parsing side of things is pretty straightforward. This suggests there may be the potential for some form of common back end which could host multiple languages via a common Intermediate Language structure.
Super cool! Have you seen that https://www.freepascal.org/ (https://www.freepascal.org/) can target the Z80?
Also, chainq (https://mastodon.social/@chainq/112051743115895620) did some work to port the compiler to MSX and CPC.
Quote from: m_dr_m on 03:00, 10 April 24Great questions! I can answer more precisely.
You've provided a wealth of valuable information here. Some might see those as constraints, I see them as guidance that simplifies the problem space.
The biggest constraint I see is being able to run on an unmodified 64 kB machine, which means 40-ish kB available with all the ROMs available. Disabling the ROMs would save about 6kB or so of RAM... but would most likely cost us more than 6kB of extra code to replace everything. That might still be an option for some programs, but might not be a primary use case. More savings could come from messing with the CRTC and have a smaller screen (including using only 2 colors in Mode 1, which gives 1 nybble per byte
In turn, running in 40kB puts heavy constraints on the languages that can be used. I'm personally narrowing it down to BASIC and Pascal, maybe also LISP. Forth and C would fit, but their handling of strings is error-prone. I feel that BASIC is better for beginners, Pascal for slightly more advanced programmers.
Feature-wise: this is where the 40kB constraint becomes interesting: the more features you have in the library, the more you run the risk of filling the RAM with library code and not have much space left for user code, which is an issue given your desire to have a rich library. In turn, this suggests that the build process should strip unused library functions, which implies being able to identify them at build time. That means that a pure interpreter might not be an option, which is an issue for LISP IIRC.
Here's the part that somewhat hurts my brain: I feel that Locomotive BASIC is about as good as an 8-bit BASIC can get. It's going to take quite some effort to build something substantially superior, especially something that couldn't be done with expansions of some form (ROM, RSX, CALL, etc...).
That leaves a few directions in my mind:
-A significantly improved BASIC language (built from scratch). E.g. re-entrancy, named functions, concurrency. More data formats (longer floats, fixed-point, bignums, BCD). Data structures beyond arrays. Support for RAM beyond 64kB.
-A different language, e.g. Pascal.
-Expansions for Locomotive BASIC. E.g. Graphics (sprites, tiles, 3D).
Quote from: m_dr_m on 19:59, 11 April 24Super cool! Have you seen that https://www.freepascal.org/ (https://www.freepascal.org/) can target the Z80?
Also, chainq (https://mastodon.social/@chainq/112051743115895620) did some work to port the compiler to MSX and CPC.
The last time I looked the Z80 output was unfinished. I get the impression it's a lot better now.
But FreePascal will only ever be a cross-compiler.
And I also want to move programming forward a notch or two from old-school compilers.
I search about FreePascal and found https://wiki.freepascal.org/Z80 (https://wiki.freepascal.org/Z80)
If it is up to date, only Spectrum and MSX is targetted, not CPC.
It can use its own assembler/linker or optionnally use SDCC.
It would be fun to use FreePascal to program for Amstrad CPC.