Hello,
Do you remember that we talked quite a while ago about an ARM Assembler in Basic?

After finishing some other projects I gave it a second thought and this time it worked. I created an assembler suite containing a
 - a Thumb/Thumb-2 assembler for a cortex-M7
 - a disassembler to view CSUB code
 - file format converters from
   - bin to CSUB
   - CSUB to bin
   - ELF to CSUB
 - an assembler include file for the MMBasic API

Maybe this is the most useless programm since the book "How to learn French" was translated to French, but to my surprise you can do real work with it.  

It is a 1.5 pass assembler, which uses some private arrays to encode forward references without a second pass. As a result, it needs some help with some encodings once in a while. It only supports Thumb (16 and 32-bit), one processor (cortex-M7) and only a limited set of assembler directives. It cannot live up to the arm-non-eabi-as or the gcc but it works.

You can find the code on github.com: CMM2 Assembler Wiki

Tell me what you think.

Cheers
 Matthias

Does this mean the possibility of mere mortals being able to create CSUBS?

  PhenixRising said  

Does this mean the possibility of mere mortals being able to create CSUBS?

Probably easier to write them in C than ASM but still only easy if you know C.

This looks an interesting post, bearing the above in mind.

John

Oh, I'm not afraid of C but I understood that the tricky bit was creating the CSUB for MMBasic.

The way I read the above is that not only asm code but also C code can be processed to be oven ready.

Again, I am the master of misinterpreting  

Hello,
Yes, the converter ELF2csub.bas will convert cross compiled C-code into an CSUB, too. But ths was already possible with the tool armcfgen143.bas, which is part of the firmware package. I just included it to have everything in one place and anyway, elf2csub-bas mimics its behaviour.

The problem of mere mortals is not to create a CSUB but to write something in C or assembler that pushs an MMBasic program really forward. I just paved the road, you must now walk on it (sorry, but I don't want to stress the citation from Matrix again, with the door or so.   )

Matthias

  PhenixRising said  

Oh, I'm not afraid of C but I understood that the tricky bit was creating the CSUB for MMBasic.

I don't see it as tricky, particularly as there's a detailed writeup with examples.

However, what is needed in C and why?  Mostly the CPU is doing not much (waiting for I/O or a timer).

(This would be somewhat less true if PIOs didn't exist.)

John

I'm pretty sure that in most instances CSUBs aren't needed now. They were handy when MMBasic was less developed but a lot has happened since. I suppose they are handy if you want to make your programs unreadable, unsupportable and incompatible across different platforms and versions of NNBasic though. ;)

Better Day here. I come from c+4 and startet with 6502 asm and z80 later
So i like your idea🫠
I start building the same mon as +4 but feel i cant become to the end

Start with chatgpt helps me lot
Also building a compiler for mmbasic was a dream💪💪 Maybe a smarter guy like the idea also

Gtx

  Mixtel90 said  

I'm pretty sure that in most instances CSUBs aren't needed now. [...]

You can certainly provide an example.
Anyone making unusual claims must also provide evidence.
Regards
Michael

You seem to be asking someone to prove a negative...

John

My point is that many previous CSUBs have carried out operations that are now native commands in MMBasic. That was out of necessity at the time. I'm not saying that there is no place for CSUBs now, but that the need for them is less. I don't think this is any sort of unusual claim, just logic.

I stick by my argument that there is no place for a system that deliberately makes a MMBasic program incompatible with other versions of MMBasic or other MMBasic platforms unless that is the desired result. If you feel that you need a CSUB then perhaps your approach to the problem is wrong and that you should look for a more standard way.

Embedding machine code in a program written for an interpreter went out with the Z80 and 6502 based BASIC interpreters, which were nowhere remotely close to the speed of a modern one. There was sound reasoning for it then but it should be discouraged as much as is reasonably possible now, IMHO.

If you are using a Pico then a single PIO can execute an instruction on every clock cycle. It can do that without involving a CPU. That's infinitely faster than any embedded code you can even imagine.  :)

Hi Mick,
Thanks for your reply!
I asked because I can't recall any CSubs presented here in recent years that I found unnecessary.
I'm thinking of a short CSub by Epsilon for a CMM2 editor to enable scrolling, or a Mandelbrot program that was very fast, or the brilliant "Bad Apple" program, or even my CMM2 Game of Life, which was 50-100 times faster than the BASIC-only version.
For me, CSubs are an option; nobody is forced to use them. It's also more laborious and time-consuming than writing pure MMBasic code. Additionally, the support could be improved. I greatly appreciate the freedom to use an appropriate tool when needed.
And of course, I expect the C source code to be included when someone presents their code here. That's good practice.
I doubt that PIO assembler is a better solution in the examples mentioned above. I also doubt that the code would be easier to read than C code.

And indeed, I have written assembler code for both the ZX81 and the C64, but that was a long time ago... Incidentally, I recently finished an input routine (multi-line, up to 254 characters allowed, full cursor control), and I wondered how that's even possible in BASIC.
Regards
Michael

"If you feel that you need a CSUB then perhaps your approach to the problem is wrong and that you should look for a more standard way."

CSUB provides an escape hatch if one is really needed.    Many people that use CSUB use it because the bulk of what they are doing can be done easiest in MMBasic.   But for some really picky timing or something that needs a special hardware feature, they can open the hatch and do what they have to do.    

If the CSUB is too big, maybe they shouldn't even be doing the rest of the program in MMBasic.   But for simple small things, it is a very nice feature to have available.

  Mixtel90 said  

I stick by my argument that there is no place for a system that deliberately makes a MMBasic program incompatible with other versions of MMBasic or other MMBasic platforms.....


If you are using a Pico then a single PIO can execute an instruction on every clock cycle. It can do that without involving a CPU....

PIO=Incompatible with other platforms

My secret weapon in the DOS days was QuickBASIC + MASM. Talk about rapid development.

I see the PicoMite as an evolution of this  

  twofingers said  

I doubt that PIO assembler is a better solution in the examples mentioned above. I also doubt that the code would be easier to read than C code.

Michael

Anything that needs an ALU cannot be done with PIO. It is not capable of doing more than decrement a value, invert a value, and compare if zero. For the rest it is moving data to and from pins. If you (as in the Pico Logic Analyzer) need to do logic AND of 3 signals, that is 3 separate instructions with conditional branches in between. The ARM can do that in one clock (and thus is 6x faster).

So NO, PIO can never do any of that.

Volhout

P.S. And PIO does not have access to any RAM it can read/write to. only RX FIFO and TX FIFO, and these are uni-directional. So no random access R/W memory. Only X and Y registers.
Edited 2026-05-06 16:17 by Volhout

@Harm,
That's how I understood it too. Thanks for the clarification, that helps prevent myths from spreading!
Kind regards
Michael