News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_m_dr_m

Basic On Mushroom

Started by m_dr_m, 17:17, 26 March 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

m_dr_m

I'm tempted to work on an improved native Basic (*)
Goals are similar to: smalltalk port
  • 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.

GUNHED

Nice idea. Maybe it could help to define commands of that new language first.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

HAL6128

Yeah, I like the idea and a similar approach as in Orgams only with Basic (an advanced compiler)
BOM sounds good in two ways.
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

dodogildo

BOM sounds great!
M'enfin!

m_dr_m

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!

 

Sykobee (Briggsy)

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?

m_dr_m

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)

Targhan

What about something like LUA on CPC?  It is simple, and can be added "modules" for more features, which could be added later.
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

eto

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. 


GUNHED

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.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

#10
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!
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.

m_dr_m

Regarding Lua, I forgot I did some preliminary experiments. 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).

PulkoMandy

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.

m_dr_m

No I didn't try anything. Yep 64 bits would be overkill!

m_dr_m

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.

Targhan

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?
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

djaybee

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.

m_dr_m

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

Deevee

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.
ORIGIN 320,200:FOR r=1 TO 360:PLOT 5*(16*(SIN(r))^3),5*(13*COS(r)-5*COS(2*r)-2*COS(3*r)-COS(4*r)):NEXT

Bread80

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.

m_dr_m

Super cool! Have you seen that https://www.freepascal.org/ can target the Z80?

Also, chainq did some work to port the compiler to MSX and CPC.

djaybee

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

Bread80

Quote from: m_dr_m on 19:59, 11 April 24Super cool! Have you seen that https://www.freepascal.org/ can target the Z80?

Also, chainq 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.

genesis8

I search about FreePascal and found 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.
____________
Amstrad news site at Genesis8 Amstrad Page

zhulien

JS subset so it runs unmodified ina browser but compiles to z80. Has scopes, variables in a class scope and local scope.  Its not meant to be full JS but has limitations, classes force functions within to reside in the same bank, only 1 level of nested functions in a class. No garbage collector except for locals out of scope. No Inheritance,  classes are for scoping and effectively simple polymorphism (pointers to like classes, no interface checking, no modern OOP overhead)

https://youtu.be/q8kBgWHT944?si=8t61v4xY4rCniZwZ

Powered by SMFPacks Menu Editor Mod