Hello, To answer your question without going into gory details, assuming the program was compiled for a 32-bit arch where the pointer size is typically 4 bytes (vs 8 bytes on 64-bit), any code assuming this would need to be addressed, especially bit operations. Generally, it's straight-forward to run 32-bit on 64-bit than vice versa with the 64-bit on 32-bit, due to the latter needing more registers, address space differences etc.
Previously, I've gotten pil21 (and originally pil64) to run bare metal on the RPI4 4/8 GB models. Qemu has an emulator for the RPI3 only (still?) so it wasn't terribly useful, which meant replacing the SD card a bunch of times until I could get a proper REPL booted. Similar to PilOS, it required factoring out C libraries, POSIX and I/O functionality, and adding some C/ASM for bootup and setting up the MMU and exception vectors, before branching to the pil21 interpreter loop (instead of a kernel for example). The interpreter was modified to allow access to system registers from Lisp to handle interrupts and other low level functionality. Everything ran at EL1 (equivalent to ring level 0 on x86) and in a single-address space, so it had access to the entire memory space including the peripherals. What's cool is I could optimize the TLB to reduce misses, which meant Lisp code could potentially run faster, along with less OS overhead like context-switching. I wrote a small UART/RS-232 driver to allow REPL functionality, with the REPL implemented in Lisp (rather than compiled into the interpreter). It was an interesting experience to say the least. As a proof of concept, it was at a stage where it could be bootstrapped from the REPL, i.e. an entire "kernel" could be written dynamically from the REPL - similar to PilOS. Of course, there are other design issues to consider including a muti-core/interpreter design, namespacing security and C support. I'm hoping to attempt it again for the PinePhone or ROCKPro64, when I have the time to create the PilPhone :) Adding to the list, there was also a minimal PicoLisp implementation on JS: https://github.com/Grahack/EmuLisp . It could act as a cross-platform implementation of PicoLisp, albeit with different characteristics, like the ersatz version or pil64 emulator; I wonder if the JIT would make the interpreter faster in certain situations, like with numbers, similar to PyPy. Unforunately, WASM isn't feasible due to stack limitations which makes implementing a GC difficult. Plenty of possibilities! On Thu, Mar 31, 2022 at 11:31 AM Henry Baker <hbak...@pipeline.com> wrote: > Actually, 64-bits is also interesting. I only asked about 32-bits, since > I had lots of old 32-bit machines > around; bare metal on a Raspberry Pi (32 or 64 bits) would also be > interesting. RPi4's are hard to get > just now, but RPi3's run 64 bits (albeit more slowly). > > I haven't played with Arm VM's but I presume that they are just as good as > Intel VM's. > > An aside: if one is executing on a 64-bit machine, how hard is it to > execute a 32-bit 'application'? Can one easily start up a 32--bit thread > inside a 64-bit machine? > > This 32 inside 64 question is purely theoretical (for the moment)... > > -----Original Message----- > From: > Sent: Mar 31, 2022 2:59 AM > To: > Subject: Re: An assembly question from the past > > On Wed, Mar 30, 2022 at 05:13:20PM -0700, C K Kashyap wrote: > > This may be of interest to you Henry - https://picolisp.com/wiki/?PilOS > > Right, but it seems Henry looks for a 32-bit machine, but PilOS needs 64 > bits. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe >
