On Tue, Aug 16, 2022 at 9:43 PM Karen Lewellen <klewel...@shellworld.net> wrote: > > On the dectalk discussion, someone shared some sources for the dec > version 4.2 or so that requires actual digital equipment corporation > processor alpha architecture. > apparently dec in 1996, was already working on 64 bit processors for their > own machines.
64 bit architecture isn't the [problem. Instruction sets are. You need to intercept the instruction intended for the real CPU and convert iut on the fly to a comparable instruction on the CPU you are actually using. What you need is a Hardware Abstraction Layer, and such things have been around for some time. As an example, I am an old Palm PDA user. The original Palm PDAs used a 32bit Motorola Dragonball CPU. But there were architectural limitations in the Dragonball CPU chip that made things Palm might want to do down the road difficult or impossible. Palm's solution was to switch to an ARM Cortex CPU design foe the new generation of devices that would run Palm OS 5. But there was an enormous amount of existing Palm OS software for Dragonball machines, so Palm included a Hardware Abstraction Layer in the new devices to do the Draghonball -> ARM conversion in software. It worked because ARM devices were *much* faster. My last Dragonball based device ran at 33mhz. My first ARM device ran at 200mhz. The overhead of on the fly instruction set conversion was not a problem. Curiously, Palm SDKs still built code for the Dragonball, not ARM. It was possible to create ARMlets - bits of ARM code callable from the Dragonball code - for time critical stuff, but you couldn't code Palm apps entirely in ARM code. ()I am aware of one all ARM Palm program, but that was a special case, but never did learn how the developers were able to create it. It would have required permission and help from Palm to do it.) On that line, a chap named Dmitry Grinberg did a lot of stuff for Palm devices that wasn't supposed to be possible. (IIRC, he's at Google these days doing something he's not allowed to talk about.) He successfully got Linux to boot on an *8bit* Atmel CPU. He was intimately familiar with the ARM instruction set, and wrote a HAL for fhe Atmel that converted ARM instructions to Atmel instructions. It took Linux hours to actually boot on the Atmel device, but it did boot. Doing anything with it once it booted was another matter. (I posted about the effort to another tech list and got a "We have drugs for that sort of thing nowadays", referring to Dmitry's obsession about doing it, and I had to agree. I admired Dmirtry's ability to make it happen at all, but felt there were likely better uses for his time.) Is there a software HAL letting you test Alpha code on a different architecture? QEMU. I think. Will anything like that be possible on 16 bit machines under FreeDOS? Given whar Dmitry did getting Linux to boot on an 8bit CPU, I suppose it's technically possible. But I suspect you would start your emulator, feed ii cede, and see what, if anything, you got when you woke the next day. If you're going to do hardware emulation in software, you need a *fast* machine to do it usably. If you have a machine that fast, FreeDOS likely won't be what you'll be running on it as your production OS. ______ Dennis _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
