Page 1 of 2
multiple architectures support
Posted: Sun Jun 17, 2007 9:14 pm
by Zacariaz
I have a rather, weird, idea, that it might be possible to make a bootloader able to detect the architecture of a cpu. I dont think i can explain it any better im sorry to say.
the way im think this might be dont is actually pretty simple.
it we take an example with to archiotectures, fx. x865 ans ia64.
We start out by executing an opcode that on the x86 would mean jumping to a specific point were we hold our x86 code. in this example i asume, with out know, it is just an example, that in case that it is not running on a x86 platform, the instruction will either be ignored or result in a harmles add instruction or simular. Then the next instruction would of course be an ia64 instruction pointing to the ia64 code.
I could think of other ways of doing this, but this is the basic principle. Do you guys think that this, or simular, wopuld be possible?
Posted: Sun Jun 17, 2007 9:45 pm
by Brynet-Inc
Wow, That's an interesting derivative of English, I'm not familiar with it.
In all seriousness, I don't know if this would be very viable or even worth the time trying to implement.
But I consider myself a debunker, Don't take it personally.
Posted: Sun Jun 17, 2007 9:53 pm
by Zacariaz
As for my bad english i am very much aware that i have certain troubles expressin my self, that is of course regretable, but i hope the message got through anyway.
As for the "idea", i am allso aware that this might not be very useable to most, nut i have an idea, which i am not gonna discuss here, vere it could indeed be useable.
Posted: Sun Jun 17, 2007 11:20 pm
by Colonel Kernel
How would you start executing code to detect what CPU architecture you're running on? For which architecture would that code be written? The whole idea makes no sense IMO.
Posted: Sun Jun 17, 2007 11:33 pm
by Zacariaz
i may not me able to discribe it properbly, but i makes sence, i just dont know if it is possible
to carpe it out.
supose you have a specific opcode which have one effect on one specific architecture and another effect on a different architecture, the by examining the effect of that certain instruction, it should be possible to determine which architecture it has infact run on.
Keep im mind that for this to be possible in any case, it would be nesacery to be somewhat, creative and it would not be possible to write the code in assembly language, it would have to be the actual machine code (is that the right expression?)
Posted: Mon Jun 18, 2007 12:25 am
by JoeKayzA
Zacariaz wrote:i may not me able to discribe it properbly, but i makes sence, i just dont know if it is possible
to carpe it out.
supose you have a specific opcode which have one effect on one specific architecture and another effect on a different architecture, the by examining the effect of that certain instruction, it should be possible to determine which architecture it has infact run on.
I don't believe this is possible, I mean, different architectures (take x86, ia64 and ppc for now) have completely different instruction encodings. An x86 instruction will pretty sure cause an exception on an ia64 or powerpc cpu, and without having executed architecture specific code before, how do you catch the exception?
Maybe this is somehow possible with EFI or OpenBoot machines as they offer an interpreter for architecture neutral code (IIRC) (don't know how it's called for EFI, for OpenBoot AFAIK you can load forth code). In this case you could just read the machine info and boot the right kernel.
cheers
Joe
Re: multiple architectures support
Posted: Mon Jun 18, 2007 12:25 am
by Brendan
Hi,
Zacariaz wrote:I have a rather, weird, idea, that it might be possible to make a bootloader able to detect the architecture of a cpu. I dont think i can explain it any better im sorry to say.
I see what you're thinking, and it'd be extremely difficult or impossible to make it work with 2 different architectures (and it'd never work with more than 2 architectures).
For an example, for 80x86 boot sectors are limited to 512 bytes and must start with a JMP intruction. Itanium uses EFI (the boot loader would be loaded at a completely different address and doesn't have a 512 byte restriction), and also uses groups of instructions (IIRC the CPU loads 4 instructions and does all 4 instructions in parallel). This means the chance of your 80x86 JMP instruction not messing up any of the Itanium instructions in that group is fairly small (assuming that Itanium/EFI doesn't require some sort of header at the start of the boot loader).
In practice, it's much easier to detect what the architecture is when the OS is installed, and then just install the correct binaries for the detected architecture.
However, there are "sub-architectures". For example, for 80x86 your boot code could autodetect things like SMP, SSE and long mode, and then start different code depending on what was detected (e.g. a 32-bit kernel or a 64-bit kernel).
It'd also be possible to have a generic boot image that contains "files" for many different architectures, where the boot loader itself is architecture specific and starts the correct code from the generic boot image. For e.g. you could have a generic boot image that contains a 32-bit 80x86 kernel, a 64-bit 80x86 kernel, an Itanium kernel and a Sparc kernel, and then have 3 boot loaders, where the Itanium boot loader looks for the Itanium kernel and starts it, the Sparc boot loader looks for the Sparc kernel and starts it, and the 80x86 boot loader detects what the CPU supports and either starts the 32-bit 80x86 kernel or the 64-bit 80x86 kernel.
Also, AFAIK the "El Torito" bootable CD format can handle multiple bootable entries, where each bootable entry corresponds to a different platform. In this case the BIOS would select the correct bootable entry (and therefore, the correct boot loader) for the platform. I'm not too sure how widely supported this is though...
If you combine all of this, you could have a single universal "OS installation" CD where the BIOS boots the correct boot code, and the CD installs the correct version of the OS for the architecture (and sub-architecture). Once the correct version of the OS is installed on the computer it'd boot without the CD.
Cheers,
Brendan
Re: multiple architectures support
Posted: Mon Jun 18, 2007 1:08 am
by Zacariaz
Brendan wrote:Hi,
Zacariaz wrote:I have a rather, weird, idea, that it might be possible to make a bootloader able to detect the architecture of a cpu. I dont think i can explain it any better im sorry to say.
I see what you're thinking, and it'd be extremely difficult or impossible to make it work with 2 different architectures (and it'd never work with more than 2 architectures).
For an example, for 80x86 boot sectors are limited to 512 bytes and must start with a JMP intruction. Itanium uses EFI (the boot loader would be loaded at a completely different address and doesn't have a 512 byte restriction), and also uses groups of instructions (IIRC the CPU loads 4 instructions and does all 4 instructions in parallel). This means the chance of your 80x86 JMP instruction not messing up any of the Itanium instructions in that group is fairly small (assuming that Itanium/EFI doesn't require some sort of header at the start of the boot loader).
In practice, it's much easier to detect what the architecture is when the OS is installed, and then just install the correct binaries for the detected architecture.
However, there are "sub-architectures". For example, for 80x86 your boot code could autodetect things like SMP, SSE and long mode, and then start different code depending on what was detected (e.g. a 32-bit kernel or a 64-bit kernel).
It'd also be possible to have a generic boot image that contains "files" for many different architectures, where the boot loader itself is architecture specific and starts the correct code from the generic boot image. For e.g. you could have a generic boot image that contains a 32-bit 80x86 kernel, a 64-bit 80x86 kernel, an Itanium kernel and a Sparc kernel, and then have 3 boot loaders, where the Itanium boot loader looks for the Itanium kernel and starts it, the Sparc boot loader looks for the Sparc kernel and starts it, and the 80x86 boot loader detects what the CPU supports and either starts the 32-bit 80x86 kernel or the 64-bit 80x86 kernel.
Also, AFAIK the "El Torito" bootable CD format can handle multiple bootable entries, where each bootable entry corresponds to a different platform. In this case the BIOS would select the correct bootable entry (and therefore, the correct boot loader) for the platform. I'm not too sure how widely supported this is though...
If you combine all of this, you could have a single universal "OS installation" CD where the BIOS boots the correct boot code, and the CD installs the correct version of the OS for the architecture (and sub-architecture). Once the correct version of the OS is installed on the computer it'd boot without the CD.
Cheers,
Brendan
That was exactly the type of answer i was looking for (not hoping for though)
In reality it is not that important to me, as the x86 is somewhat, "popular" but i thought i could be neat to make the os im planning, work on multiple platforms, as it is suposed to be a mobile os, e.g. you carry it in your pocket on a usb key or simular, the plug it in where you wanna use it. (that is far from the whole concept, but an important part)
anyway, thank you all for the answer, especiallyt the last one which were very discribing.
Regards
Posted: Mon Jun 18, 2007 1:37 am
by AJ
Zacariaz wrote:supose you have a specific opcode which have one effect on one specific architecture and another effect on a different architecture, the by examining the effect of that certain instruction, it should be possible to determine which architecture it has infact run on.
Another technical difficulty - you would need some kind of CMP or TEST-type opcode to see what effect the original opcode had. What machine-language instruction do you use for performing the test?
Adam
Posted: Mon Jun 18, 2007 2:05 am
by Brendan
Hi,
AJ wrote:Another technical difficulty - you would need some kind of CMP or TEST-type opcode to see what effect the original opcode had. What machine-language instruction do you use for performing the test?
Technically, not really. For e.g. if the 80x86 JMP instruction was an Itanium instruction that did no harm (e.g. NOP, ADD, SUB, MUL, etc - anything that doesn't cause an execption or trash something the boot loader needs later), then the difference between instructions sets is the CMP/TEST.
For e.g. if "JMP start80x86" was "ADC R0, 3" on Itanium you could have something like:
Code: Select all
CPU 80x86
jmp start80x86 ; Actually ADC R0,3 on Itanium
CPU Itanium
jmp startItanium
The problem is that the 80x86 JMP instruction is likely to cause some sort of exception on Itanium, and there's also differences between boot loader formats to take into account. For e.g. if an Itanium boot loader must start with a special header where the first dword has to be 0xAA55AA55 then you're screwed.
Even if you're extremely lucky, it'd be very fragile (for e.g. changing the target address of the 80x86 JMP instruction would effect what the Itanium saw as it's first instruction), and it would be exponentially harder the more architectures you try to support. Making it work for 2 architectures would be extremly difficult, making it work for 3 architectures would be virtually impossible, and making it work for 4 architectures would be harder than finding a safe chemical that cures all forms of cancer, AIDs, several other diseases and wrinkles....
Cheers,
Brendan
Posted: Mon Jun 18, 2007 2:09 am
by Combuster
the easiest approach for this kind of thing is to have a series of jump statements for each architecture which, hopefully, do nothing to mess up on other architectures (ALU instructions that don't reference memory?)
But as brendan said, you can make use of the architecture's boot sequence which loads the bootcode from different locations:
x86s willl load the first sector of a disk, or you can use eltorito for CD's
IIRC HPPA machines will look for the IPL header around the 4k mark (works the same with both cd's and hd's)
And if you bother with consoles:
The dreamcast will parse the filesystem of a cd and will then look for 1st_read.bin
The Sega CD will read the first sector of the cd and gets a size-offset pair a few bytes from the beginning.
so all you have to do is put the loaders for different architectures at different places and with a bit of luck you don't have anything overlapping forcing you to go through this 'opcode hell'
Posted: Mon Jun 18, 2007 2:53 am
by Zacariaz
hmm, it that is true, it is great, exept it will probably take ages to learn the working of different architectures.
another question would be which architectures to support. Of course the x86 would have to be supported, but what about other architectures, which is acutally use ordinary people? the ppc of course is still used by many, but does it have a future, and what other architectures might be good thing to include?
Posted: Mon Jun 18, 2007 3:47 am
by Brendan
Hi,
Zacariaz wrote:another question would be which architectures to support. Of course the x86 would have to be supported, but what about other architectures, which is acutally use ordinary people? the ppc of course is still used by many, but does it have a future, and what other architectures might be good thing to include?
To be honest, until one architecture is supported properly I wouldn't worry much about other architectures (2 or more half finished OSs aren't as useful as one finished OS).
The first architecture I'll support is 80x86 - it's a large part of the market, and any computer that doesn't support 80x86 is likely to have a suitable emulator for it.
The second architecture I'll support might not have been invented yet - I'll wait and see what's around in 10 or so years...
Cheers,
Brendan
Posted: Mon Jun 18, 2007 5:16 am
by Zacariaz
Brendan wrote:To be honest, until one architecture is supported properly I wouldn't worry much about other architectures (2 or more half finished OSs aren't as useful as one finished OS).
This is just the planning phase, and i need to get it right before i start anything. I myself suspect that it wont take long before the regular joe only uses x86 but i would like to know if anyone disagrees.
Posted: Mon Jun 18, 2007 8:33 am
by Colonel Kernel
Zacariaz wrote:This is just the planning phase, and i need to get it right before i start anything. I myself suspect that it wont take long before the regular joe only uses x86 but i would like to know if anyone disagrees.
It depends what your target is. A lot of mobile devices have ARM processors, so x86 will not necessarily be everywhere. Game consoles are largely not x86 (Xbox 360 is PPC, PS3 is Cell). OSes run on all these things too.
