On Hardware Abstraction Layers

[Love4Boobies]

Hi.

I'd like to open a topic on HALs. What do you think would be the best way of implementing one? How does your OS handle it? There can be many designs; take for example Singularity which is certainly different from most OSes in this respect. What would be the best way to support as many architectures as possible?

[DeletedAccount]

Hi,
Yup Windows has one .Contarary to popular belief ,Windows really is a portable operating system . Porting it to different architecture would mean only rewriting the HAL and some small modifications here and there .
Regards
Shrek

[Love4Boobies]

Well that's the purpose of the HAL in the first place. However, that does not answer my question I am not even sure how it is usually implemented. Is it implemented by putting architecture-specific stuff in #ifdef's? (P.S.: This probably should have been discussed in the OS Development section, but I also want you oppinions on different implementations).

[DeletedAccount]

Hi,
HAL is usually a seperate module that rests below all the other higher level layers .It is a seperate module in itself and very much platform specific . I am not however a big fan of macros , using macros lead to hard to read code , as well as code that's difficult to debug .

Regards
Shrek

[kasper]

Hi,

Is implementing a HAL not just carefully separating interface from implementation?
(I'm probably missing something, sorry)

You can implement the separation of interface and implementation:

• Via the linker: different compilation units for different platforms, each containing the same functions.
• Function pointers: adapt to changing hardware at runtime.

And if you want something more exotic:

• Dynamic routing of messages: depending on the system state the HAL layer chooses a different implementation.
• Internal electronic auctions: probably costly, but perhaps it produces adaptive behaviour beyond that of dynamic routing.
• JIT compiling or JIT linking

Kasper

[Love4Boobies]

Via the linker: different compilation units for different platforms, each containing the same functions.

This is pretty much the same as using #ifdef's, only you have more code to write.

Function pointers: adapt to changing hardware at runtime.

This would increase the size of the binary. I can't see any reason for doing this.

Dynamic routing of messages: depending on the system state the HAL layer chooses a different implementation.

I've never heard about this. I'll search it on the web. Would you like to elaborate?

Internal electronic auctions: probably costly, but perhaps it produces adaptive behaviour beyond that of dynamic routing.

The purpose of the HAL is to be a portable layer on top of hardware. It wouldn't really be a HAL if it were in hardware, would it? Besides, it wouldn't be flexibe or extensible.

JIT compiling or JIT linking

That's why I mentioned Singularity Still, probably Bartok has a HAL of its own (using #ifdef's). I'm not sure.

[Colonel Kernel]

Via the linker: different compilation units for different platforms, each containing the same functions.

This is pretty much the same as using #ifdef's, only you have more code to write.

No, it's different because with the linker, different HALs can be selected at boot time, while with #ifdefs the right one must be chosen at compile time, which greatly limits its usefulness.

To clarify a bit what the Windows HAL is for: It abstracts away machine-specific detail, not just architecture-specific detail. For example, there used to be (and maybe still are) different HALs for uniprocessor and multiprocessor x86 versions of the NT kernel. The latter HAL uses the local APIC, while the former HAL (I believe) uses the old PIC instead, among other differences. I think there are even different HALs for different motherboard chipsets.

The existence of a HAL doesn't mean that the rest of the kernel outside the HAL cannot contain architecture-specific code, and that code is usually managed with #ifdefs, or different source files/make files, or some other compile-time selection mechanism.

JIT compiling or JIT linking

That's why I mentioned Singularity Still, probably Bartok has a HAL of its own (using #ifdef's). I'm not sure.

<rant>
For the umpteenth time, Singularity does not use JIT compilation! Sorry, I just get frustrated when people repeat false information instead of going to the authoritative source.
</rant>

I don't recall if Singularity has a separate HAL either... It's quite architecture and machine specific I believe, since it is just a research OS and was not designed to be portable. There is no reason in principle why it couldn't be designed that way, but if it were it would work in a similar manner to Windows, since the compiled Singularity kernel is just native code and doesn't use any JIT compilation tricks.

[Combuster]

Function pointers: adapt to changing hardware at runtime.

This would increase the size of the binary. I can't see any reason for doing this.

If you use C++, you'd have classes, vTables, and most of the appropriate function calls would be done via a pointer already

Dynamic routing of messages: depending on the system state the HAL layer chooses a different implementation.

I've never heard about this. I'll search it on the web. Would you like to elaborate?

Think microkernel, message passing, ...

[JohnnyTheDon]

For loading modules in general (it would work with a HAL, but I personally don't use one) I use an initialization function in the module. All the kernel does is call the entry point in the module's file (designated in the module's ELF header) with a pointer to a table as the only argument. The table contains a list of all the functions that the module needs to use. As long as the module is compiled as position independent code, this works just fine. Position independent code can reduce performance, but my OS runs on x86_64 (where RIP relative addressing reduces the performance impact of position independent code). You might want to load your HAL at a specified address, so it doesn't need to be position independent.

[kasper]

Hi all,

Internal electronic auctions: probably costly, but perhaps it produces adaptive behaviour beyond that of dynamic routing.

The purpose of the HAL is to be a portable layer on top of hardware. It wouldn't really be a HAL if it were in hardware, would it? Besides, it wouldn't be flexibe or extensible.

I didn't mean in hardware. Probably the word "electronic" put you of. I used electronic auctions to contrast them with regular auctions, like those at Sotheby's. An example of electronic auctions are those at eBay. (A habit useful in the context of AI, but redundant in OS dev since everything is electronic )

We could use auctions in a more wider setting. For example on mainframes and in distributed computing auctions can divide computing power among tasks. For the HAL the auctioned tasks or resources are more diverse than just computing power: they would include displaying graphics to the end user, storing data, etc.

But this is a different level than (JIT) linking, ifdefs, JIT compiling, etc. It can come on top of dynamic message routing, which I mentioned before.

Kasper

[Love4Boobies]

Would a compiler (properly) supporting SEH make it possible to NOT include interrupt support in the HAL?

[Colonel Kernel]

Would a compiler (properly) supporting SEH make it possible to NOT include interrupt support in the HAL?

I don't see how, given that SEH is about exceptions, not interrupts, and therefore has nothing to do with the PIC or APIC. Managing the PIC/APIC is one of the primary responsibilities of the HAL.

[1234]

[post deleted]

[Troy Martin]

*cough*illegal*cough*

I'd go with ReactOS instead of hacking code out of Windoze.

[1234]

[post deleted]