Possibility for a layer that allows for running of CISC apps on RISC CPU?

[JJ]

Dear computer gurus...

would anyone know if there exists any project attempting to create a
layer that would allow running software made for e.g. x86 (or any
other CISC architecture CPU) on a RISC architecture CPU?

Or are there any cases where the adding of virtualization support has
allowed to e.g. run Windows 7 (CISC version) on a RISC machine?

Any pointers to books of websites about this would be appreciated.

Many thanks,

 

[Andrew Reilly]

Dear computer gurus...

would anyone know if there exists any project attempting to create a
layer that would allow running software made for e.g. x86 (or any other
CISC architecture CPU) on a RISC architecture CPU?

Or are there any cases where the adding of virtualization support has
allowed to e.g. run Windows 7 (CISC version) on a RISC machine?

Any pointers to books of websites about this would be appreciated.

Sure, there have been a variety of shipping products along those lines.

The first one I know of was the "PC Emulator" for the Acorn Risc PCs.
This was a straight interpreter, I believe.

The DEC Alfa fx!32 system was a just-in-time compilation system that was
reputed to have been able to run some 32-bit x86 linux and WindowsNT code
faster than the actual PCs of the day (briefly).
http://en.wikipedia.org/wiki/FX!32

The Transmeta Crusoe was a VLIW processor that used proprietary "Code
Morpher" software to run 32-bit x86, which was probably a similar sort of
animal.
http://en.wikipedia.org/wiki/Transmeta

Almost all x86-64 systems today ship with an x86 emulator in order to be
able to run BIOS code (especially graphics card configuration routines in
the PCI bioses.) This probably works just the same on RISC systems, too.

Cheers,

 

[Joe Pfeiffer]

Almost all x86-64 systems today ship with an x86 emulator in order to be
able to run BIOS code (especially graphics card configuration routines in
the PCI bioses.) This probably works just the same on RISC systems, too.

I haven't paid enough attention to the x86-64 world -- they didn't set
up some sort of mode bit so 64 and 32 bit could coexist, like 32 and 16
bit were able to on x86?

 

[Quadibloc]

I haven't paid enough attention to the x86-64 world -- they didn't set
up some sort of mode bit so 64 and 32 bit could coexist, like 32 and 16
bit were able to on x86?

The chips are switchable between 64 bit and 32 bit, yes, but not with
full flexibility. Basically, there's a mode in which you can run 16
bit code and 32 bit code, and there's another mode where you can run
32 bit code and 64 bit code. And switching from 32/64 mode back to
16/32 mode isn't possible easily... it's a bit like the situation with
protected mode on the old 80286.

At least that's what I remember about this, but I could be wrong. So
they don't need to emulate the x86 to run the startup BIOS screen, but
to run BIOS routines after the machine is running they need it.

John Savard

 

[Andrew Reilly]

I haven't paid enough attention to the x86-64 world -- they didn't set
up some sort of mode bit so 64 and 32 bit could coexist, like 32 and 16
bit were able to on x86?

My understanding is that you can bounce back and forth between 64-bit and
32-bit "memory managed" code (because the instruction set flags are part
of the segment descriptors), but direct-mapped 16-bit is not possible
that way, and that's what BIOS needs. I'm afraid that I've never looked
to find out why.

Cheers,

 

[Quadibloc]

The chips are switchable between 64 bit and 32 bit, yes, but not with
full flexibility. Basically, there's a mode in which you can run 16
bit code and 32 bit code, and there's another mode where you can run
32 bit code and 64 bit code. And switching from 32/64 mode back to
16/32 mode isn't possible easily... it's a bit like the situation with
protected mode on the old 80286.

At least that's what I remember about this, but I could be wrong. So
they don't need to emulate the x86 to run the startup BIOS screen, but
to run BIOS routines after the machine is running they need it.

I've searched for more information on this.

The computer can run in three basic major modes: system management
mode, legacy mode, and long mode.

In long mode, it can switch between 64-bit mode and 32-bit mode. The
32-bit mode does include 16-bit instructions. However, it omits some
older features, and thus 32-bit mode within long mode is not fully
upwards compatible with previous 32-bit processors like the 80386.
Virtual 8086 mode is not available, and segmented addressing is not
available.

In legacy mode, the processor operates exactly as a 32-bit processor,
and has protected mode, real mode, and virtual 8086 mode. According to
Wikipedia, the AMD implementation of this, at least, provides Physical
Address Extension to a 56-bit address to programs in legacy mode.

John Savard

 

[Quadibloc]

.... and the basic problem seems to be that Legacy Mode is a mode of
the whole processor, _not_ of an individual process. So it isn't
possible to run applications in Legacy Mode in a window while the
computer still handles interrupts in 64-bit mode normally.

John Savard

 

[MitchAlsup]

My understanding is that you can bounce back and forth between 64-bit and
32-bit "memory managed" code (because the instruction set flags are part
of the segment descriptors), but direct-mapped 16-bit is not possible
that way, and that's what BIOS needs.  I'm afraid that I've never looked
to find out why.

After a decade of x86 being 64-bits, why can't the BIOS boot, and to
all the other nonOS stuff in a more normal mode?

Mitch

 

[Stephen Fuld]

After a decade of x86 being 64-bits, why can't the BIOS boot, and to
all the other nonOS stuff in a more normal mode?

It is happening, but slowly. UEFI is now gaining more market share, and
is clearly the future. But vendors are reluctant to spend money to
invest in it as long as the BIOS works well enough, and there is the
worry about support for (very) old processors. What seems to be the
real driver for UEFI implementation is its ability to boot from disks
larger than 2 TB.

 

[Quadibloc]

After a decade of x86 being 64-bits, why can't the BIOS boot, and to
all the other nonOS stuff in a more normal mode?

That would break upwards compatibility, you naughty boy.

John Savard

 

[Bobbie Sellers]

Dear computer gurus...

would anyone know if there exists any project attempting to create a
layer that would allow running software made for e.g. x86 (or any
other CISC architecture CPU) on a RISC architecture CPU?

Or are there any cases where the adding of virtualization support has
allowed to e.g. run Windows 7 (CISC version) on a RISC machine?

Any pointers to books of websites about this would be appreciated.

Many thanks,

The Amiga emulators usually run on a Linux kernel translating
68000 CISC instructions Just In Time or otherwise on top of Windows.
The commercial emulator Amiga Forever comes setup to run on top
of Windows but it includes in its distribution CD the emulator
running on the Knoppix core. There are one or two others
designed to run classic Amiga OS 1.3-3.9 on a Linux kernel
as described above. I saw the preview of this system which
was priced fairly high compared to AF but ran faster than
my Amiga 2000b/68060@50 MHz on a 500 MHz Pentium laptop.
My impression is that these are systems for gamers more
than for people who did office style work as I did on
the 2000.
The creators of the emulation software got into
a clash which affected further sales. While the system
had updates available online via the AmiNet server &
mirrors system for a while the worries over the licensing
of the IP kept a lot of folks from buying the product.

I have given up on the Amiga as the Linux systems
like Mandriva and Ubuntu with Gnome or KDE provide a
comparable experience. Plus they have memory protection.
I still have the Amiga sitting next to me waiting
for repairs before I donate it to a CBM/Amiga-UG in the
Central Valley of California.

later
bliss