Based on my own experiences of writing a bytecode/VM for my BCPL system, then ... I don't know. My system runs at a maximum "clock speed" of ... Well, it takes 29 cycles to fetch and JMP () to the handling code and increment the VM's PC, or 37 cycles when the top word of the PC needs an increment.

So assuming a NOP would take no cycles then assuming 29 cycles in my 16Mhz system, that's say 500Khz. The MicroPython VM appears to be stack based so that's not going to be quick if you implement an external stack for it, so you're down to the 100Khz region (I estimated some 200Khz on average for my VM).

Is that slow? Who knows. It all depends on how much "work" you can get done per instruction and how efficient the compiler is at throwing out those instructions. The BCPL system is very efficient and has instructions to handle variable width data very efficiently.

Possibly another way to think about it might be:

Would this encourage newbies to get into the '816?

I'd suggest no - why would they use a slow old CPU when they can use ARM/RISC-V/Super-H, etc. ?

Although this does fit into my own personal scheme of "what if we applied todays knowledge to yesterdays systems". If only I actually enjoyed programming in Python I'd have gone for MicroPython rather than BCPL.

The calculators mentioned earlier have a 32-bit RISC CPU (Super-H) so writing a MPython bytecode VM for them if probably going to be quite efficient, given a good number of 32-bit registers, 32-bit wide memory, so single cycle operation for more data exchanges and so on.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I'm not keen on looking at '816 applications through the lens of high performance: it should improve on the '02, but not match a modern fast microcontroller.

I think the way to look at performance is whether it is adequate: for a handheld game, for a calculator, for a chess machine, for a 1980's home computer experience. The '816 should be fine here.

Why might a newbie be interested? Perhaps because it's different - they've found something special - or because it's historical (SNES), or because chunky components looks more like a homebuilt machine. Who knows: I think if anyone here makes something, it's mostly for them and for us. It's not to make a fortune or to win a big market.

And the '816 seems well-suited to interpreted code, especially over the magic 64k size.

As to the size of MicroPython, I suspect that the core VM can't be very big: perhaps what's happened is that a number of core python libraries have been converted to C for performance. If so, that's technically not necessary: an 816 MicroPython could instead maximise the amount of bytecode and minimise the amount of C. And it might even be that someone would enjoy coding the core VM in assembly language instead.

But I don't think it's a small project.

Depending on home performance-mad you want it to be, I suspect the core VM won't be that big at all - but I'm basing that on my BCPL/Cintcode VM which is a bytecode for a Very Complex Instruction Set. That's pushing 16KB now - but a big chunk of that is a speed optimisation I made (which is conditionally assembled). I save 3 cycles per VM opcode by in-lining the opcode fetch+dispatch code on every opcode. That adds 22 bytes to every decoded instruction - was it worth it for those 3 cycles? Hard to tell, but I felt I was pushing the limits at that point and I have to replace it with a 3-byte JMP instruction when I conditionally assemble in some more debugging to keep it under my "magic" 16KB limit.

As for the C - yes, it seems a lot of the intrinsics are written in C but I gather there are also MPython equivalents - Not a big show-stopper and in a way I used C early on in my BCPL system to help with the bootstrap and low-level library code until I got the system to the state where I could load the VM, do all its initialisations in ASM then get it to the state where it could directly execute compiled BCPL and after that it was relatively easy - I just re-wrote the low level bootstrap stuff and essential IO libraries in BCPL. Saved a lot of code space too.

Back for MicroPython - so-far, no-one here has publicly stated that they are working on it, (or are going to work on it), however I know from reading other places, forums, social media platforms that there's a shed-load more going on in the 6502 world than we see here. I also know that there are several social media personalities who are deliberately avoiding posting here, although they do read it - for various reasons, so we really don't know what might be going on outside here - it might be that someone already has a MicroPython on an '02 or '816 platform... Really hard to tell until you see their Facebook or YouTube video on it.

I'm going to stop thinking about MicroPython for now - mostly because I still have a million boxes to unpack and properly get our home/office network going after a big house move...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I wish I knew what was giving them pause, so we could attempt to remedy the situation ... this forum seems so comfortable and welcoming to me. I hope it's not my breath ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

No - it's because they want to earn money from YouTube, Patreon and selling things and need to show that they haven't blatantly ripped off something/someone else or got too much help...

This is the world of the "Social media influencer" like it or not that's what it is these days.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That! (unproductive comments removed)

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

(We usually express ourselves less strongly than that, here. I'd much prefer if we continued to do that. Consider what kind of responses or conversation any given comment is likely to give rise to.)

I don't think anyone here should be gatekeeping a hobby, or telling people how they should or should not enjoy technology. I think it's fantastic that teens, 20s, and above are even interested in embedded systems, be they modern 32-bit or historic 8-bit. Even taking the time to blink a single LED, whether it's in Python, BASIC, C++ or just pressing a button on a board shows a level of interest that should be nurtured, not admonished.


On the direct topic of MicroPython, it seems unlikely that a port would be worthwhile from a practical standpoint, but I think it's interesting to think about from a, "Yeah, but if we wanted to?" perspective. What kind of system architecture would it take to get the full VM going? What would be the cost of individual VM instructions to, for example, perform a single memory read from a large address space?

One of the cool things about this site is that it has decades of accumulated musings, and who knows... tomorrow someone may actually try to do this, not because it's useful, but because they can... and maybe they'll find this thread and appreciate the thoughts of experts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The fact that there are so many languages running over a VM or interpreted code, that runs more or less fast is because the speed they get has more to do with the fact that the CPU is running at the gigahertz than with anything else.

I'm not a fan of Python and Java, too.
But I think that the bloat is caused by the libraries.

UCSD Pascal had used p-code, what also seems to be sort of a Bytecode.
So being able to run (at least a subset of) Python or Java Bytecode on a 65816 computer actually makes sense,
since compilation from source code to Bytecode could be done on a PC.

I was won over by Python after doing a few projects with it. The philosophy, or at least use in actual practice, is counter-intuitive to a lot of people coming from other languages. The real strength of Python is that it's so much easier to use than something like C once you get used to it, which saves the programmer a whole lot of time. The price you pay is that it executes much slower for some things, but for a long time now the limiting factor for most PC programming is human time not compute cycles which are plentiful and essentially free these days.

Imagine a programmer has the choice between implementing a program in C, which will take 100 hours, or in Python which may only take 50 hours. If the C version takes 1 second to run and the Python version takes 10 seconds, you could run the Python version 20,000 times before you regretted not writing it in C since you've still saved yourself time. A lot of things never get run enough to make up for the added time investment. In the cases where 10 seconds is just too long, you can always use another language. No one is arguing that Python is good at everything, just that you save time in the long run on some but not all projects. Some of the criticism of Python comes from people using it for things that clearly should have been done in another language from the beginning then whining that it's "slow."

I would disagree that there is a lot of "bloat" if you mean that it's bigger than it has to be for what it does. There are definitely size and speed trade offs, but those are made thoughtfully and offer advantages that turn out to be useful for a lot of people. As far as libraries go, there are good ones and bad ones like on any platform where you let the community create whatever they like. The really good ones like pandas and numpy are actively maintained and high quality. You can use those to process large amounts of quantitative data really fast since they're written in C, so you still get the fast development time of Python without losing as much performance.

As far as MicroPython goes, I didn't hear about this until they started putting it on embedded boards with 100-200MHz ARM processors. I think it only makes sense when you have that many cycles to spare. Running it on a PIC16 seems to be more of a proof of concept to show they optimized well than a practical application. It seems strange then to try to get this running on a 65C816 since you definitely don't have cycles to spare and the tradeoff wouldn't make much sense. On the other hand, I think all of us are here just for fun rather than any practical reasons at this point, so I say go for it if you think porting MicroPython will be fun.

One of those fast ARM boards I saw shows up as a disk drive over USB which holds your Python source. You can edit it right there without copying the file to your PC first then you can run it immediately on the board. The neat thing is you can unplug the board and hand it off to someone else and they can pick up where you left off since the board has the source on it. Something like that will never replace C in embedded, but that type of functionality, along with saving programmers time at the expense of performance, will be valuable in some situations.

Using "PIC16" is an unfortunate choice of nomenclature. What they mean are the dsPIC and PIC24 families. These are reasonably powerful 16-bit machines. As opposed to the PIC16F which is mid-range between the original small microcontrollers with PIC10 and PIC12 at the low end and PIC18 at the upper end.

Indeed Bytecodes or Bytecode VM's aren't new. A very early one was made c1966 for Martin Richards BCPL project, and as noted the UCSD P-System was a form of interpreted pseudo code and now we have many languages which are interpreted pseudo codes - some byte wide, some not. E.G. My BASIC interpreter is effectively a one-pass compiler into a highly tokenised form, but those tokens are actually 32-bits wide but a lot of 8-bit BASICs of the era use 8-bit tokens

I'm always pleasantly surprised at just how fast my bytecode implementation for the current BCPL cintcode VM is, however a lot of that is down to the compiler and the bytecode working together - it's a highly tuned compiler tailored exactly to the generation of the code that's "ideal" for the task in hand. It's not going to win any speed records on my 16Mhz '816 system but it's still nice to use - it may not be so nice on a more traditional 2-4Mhz '816 system though.

I'd like to think that the MicroPython compiler and bytecode systems go hand in hand and the compiler is producing good code for it's own VM - it's then up to the VM implementation to add efficiency where it can.

I think it's do-able on the '816 but like my BCPL system it isn't going to win prizes for speed - but - as a system to get new people into the '816 then then into the depths of more retro computing? Very possible - it's just going to take someone with enough enthusiasm (or money) to actually do it - providing you have a suitable hardware platform for it and right now there are just 3 systems with enough RAM - the Foenix, the Neon816 and my Ruby board - however I'd love to know about more. (Not counting the Beeb816 project and emulators, etc. just physical systems for now)

(Also the Apple //gs of-course for probably the only "real" retro system out there - but cost and availability may put folks off)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Might be worth mentioning Forth too: there are at least 3 ways to implement a Forth, and squinting a bit that can look like a VM or even a JIT.

Although Beeb816 is still at prototype stage, it uses a WDC '816, does work, and is open source, so I'd include it as very nearly being a suitable platform, in the same sort of category as Ruby: a motivated person could make one. There are about three Beeb816 in working order at present, and could be six fairly soon. There's also Daryl's SBC-3, of which a few might be around.

I think my position would be: there's not much obstacle to getting hold of a large-SRAM '816 design, for anyone motivated, so for the purpose of this discussion, it's the software side of a MicroPython port that's the main thing. It should turn out at least as fast as a 1980's Basic, but will never be as fast as say a Raspberry Pi, so don't even worry about that comparison.