OSDev.org

For program to run, it must be executed on a hardware, to be executed on hardware, program must be either compiled or interpreted.

People can very well abstract some hardware specific things out of the way, like if the hardware is using big or little endian number encoding, or if process is communicating over net or to some local another process.

What can be done for possible future cases that actual hardware completely turns into something else? For example if somebody invents. err. lets say. electron solitons and how they could be used as storage devices and for processing basing on quantum mechanics or sth., instead of electronics. Basically, the memory model, execution methods everything would turn somewhat around. This is the extreme case where abstractions wouldn't be much of help, propably(I'm not sure about this, fix if you know better.). But hardware changes whole time, to even make the system somewhat flexible for changes of the underlying system.

What is the best way to abstract away the hardware specific things, and make it easy for future to change world and reality? And how much the absolutely best abstraction can take change from hardware before it breaks? (Like, before the performance penalty turns so big that old programs must be abandoned and new ones must be done.)

I've understood that somekind of onion layering techniques are the only way to make abstractions breakable. Meaning that each layer introduces a simpler and simpler abstraction from the hardware with the layer under it, therefore making it easy to take away a layer from hardware side and modify it to make the system function again on new hardware.

Just use common sense. Abstractions must be meaningful and useful. It seems to me your talk about abstractions is.. somewhat abstract?

What can be done for possible future cases that actual hardware completely turns into something else?

Nothing. You can't abstract something that you don't even know. How can you use something if you can't assume anything about it?

There is only one Perfect Abstraction - it represents anything and everything, and assumes absolutely nothing. Too bad you can't do anything useful with it - there isn't even a lot to talk about. That's pretty much it.

And if you want to design an OS that runs on it.. good luck!

btw, The law of leaky abstractions may be relevant.

IMO the most critical abstraction for hardware in terms of backwards compatibility is binary. As long as we can pretend that our hardware is based on 1's and 0's (even if the underlying implementation changes radically in the future), then we should be ok.

In terms of software abstractions, the ones I like the best are the ones that have no run-time cost (i.e. -- things that the compiler or other static analysis tools can do for you). Here there can really be no controversy.

zloba wrote:btw, The law of leaky abstractions may be relevant.

Thank you a lot!

It would been taken a lot of time for me to get into point to realise that hardware abstractions are not actually what makes life easier, instead they provide completely opposite results. Bad thing is that in advent of intel and their cryptic processor interface design, some of them are required to make the interface a little more user-friendly.

hardware abstractions are not actually what makes life easier, instead they provide completely opposite results

I wouldn't say that.. abstractions do make life easier, as long as you don't take them too far.

They allow to ignore irrelevant details and allow us to concentrate on the useful properties, making it convenient, saving time and mental effort for the important things.

Sorry if I was vague. Tell me if this is wrong:

Some abstractions really make life easier of course. Like you said. Some abstractions allow to ignore irrelevant details. Thought, they shouldn't try hide irrelevant details since developer decides what is relevant and what is not; For different goals, different details are irrelevant. And it is practically very hard and likely to unsucceed.

From my point of view, there are three different kind of primitive abstractions:

• Abstractions which try hide away the underlying implementation.
• Abstractions which spices up the underlying implementation, widening people's chances to get something done.
• Abstractions which takes a bag of implementations, then finds a common enough ground for them and hide away the differences.

Any of them can be a good, but two later can be more likely better choice than the first one. I explain why.

Abstractions which try hide away the underlying implementation may leak, therefore the relevant information from both abstraction and underlying implementation must be known. (explained further in the link zloba posted.)

The programmer who writes the abstractions doesn't know everything what end-users keeps relevant and what he doesn't, if the abstraction doesn't hide anything, it may be useful or not, but at least end-users can touch everything they keep relevant and the abstraction can be put into support by the underlying implementation, therefore allowing it to be smaller than if it'd hide the details.

Abstractions written for handling bag of implementations all same way. They are exceptional for two overlying abstractions since they make similar things compatible with each other. The end-user may still keep some specific things hidden by abstraction relevant, but touching them means ditching the abstraction.

EDIT: Late addition to the list:
Abstraction which prevents access to critical parts to provide security for end-user.

Every abstraction allows you to think of a specific item as a more generic item, where the methods of the specific item are mapped to the generic item. If they match, you're going for an efficient abstraction. If they don't match or when you're using a bad mapping, you're going to get overhead.

When they don't match, each mapping adds an order of magnitude to the speed of the operation. So, if you add O(n) every interface, and you're using 3 interfaces, then you're going to get O(n^3) worse performance than you could get.

Example: When reading a file, you want random access. Most OSes pretend that there is random access to all files, such as on memory disks and harddisks. If you apply this theory to tapes, then you're going to get a whole lot of random seeks. Every average-time of operation for your tape is then seektime + operationtime, which is really really bad. Inversely, you can represent each seek separately. If you use that for harddisks though, you'll get a lot of pointless calls and you'll tend to optimize for locality - which harddisks don't care as much for (seek times aren't in hours or minutes, but in milliseconds) and memory cards don't even notice (they don't seek). That limits your algorithm choice, resulting in tape-optimized algorithms that could be an order of magnitude slower than your memory card algorithm could've been.

Last point, don't stack inefficient interfaces. Finding a file is O(n) on FAT. If you stack a file-ordering mechanism on top of that (explicitly on top of, not beside!) you'll get an O(n^2) or O(n log n) file order. If you then search on that, you might end up with an O(n^3) file search, effectively.

Don't pile abstractions and use abstractions that make clear what the underlying mechanism is good and bad at. Don't hide slowness but more importantly, don't hide power.

Basically, from what i can tell of it all, the trick is to think about what a programmer (or who/what ever) NEEDS to do and was the device (or whatever) under the abstraction DOES. Look at the strengths and weaknesses of what it does and then work from there to find a suitable level of abstraction, if an level is suitable at all.

Someone correct me if this method is complete and utter rubbish because it would help me greatly to know a correct method if this is not.

The website is mostly rubbish. It is only applicable if your abstraction is incomplete or if you don't properly formulate it. If you properly formulate the abstraction, you don't need to know what is below.

TCP was formulated as a reliable service, with the sidenotes that connections are either kept functioning reliably and in order, or lost. There are no guarantees whatsoever on speed, agility or the ability to send through a brick wall. If you try to abstract on an abstraction you don't understand you will walk into traps. If you still insist that abstracting is then wrong, you're just an idiot.

By the way, my car-abstraction (for which in the terms of the abstraction, we won't name a brand or type of) seems to hold pretty leak-free against the weather. Of course, you could buy a convertible...