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,

On Sun, 10 Apr 2011 17:12:31 -0700, JJ wrote:

> 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,

--
Andrew

Andrew Reilly <areilly---@bigpond.net.au> writes:
>
> 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?
--
It's time to try defying gravity

On Apr 10, 8:17*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Andrew Reilly <areilly...@bigpond.net.au> writes:
>
> > 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?

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

On Sun, 10 Apr 2011 20:17:18 -0600, Joe Pfeiffer wrote:

> Andrew Reilly <areilly---@bigpond.net.au> writes:
>>
>> 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?

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,

--
Andrew

On Apr 10, 8:29*pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Apr 10, 8:17*pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>
> > Andrew Reilly <areilly...@bigpond.net.au> writes:
>
> > > Almost all x86-64 systems today ship with an x86 emulator in order tobe
> > > 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?
>
> 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

.... 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

On Apr 10, 10:03*pm, Andrew Reilly <areilly...@bigpond.net.au> wrote:
> 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

On 4/11/2011 8:44 AM, MitchAlsup wrote:
> On Apr 10, 10:03 pm, Andrew Reilly<areilly...@bigpond.net.au> wrote:
>> 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?


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.


--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Apr 11, 9:44*am, MitchAlsup <MitchAl...@aol.com> wrote:

> 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