How does an operating system know what code to run on various CPUs?
Bits
Posts: 414
Windows and Linux are operating systems (OpSys) and they can run on a variety of machines.
1. How does the OpSys load properly for a given CPU?
Will the opSys port its code into a type of converter-function for various CPU?
If my guess above stands correct then...
...I could write a OpSys that runs in the propeller environment with a function that allows it to be converted over to a ARM environment.
1. How does the OpSys load properly for a given CPU?
Will the opSys port its code into a type of converter-function for various CPU?
If my guess above stands correct then...
...I could write a OpSys that runs in the propeller environment with a function that allows it to be converted over to a ARM environment.
Comments
One of the first tools needed for any porting effort is a cross compiler that will take your source and generate a machine level binary for your target machine.
Then you get into accommodating the hardware difference of your two platforms. If you start on a machine that is happy to do serial I/O but are porting to a machine that has a graphical interface and a keyboard port, your port needs to include new code to take input from the keyboard instead of the serial port you are used to and also to deliver output to a graphical display of some sort instead of just sending out a single ASCII character.....this problem/challenge ripples through all the hardware.
Friends don't let friends port operating systems! :0)
If you want to run that same OS and programs on another architecture, say ARM, then you will have to get your OS and programs compiled for that architecture.
You might wonder how this all gets started. Well there are compilers, like GCC, that will not only do normal compilation of C code into executables for the machine they are running on but also compile into executbles for a different architecture. This is "cross compilation". In this way you can build an OS for ARM on your Intel box, for example.
So in short, the answer to your question is that you have to build your OS and its program differently for each OS. In general an OS on one architecture will not run executables built for another and for that you need an emulator.
There are some exceptions. A Linux or Windows OS for 64 bit Intel is able to run 32 bit applications. This is because 64 bit Intel chips have a 32 bit mode of operation.
This handle the lowest level stuff specific to a given processor, and implements a bunch on common functions that the standard code can call while sitting on top.
A simple example is the forth kernel, we write code for the interpreter and simple functions like + and - and fetch and store (to memory), and then we can pretty much port any code from machine to machine. I say "can" because in reallity putting all the detail in the HAL is usually not needed and a PITA and we skip it.
If you look t the discussion for Dave Hien's pfth you can see some of the arguments for and against requiring "full portability"
A HAL is more about abstracting the interaction with hardware like, disk drivers, video, sound, whatever. One could say that a Linux kernel is a HAL. I just ask the kernel to read and write files or even raw disk blocks and it provides the means to do that no matter what kind of disks and hardware connection I have.
In a more nebulous way, a C compiler is a HAL, abstracting me from the details of the CPU. I write my code in C and the same code can be compiled for many different CPU architectures.
As I found following the various Forth threads, Forth is not and has no HAL. Programs are not portable from machine to machine or even from one Forth implementation to another with out some or a lot of work.
That is until the real Forth stands up and is usable everywhere. At that point it will still need a HAL, for example some words abstracting access to I/O pins or serial ports, those HAL words would need to be implemented differently on all machines.
A HAL makes it easier to port code from one hardware platform to another. You would just need to write low level drivers for each platform that provides the interface specified by the HAL. As an example, the HAL would most likely have a way to perform console I/O. The application program would just send and receive characters using the HAL interface, and the HAL drivers would send this to a serial port, VGA or TV display, and receive characters from a serial port or a keyboard. The OS and application programs don't have to worry about the specific interface. That's handled by the HAL.
Programming languages such as C and Forth support a form of a HAL through the use of their standard I/O functions. C is much more developed than Forth in this respect with a rich set of standard library functions for console and file I/O. Forth also has support for standard console and file I/O, but at a lower level. There is a standard Forth language called ANS Forth, which was developed by ANSI. Large programs that are written in ANS Forth can be easily ported from one platform to another. The main problem with Forth portability is that most programs use extended ANS Forth words and non-standard words.
Seems this fat binary technique has been used elsewhere, even on Linux although I had never heard of that before.
http://en.wikipedia.org/wiki/Fat_binary
episode was an example of doing this partly in silicon, treating intel instruction set as the byte-code!
You're getting a lot of theory and current/past technologies on some rather powerful platforms. The Propeller is rather limited in resources, so what are you thinking of trying? Maybe we can target the responses better this way.
Cambridge University has a course on OS development on the Raspberry Pi. It's interesting to read through and work through just to get a feel of what goes on in putting together an OS and the pieces that you need to start building.
Android is a good example. Android apps are written Java and their byte codes run by the Dalvik virtual machine. Which itself sits on top of Linux.
In theory Android apps don't care if the Android machine is using an Intel or ARM processor.
In practice a lot of Android Apps have C/C++ in there as well and won't migrate across architectures.
Linux OTOH, has been ported to various processor families, but it must be recompiled for each one. I have Linux for Mac, Intel and Sun Micro and each will only load with its targeted cpu.
I suppose one could develop a multi-architecture OS that would detect the processor type and load code appropriately, but what a bloody monster that would be! Probably need blu-ray for the installation disk! :-)
However MS is trying again. There is a Windows 8 for ARM (Windows RT or whatever it is called). MS want's a slice of the phone/tablet market which is mostly ARM based.
Mostly curious.
I guess I want to try to create a small "diverse architecture environment" operating system, with or without the propeller.
This is the example of hardware abstraction layer. Once you get linux to come up on a system (by compiling for that system's processor) one can load any "standard" package (via rpm, apget, etc).
I used the forth example since that is closer to doable on a prop (whereas linux remains a little more difficult).Forth is much lower level and does not have a HAL, that done when the forth is proted to the processor, and further work must be done to supply any further degree of compatibility, as degree of cross platform compatibility is an option in forth.
I think what bits is asking for is an operating system level "target compiler" or "cross compiler". Typically a target compiler is directed at the processor or microprocessor, and the OS level stuff is handled separately.
If the goal is to move an OS onto a micro controller like the prop, or from x86 to cortex, etc, there is a BUNCH of stuff for the architecture that is beyond just the processor op codes.
*NIX!
This is an interesting topic that excites some of my old, rusty brain cells and makes me realize how much the world has changed since some of those brain cells were last used.
Curious - bunches of ways to satisfy and scratch that itch.
Some of it will get into semantics: Operating System? Find a Minix or early Linux kernel to study or even DOS, I think there are Open Source versions of that now. Just the kernel, not all the bells and whistles that go into a modern Linux distribution. The OS is really just the basic Kernel that presents the common Linux (POSIX) API, hardware management, security, etc. to the other programs. This used to be fairly simple and straight forward way back when. Now, the linux kernel itself is rather large and flexible. This will give you ideas of what an OS does (and should't do). Even the simplest of OS will be a considerable beast to port from architecture to architecture.
Maybe a common hardware monitor that you could take from architecture to architecture so you would have a known set of commands and tools to poke arounf the hardware as you were developing. Chip wrote a monitor for the Propeller II and the source is in the PII Update BLOG thread. A monitor is a good thing and can make life easier at times. You would still need to adapt it to each architecture you worked with but it wouldn't be that major an effort and would also be a good way to learn the assembler for that hardware.
...and lastly, I'll bring up Forth. Taking something like Dave Hein's new pfth, you have an assembler based kernel supporting serial I/O and the basic words you need to extend the system. On top of this kernel, you add .fth words to add functionality and also to add architecture specific features. It really is a good developement and experimentation tool if you can keep the core standard and then add goodies from your toolbox. What happens is that you tend to extend it away from the standard as you add things and then at some point, it no longer resembles standard Forth. It becomes a personal tool. It's interesting to read abotu Charles Moore and how he has carried hos Forth along and evolved it as he went from job to job and computer to computer.
The game changer in all of the above is the Raspberry Pi and the other single board computers like it that are now available for $35-$50. As a hobbyist/hacker, it's incredible to think of a fully functional Linux paltform with all the features they now offer that you can drop into a project for $35. Need a new set-yop box for your TV? RasPi with XMBC. Need a new home automation system? RasPi talking to an X10 transciever. The list is endless! It's making me rethink my hobby world.
If you want to see a OS that is understandable by mere mortals source code wise and has been ported to multiple OS's look at Niklaus Wirth's Oberon System and compiler. I remember when it was first released, it was the only OS with a GUI and compiler that could be run from a 3 1/2" floppy disk. The nice thing about it the source is easily understandable - provided you can read Pascal type languages. And you still can find ports to most microprocessors. IIRC Atari ST, Amiga, PC, Sun workstations, etc.
Here's a book that describes the OS and compiler.
http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf
Or you can look at 2.11 BSD Unix which doesn't need a CPU with a MMU to work and has been ported to the PIC32 microcontroller. It's totally self-hosted.
http://retrobsd.org/wiki/doku.php
Now if you just want a simple DOS - study a clone like FreeDOS.
If lean and mean and able to run on a 8 bitter like a 6809 go study the Nitos9 for the Tandy.
And if anyone is serious about the subject OS's go get a copy of Andrew Tanenbuam's book on OS's.
On the other hand, FreeDOS is a very interesting continuation of DOS into the world of huge DVD players and GByte SDcards.
I suspect a small version of LInux might be the best for general study. But I also suspect that any Unix OS would not adapt well to a Propeller. From the start, the system was intended for multiple-users and the Propeller is not really enough to adapt to that.
DOS is pretty much a single user OS that evolved out of CPM.
I am rather conflicted as I like DOS for an easy simple file system, and I like Linux for all the wonder Unix utilities that were ported over. I guess it is a matter of porting the utilites to a DOS system from Linux.
Linux has a very very interesting item, called Busy Box.
www.busybox.net
This is where programmers took all the Linux utilities from Unix and various places and compressed them into one tiny binary image. This is something the Raspberry Pi and other non-Intel devices love to use. My wifi router is a Linux reloaded firmware with Busy Box for support of the small Linux system. And this is a very small Linux with no keyboard or monitor, just 5 LAN ports, 2 USB ports, and 2 RS233 serial ports.
You might try learning about Linux on a router for small, powerful OS examples. I can extend the router to be a printer server and a file server with a USB harddisk. It would operated 24/7 with far less power than other servers, and much less hardware cost.
Routers are a very cheap entry platform into tiny Linux systems. Take a look at OpenWRT for pre-compiled ready-to-load images. That saves a huge headache. As someone mentioned above, friends do not ask friends to cross-compile.
Nobody mentioned the vastly complex Make files that are usually required.
http://en.wikipedia.org/wiki/List_of_router_or_firewall_distributions
For Windows, the .exe or .com file extension is a clue that the application is right for it.
For Linux, no extension is required, but rights to execute need to be established.
For Apple, I am not sure, but I suspect it is somehow similar to Linux.
Running on various CPUs can really be about which Intel CPU or AMD cpu. The installation code polls the system for the hardware configuration and works through a database of choices.
And above are mentioned the 'other CPUs' that require a recompile. For these, Linux provides a system of configuration that creates a MAKE file to run with the compiler and the user has to sit down with a text on Linux Kernel and review all the features that he/she might have or want if they are to be included in the kernal build. But since about V2.6, Linux has allowed more of these features to be added and removed after the kernel is built via Modules code. I suspect that Windows has gotten more and more like Linux and follows similar procedures as they work quite well.
For the student of computers, these processes are all easy to study in Linux and very proprietary with Apple and Windows. There are a few other open source OSes - BSD and Minix, but they are very similar to Linux in methods as all evolved from Unix influences.