OSDev.org

I am currently developing for both ia32 and ppc, using what I guess would be described as a HAL (although I'd honestly not until just now consciously connected the two ideas, so maybe I have the concept of HAL wrong here).

My ppc port is far, far behind my ia32 port, simply due to a lack of hardware to test on -- my only ppc-based system is in constant use. Of course, lack of documentation is also an issue...

Documentation and the fact that most people have an ia32 system sitting in front of them (and not an arm, for example) have far more to do with why most of our operating systems are designed around it than fear does. Give me a break.

Perica Senjak asked about HAL -- it's hard to come up with a solid model for a HAL (I've never seen one), but mine just sort of developed with the operating system. Basically, I wrote most of the architecture-dependent code first, so that helped separate what would and wouldn't work on any architecture.

Let's say you had a printk function, for example. You would set up all the text parsing/processing in an area of the code that is compiled for all architectures, and then call a function (different for each architecture/driver) to actually print the text on the screen. I have a common cons_write(char *str) function in both architectures, so i just declare it as extern in my system-wide printk function. Then, I create a shortcut to the folder containing whichever architecture's code i want to compile (say archdep -> arch/ia32), and i do the same for headers (include/archdep -> include/arch/ia32). And everybody referencing those headers just does #include <archdep/lala.h> rather than arch/ia32/lala.h. Each architecture then has its own Makefile, and since I use GRUB and take advantage of multiboot, I start execution in each architecture's own initialisation function.

And you do this for all major architecture-specific functions. You have your main code, where nothing depends upon your CPU type, but it calls a number of functions that worry about architecture throughout. So basically, you're isolating all of your hardware-specific code. Once you get used to it (I imagine it's difficult to reorganise existing large projects in this manner), it's actually pretty convenient.


Wow... first post, I hope it made any sense at all

OK, heres a small point I think windows HAL must be pritty basic because it only ports to i386. Which leads me to ask. Are Microsoft now trying to port to othe architectes? Other wize whats the point in thier HAL. The same carn't be said for it's DirectX HAL however seams it's reasons there are pretty obvious.

The Windows NT HAL works as a motherboard driver and a top-level bus driver; it does not contain the processor-specific code. There wouldn't be any point in it doing so, since Microsoft must recompile the kernel for each architecture anyway, and they assume that different models of each type of CPU work in more-or-less the same way. Instead there are separate versions of HAL.DLL for each architecture on each processor, such as single-processor vs. SMP, AT vs. ACPI, etc.

Currently the Windows NT codebase, in the form of Windows XP, only targets IA-32, IA-64 and AA-64. In the past it has targetted PowerPC, Alpha and MIPS architectures, although some of these were more political than practical and have been phased out.

The DirectX HAL is different from the Windows NT HAL (they just happen to have the same name). The DirectX HAL consists of the kernel-mode graphics driver which both Direct3D/DirectDraw and GDI interface to. It is supplemented by a Hardware Emulation Layer (HEL), which 'fills in' the features that the hardware doesn't support by emulating them in software.

Of course, everyone else is free to have their own definition of what their HAL is. But the Windows NT HAL is a processor-specific driver for standard on-motherboard hardware, not for features of the CPU itself.