On 22/12/2010 06:42 PM, Darren New wrote:
> Orchid XP v8 wrote:
>> Perhaps. I guess it kind of depends on what you're trying to do. If
>> you have an application that just does its computations in its own
>> little world, then it's fine. If, on the other hand, the application
>> wants to do arbitrary stuff with the whole machine, then... yeah.
>
> Not necessarily. There are memory models that really just don't mix, for
> example. GCed memory with non-GCed external resources is the classic.

And yet, code written in languages assuming GC management and languages 
assuming manual management can not only interoperate, but even be linked 
together in the same process image.

> This paper describes how if you assume you have a C-like/Pascal-like
> workload, using thousands of page faults a second to do GC isn't going
> to be efficient. Etc.

True enough.

>> Wasn't there an OS written in Smalltalk at some point? (Or was that
>> only for special hardware?)
>
> Yes. The "dolphin" computer. It had programmable microcode, so when you
> booted a Smalltalk image, the machine code *was* smalltalk bytecodes.
> When you booted a COBOL program, the machine code was appropriate for
> COBOL.

That sounds moderately mental. I'd hate to think what happens if you get 
the microcode wrong...

>> Certainly you can see that if the Smalltalk runtime was running on the
>> bare metal, it would have all sorts of interesting consequences. (For
>> example, since *everything* can be changed, you could invent some new
>> bizare concept of files.)
>
> They had what you'd consider a bizarre concept for files. That's the
> point. You didn't have to worry about "destructors" for files, precisely
> because "file" was built into the language, not the OS. So to speak.

Not even built into the language - built into a library. And, 
presumably, by changing that library, you can change how the filesystem 
works...

(Does anybody remember how "Longhorn" was supposed to ship with a 
filesystem that was actually a relational database? *Really* glad they 
scrapped that idea!)

>> if you tried to write an actual "operating system" in Haskell, rather
>> than just an application.
>
> But that's the point. When your application runs on the bare metal,
> there's no distinction between OS and application.

Well, to some extent there /is/. By definition, an application is 
something that solves a real-world problem, and an OS is something that 
provides services to applications. Although in the case of something 
like a Smalltalk or Haskell OS, the "OS" might be statically linked into 
the application image - i.e., the "OS" might just be a runtime library.

> In other words, they're using an OO memory model. Objects are contiguous
> blobs, but it doesn't really matter beyond that where they are in the
> address space. So instead of doing a compacting garbage collection in a
> linear space, they do a compacting garbage collection on a per-page
> basis. *That* is really the innovation.

Sure. If the virtual address space supports it, why not? (Other than 
"because most OS designs assume that you would never want to do such a 
thing".)

>>> Traditional file system interfaces probably do too.
>>
>> Now, do you mean "file systems", or do you mean "interfaces to file
>> systems"?
>
> Interfaces. The reality of file systems nowadays isn't anywhere near
> what the interface looks like. Internally, it's much closer to multic's
> file system, yet it's generally presented with UNIX file system semantics.
>
> (In Multics, the basic way of getting to a file was essentially memmap.
> That's why UNIX files are all represented as an array of bytes, with no
> records, no insert/delete bytes, etc. It's modeling multics' interface
> without the convenience of either having it in memory *or* having the OS
> provide you useful services.)

OK, now I must know... WTF is this "memmap" that I keep hearing about?

>> Well, we'll see what happens.
>
> Yeah, sadly, I don't have a whole lot of hope. Altho the thing with each
> application running in its own Xen hypervisor slot sounds interesting.
> I'll have to look at the implications of that a little more closely.

Remember that Galios mainly does work for people who want high assurance 
software. Stuff with mathematical guarantees of correctness, and so 
forth. For that kind of insanity, being able to guarantee that the OS 
isn't going to do something weird (because there isn't one) is probably 
quite useful. I'm more dubious about how useful it is for everyone else. 
The idea of experimental OS design using Haskell is quite interesting, 
however.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message