• Please review our updated Terms and Rules here

MicroPython on IBM PC?

J

jrd

Member
Joined
Apr 29, 2015
Messages
37
The subject of Python came up in another subforum, which made me wonder:

How come no one has ported MicroPython to the 8088 IBM PC?

The minimal requirements, from 256K+12 to >512K, don't seem too high. The C code expects 32-bit ints, but there are C compilers for real mode DOS that have that. Yet it seems it's only been ported to Windows machines. I don't even see a plain 386 32-bit version for DOS.

It may be the porting steps are too convoluted. It is because too many low-level hardware details have to be written? I got a bit lost myself trying to find all the porting steps. Yet I'm surprised no one has tried. Has anyone tried and got stuck?
 
The steps here are clear https://docs.micropython.org/en/latest/develop/porting.html. Create main() for launcher, makefiles, configuration, create I/O handler for the target system.

I'm afraid there is no toolchain targeting 8088 that can do GNU makefiles and modern C.
For 386 32-bit DPMI I guess you can try porting this via DJGPP and for real mode 386 maybe Open Watcom.

But there is an official 386 DPMI Python 2.6 installer.
 
More than the compiler, I suspect the challenge would be adapting any large-scale C program written for a flat address space (particularly one that does in-depth memory management of its own) to a segmented model where any structure/heap of > 64 KB requires special handling just to access and many different segment/offset combinations can point to the same physical address. Those are challenges that modern C programmers have happily forgotten about, but if you're targetting real-mode x86 they remain as inescapable as ever...
 
There is a “16 bit” port of MicroPython for PIC microcontrollers, but those parts are really not quite 16 bit; they have 24 bit program counters and don’t require segmenting the ~256k-ish of code MicroPython requires; they are limited to 64k data segments, but that doesn’t matter a lot since the microcontrollers it targets usually only have 16-32K. It also looks like the C compiler for that platform is pretty adept at handling code that uses long INTs… but yeah, the thing that’s really going to hurt trying to target real mode is the code segmentation.

Strictly speaking the 8088 is fully Turing complete CPU so, sure, you can port any software you want to it as long as you don’t care how slowly it runs. (And how much RAM/disk swap space it takes up.) You could ignore the segmentation issues with the MicroPython code itself by writing a compiler that targets a low level virtual machine that simulates a 32 bit flat memory model and 32 bit ints; the performance would be pretty miserable but if you were clever enough with your compiler it wouldn’t be quite as bad as actually literally emulating a 32 bit CPU.
 
jrd said:
How come no one has ported MicroPython to the 8088 IBM PC?
Click to expand...
Maybe a better question is who actually wants to run Python on the 5150? It's going to be terribly slow. You are much better off using a period correct compiler.
 
Most of the calculator programs written in MicroPython are tiny and nearly instant. Yes, my Casio is faster but those programs should still have a run time under a minute on the 5150.

I think so much of MicroPython's libraries won't apply to the 5150 that it would probably make more sense to design a smaller language sharing Python syntax.
 
Nearly instant on what system? I am fairly confident even QuickBASIC would give MicroPython a beat down on the 5150.

You could gear down a Model T and tow a boat at 2 mph. But it's the wrong tool for the job.

 
Plasma said:
Nearly instant on what system? I am fairly confident even QuickBASIC would give MicroPython a beat down on the 5150.

You could gear down a Model T and tow a boat at 2 mph. But it's the wrong tool for the job.

Click to expand...
Casio FX-9750 GIII with a 59 MHz SH4. Maybe 20 times as fast as the 5150 but if a Micropython program completes in seconds on the calculator, that would suggest durations under a minute on the 5150 which should be acceptable. Yes, there are programs written in Python that are much more complex but those should not be run on either a calculator or a 5150.
 
krebizfan said:
Maybe 20 times as fast as the 5150
Click to expand...

According to the manual/datasheet the SH4A is a pipelined 2-way superscaler (including the FPU*) 32-bit RISC CPU. The 8088 is effectively an 8 bit CPU that can’t do anything in less than four clocks. Calling the 5150 only 20x slower seems more than a little optimistic to me; just running NOPs I’d expect the SH4 to be more like 50-100 times faster, and multiply that by an order of magnitude if they’re both doing 32 bit math.

*Edit: apparently the custom SH4 Casio uses is missing the FPU. But everything else appears to apply.
 
Last edited:
…


Couldn’t resist looking it up: the SH4 claims around 300 Dhrystone MIPs at 167mhz; if the calculator is running at 59mhz let’s call it, I dunno, an even 100? An 8088 @4.77mhz scores around 0.22. So the SH4, ignoring the additional handicaps the 8088 is going to have with word length and memory segmentation, would be expected to run integer code around 450 times faster than a 5150? Sadly that sounds about right to me.

It is positively mind boggling how fast even cereal-box-toy level microcontrollers are compared to 1970’s microprocessors.
 
I'm busy with creating my own OS with its own file system plus its own BASIC, all in assembly, meant to be run on a 8088. For cheer fun. So if someone wants to create Python for 8088, why not?

Regarding the speed difference: it is an extra challenge to let Python run at a decent speed. The problem: there are various BASICs for the 8088 around so I material to compare with at the end. This creation of Python won't. But that partly can be solved by comparing the speed of a program with equivalent programs written in Pascal, C, BASIC or whatever is available.

So who ever is willing to create Python for the 8088, I wish him luck and fun!
 
When you port something to old architecture, on one end you have usefulness of technology that wasn't there, on the other you have the journey and the fun of porting, and the projects land somewhere in between.

With original Minix the landpoint was thoroughly on the 'fun' end. 8088 does not make for an useful Unix experience of multiuser workstation or server, but it can 'act' like one for educational and development purposes. The author was of course 100% aware of this so the 8088 Minix the book version remained just that...a demonstrator, for people that have the lowest-spec PC around. Further revisions dropped XT practically, they still ran ancient CPU opcodes but weren't going to run in 640kb space. The intent was not to have a meaningful Minix experience on 8088 but a glimpse of it.

Python on 8088 today would be completely useless for usage, even for educational purposes. So it won't be there until someone ports it purely for his own fun.
 
Eudimorphodon said:
…


Couldn’t resist looking it up: the SH4 claims around 300 Dhrystone MIPs at 167mhz; if the calculator is running at 59mhz let’s call it, I dunno, an even 100? An 8088 @4.77mhz scores around 0.22. So the SH4, ignoring the additional handicaps the 8088 is going to have with word length and memory segmentation, would be expected to run integer code around 450 times faster than a 5150? Sadly that sounds about right to me.

It is positively mind boggling how fast even cereal-box-toy level microcontrollers are compared to 1970’s microprocessors.
Click to expand...

If one excludes benchmarks that fit inside the CPU cache, the SH line isn't quite as impressive. https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=700 shows 8 queens benchmarks. The 9860GII is 2.5 times as fast as the HP 200LX when both have programs coded in assembly. Obviously, the Hornet is faster than the 8088 in the 5150. The 9750GIII is the 9860GII without a backlight. The replacement of the SH3 with the SH4 in the GII didn't change the performance much.
 
krebizfan said:
If one excludes benchmarks that fit inside the CPU cache, the SH line isn't quite as impressive. https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=700 shows 8 queens benchmarks. The 9860GII is 2.5 times as fast as the HP 200LX when both have programs coded in assembly. Obviously, the Hornet is faster than the 8088 in the 5150. The 9750GIII is the 9860GII without a backlight. The replacement of the SH3 with the SH4 in the GII didn't change the performance much.
Click to expand...

Wait, 2.5x?

The fastest number I see on there for the 200LX is 0.0295 seconds. The assembly score for the FX-9860GII running at 29mhz is .00123 seconds. @118mhz it’s .000315.) Maybe I’m missing something but those results for the SH3 are 24 and 94 times faster than the 80186, respectively? (Which itself is going to be a good 3x-ish faster than an 8088?)

Maybe in the context of this calculator the difference between an SH3 and SH4 “didn’t change the performance much”, but the SH3 is scalar while the SH4 is superscaler. It’s basically the difference between a 486 and a Pentium.

Also, this is also a simplistic fake benchmark that doesn’t care much about CPU word length (some Z-80 powered machines outscore the Hornet), not a huge blob of general purpose C code. For that challenge the SH3/4’s architectural advantages are going to multiply the gulf between them and the 80186, not reduce it.

To be clear, here, I’m sure someone could sit down from scratch and code up a “Python-like” language to run on real mode DOS machines that could work well enough to do simple tasks, but a straight port of real Python… yeah, I dunno.
 
Last edited:
You must log in or register to reply here.
Back
Top