OSDev.org

Khumba wrote:I'd like to see how efficient drivers written in a high-level language can be.

I have some experience with it after writing drivers in BASIC for my OS. Yes it is possible to get reasonably fast drivers, but you should be aware of the many possible cycle eaters that are all around.

If you'd write a disk driver in a high level language, you'd notice no real difference in speed. The main time sink is within spinup and seeking times. Your code only spends a fraction more time setting up those, which is pretty much neglegible over the time spent by the disk, DMA and the appropriate bus controllers.

The putpixel function in comparison was a complete disaster, as the overhead became 10 times as much as the time to pump one pixel to the video card.

Combuster wrote:

Khumba wrote:I'd like to see how efficient drivers written in a high-level language can be.

I have some experience with it after writing drivers in BASIC for my OS. Yes it is possible to get reasonably fast drivers, but you should be aware of the many possible cycle eaters that are all around.

If you'd write a disk driver in a high level language, you'd notice no real difference in speed. The main time sink is within spinup and seeking times. Your code only spends a fraction more time setting up those, which is pretty much neglegible over the time spent by the disk, DMA and the appropriate bus controllers.

The putpixel function in comparison was a complete disaster, as the overhead became 10 times as much as the time to pump one pixel to the video card.

Ah, I see. That's interesting. The"putpixel" equivlant that I wrote in TP seemed to be quite fast. But then again, I was indexing to an array which was ABSOLTE-ed onto the video-memory, which is quite fast.

Edfed: Just because someone rediscovers an old idea does not mean that they did not think of it themselves, just that they weren't familiar with prior art. This particular wheel has been reinvented dozens of times over since the mid-1960s, yet most novices in the field aren't familiar with it because neither of the two systems in widespread use (Windows and the various Unix derivatives such as Linux and OS X) use it. Seeing how such systems are being used more and more in an applications context, and how Windows is supposedly moving in that direction with (apparently the majority of Windows 7 is going to run in CIL rather than native), it is hardly surprising that you would see more and more people thinking of it again.

It is a sound idea, and as has been pointed out already, was used in several successful systems in the past. I remember using a UCSD Pascal system in the mid-1980s that worked like this; at that point the system in question was already ten years old and was fading into obscurity, but that was due to the changing computer market, not any technical weaknesses of the OS.

Hey Shark8, if you're seriously interested in getting a Lisp machine you should check out this site. It surprises me that there is no Symbolics/Genera emulator (even with all the legal issues). Is there not enough knowledge about the hardware?

Haven't written any Pascal, but hey, if you're in real mode, might as well use the BIOS. Played around with Oberon for a bit but didn't stick with it.

Shark8 wrote:... have your MP3 files as objects that know how to play themselves ...

Another great idea; I'm planning on having a generic BinaryFormat object with a "data" byte array, then general document and media types or mixins between that and the actual Png/Mp3/etc. classes to have common accessors at a higher level.

Extending that to directories-as-collection-objects, since an object's name will no longer determine its type, directories would need to determine uniqueness by name and type (ie. object's parent). Plus, it's not so much "open file, read/write, close" as "copy object, manipulate it, write it back", which sounds a lot like a VCS, no? (Lisp machines used a traditional filesystem.) Anyway, hope this isn't getting off-topic. Just part of my utopia .

Interesting, thanks Combuster; in my case, for things that need to be fast (ie. graphics), because there is no ambient authority I can't include primitive instructions for anything driver-like, so there has to be at least a message send. Don't know how to get around that, but perhaps there's some crazy cache use possible, inlining or such. Need to read Sun's papers. I guess it depends greatly on the language.