Be honest though, a compiled program and one running under an interpreter are different animals. You can't (sensibly) edit the target code from a compiler and it can only run on specified target hardware. This is the (heavy) price you pay for that extra speed.

Long ago I used YABasic for Win95 that used a hybrid approach. When you typed RUN the source code was compiled into RAM then run.
This results in a brief delay but then runs very fast.

YABasic = Yet Another BASIC

  zeitfest said  

Is there a Python compiler ? Using that would be a fairer comparison.

If you mean "compile to native binary", then no. Certainly not for MicroPython.

All Python is compiled to bytecode rather than interpreted. You can skip the initial compilation delay for libraries by using the mpy-cross compiler. The binary mpy files are much quicker to load.

You can have various bits of your MicroPython code go faster using the Native and Viper decorators, but there a limitations to those. They won't take all code and make them faster (or, in the case of Viper, work at all).

I'd respectfully suggest we need a new benchmark suite now we're seeing benchmarks with run times in the milliseconds. Jitter in the timers must be a few of those decimal places.

I should probably explain how this works. "I" have written a clever transpiler that converts the Basic program to C. Then the C compiler takes this and compiles it into the executable.
The executable actually links and is run by a sort of library that resolves system calls and other code that isn't included in-line by the compiler. The performance is about a quarter of that of an executable cross compiled on the PC with full optimisation. For example the rp2350 clocked at 375MHz gives a dhrystone rating of about 380,000 running under Fuzix. My compiler gives about 90,000 ( A Vax 11/780 has a rating of 1757). However, it is completely stand-alone, you can write code on the PC3, compile it and run it. The compiler is fully C89 compatible save for bit-fields and has been qualified against C89 test programs. There is one main limitation - single file only i.e. a compiler but no linker.
The transpiler can deal with the solar eclipse basic program (>3000 lines of complex math) and compiled on the PC3 this runs in 3.2 seconds vs 13 in MMBasic. This ratio is less than many examples because much of the code is double precision math where the compiler gives no advantage. The manual shows what bits of Basic are covered so far. Currently I am getting the MMbasic editor to work under Fuzix (80% there) and starting to implement graphics support in the compiler (PIXEL command and function working)

  matherp said  

"Micropython is faster than MMBasic"

but not when MMbasic is compiled.

Interim results for the MMbasic compiler under Fuzix on the Pico Computer 3,  i.e compiled on the rp350b itself

BM1     BM2     BM3     BM4     BM5     BM6     BM7     BM8
0.0015  0.0027  0.0170  0.0156  0.0231  0.0323  0.0472  0.0239  PicoCom3 Micropython      252000KHz
0.0012  0.0021  0.0189  0.0153  0.0217  0.0281  0.0417  0.0195  PicoCom3 Micropython      315000KHz
0.0016  0.0219  0.0352  0.0320  0.0492  0.1374  0.1104  0.0458  PicoCom3 MMBasic          315000KHz
0.0011  0.00026 0.00078 0.00076 0.00144 0.00709 0.01204 0.00854 PicoCom3 Compiled MMBasic 375000KHz

Awesome    

But methinks BM1 is a typo for compiled MMBasic

No, it isn't the MMbasic code for a small loop ends up in cache and executes extremely fast. As soon as the loop grows to require flash reads things start to slow down

Hmmm, still a bit confused how a loop with code (BM2) runs four times the speed of an empty loop.

My simplistic coding is pretty much BM2, BM3, BM4....Boy am I in for a boost  

  matherp said  

I should probably explain how this works. "I" have written a clever transpiler that converts the Basic program to C. Then the C compiler takes this and compiles it into the executable.

There is no end to your work!  

Thank you.

But, the critical advantage I see with this is not the speed. It allows a simple level of obfuscation to the code, which is currently not available with BASIC (I think?).

I have often thought that the CMM2 would make an excellent smart terminal for an inventory/point of sale system (going back to a central PC server).

In Canada, we have a giant chain of shops called Canadian Tire, and they still use a text based point of sale system running in what looks like a DOS/Text environment. It works great for them. Mice, Windows and touch screens don't really add much to the efficiency of this sort of single use system.

Someone could develop a CMM2 version and having the CMM2 part compiled would help lock down the program so that tinkering fingers couldn't copy or edit the program.

Pete,

Although I am impressed with the speed at which things happen, I cannot ignore the reality that a picomputer3 is a raspberry pi 1,2 or 3 with less "umph".

Implementing python on it brings ti more in line even. And now with Fuzix, this is even more.

For such a large project as Canadian tire, you might consider a pi. And use freebasic compiler.

The pi platforms have been around for 10 years, there is a company behind it that ensures the hardware you buy actually works. JLC won't. As we have seen wuth 'dud' hub chips.

Volhout
P.s. or use a x86 platform, linux, freebasic or even BasCom (does the same thing, transpile basic to C.)

I think you have to be very careful with a PoS system. As the software supplier you can't afford to take any risks whatsoever of the system misbehaving under any operational or fault conditions. You could open yourself up to massive claims if anything fails. There are reasons why they tend to run on old, but hardened, operating systems running on low-powered hardware. It keeps things simpler and less likely to break.

Also, in these days of accessible AI you can't really regard any code in any language as secure. What used to take 20 years to crack can now be done overnight.

I remember the guy who administered the company Unix system, getting all excited about his new server "it can do THREE MIPS!!!" (80386)

Mobile devices are the only way to go. Biometrics, NFC, connectivity, QR code scanning.

Hi Harm,
I think you need to treat it as a completely separate project, pretend it's not Peter creating it.
MMBasic standard, is now about as complete as it's going to get other than bugs & I'll be using it for the foreseeable future because it's easy & reliable, my solar fridge controller has been running for at least 3 years now with no interventions, I'm currently writing a controller for some full sized solar panels a 2.5Kwhr battery and a small grid tied inverter, to get the best utilisation out of 4 East/West panels, as far as keeping battery topped up and inverter running for the best length of time without reverting to mains power/charging & it's the web version so I can monitor or override things when I know better than the algorithm, like I know it'll be sunny tomorrow it doesn't. I very much hope this will similarly run for multiple years with no interventions.
The Python and Compiled Basic are simply other separate projects.
Regards Kevin.

  Bleep said  

I'm currently writing a controller for some full sized solar panels a 2.5Kwhr battery and a small grid tied inverter

Very interested in this project.

Not just that, Kevin. I think one of the points that Harm was making is that there has to be a responsibility for the hardware as well as the firmware/software. JLCPCB make PCBs, that's their job and they will test them to some extent after manufacture. They will also mount components on them if you tell them what you want and where you want it. They won't, however, take any part in the design or testing of the final assembly. That's up to you. They don't know or care how or if the final board works as that's not their responsibility, that ended with testing the bare PCB.

Hasn't that always been the case? unless you just want a bare Pico2040/2350; which is OK if all you want to do is talk to it through a terminal.
You have always had to add your own peripherals, SD reader, sound, VGA/HDMI USB hub... I have several boards in front of me which apart from the Pico I built, you have created several yourself; one of my LCD ones is loosely based on one of your PCBs that you very kindly sent me, taking the chance on having JLCPCB build one for you is a nicety, but a new development, as dddns is attempting, you can put together your own Pico3, if you so choose! At the moment I'm using the previous HDMIUSBI2S design, which also works with Python & Fuzix.
Kevin.
Edited 2026-08-03 23:20 by Bleep

Kevin,

When you are talking about a nation wide network of dealers, you want to make sure the hardware is reliable.

And an off the shelf pi3 or 4, can do exactly the same as a picomputer3 (hdmi, keyboard, mouse, sd card, wifi, bt, even wired ethernet), runs pyton, half a zillion compiled languages, and the hardware is proven to be reliable. And when it fails you can buy a replacement in retail.

That is a major thing. Businesses cannot afford to have equipment fail on them. Every hour until it is up and running again is financial loss. That is why they still use the DOS based systems. They do not fail.

Volhout

The only reason to use propiaritary hardware is when you absolutely need it.
Edited 2026-08-04 02:16 by Volhout

Hi Harm,
Isn't this for a hobby? I would never expect any commercial product to be made using MMBasic or Fuzix or a Pico3 board running an interactive version of Python.
Whereas, getting people interested maybe even enthusiastic in electronics and or programming and or migrating to other languages and playing around with the possibilities, then why not.
Or simply just old retired programmers like me, who can't be dealing with working out what all those external libraries are doing, which of the many to use, and then actually managing to use them!
Kevin.

You can't add peripherals such as a SD card to a Pico or overclock it or even run MMBasic on it and sell the result without losing Raspberry Pi's support for it, Kevin. Even MMBasic may be using registers or memory addresses in a way that they don't test for. You are using the Pico out of spec. It may be very cheap and easy to replace, but that's not the point. Long term reliability is the key and running things outside the specification is a no-no. You can take on the hardware support if you wish, but you can't go back to Raspberry Pi if you start to come up against strange faults that may or may not be hardware related, it's not their problem.

Sorry Mick,
I don't understand, I have never said it should or even could be used in a commercial product? & I definitely wouldn't expect any support from Raspberry Pi. Please see my comments immediately above yours.
Regards Kevin