Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> That was one of the premises they started with: what if nothing in the 
>> OS was written in a language like C? :-)
> 
>   They will still need dynamically loadable libraries for the system to
> be rational.

It's possible. I suppose it also depends on (a) how much memory they 
think they'll have in machines by the time it's actually a production 
OS, and (b) what markets they're targetting.

Certainly for general desktop or server systems, you might have dozens 
of non-trivial applications running at once. In contrast, I think the 
first target environment for Singularity is something akin to TiVo, or 
Media Center, where you really don't have someone with dozens of windows 
open at once.

But sure, I can see the system evolving to put something like the 
native-code regexp library in a dedicated page of address space, loading 
it on demand, and sharing it with all the different programs that use 
that library. Or, you could just have a "regexp server" where you send 
the strings you want parsed and it returns you the results. This 
wouldn't have a whole lot more overhead than simply calling it directly, 
since you're sharing address space with the regexp server itself. It's 
not like it would have the IPC overhead it would in Windows or Linux or 
something.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> Oh, and btw, download that there Singularity OS. Note the almost 
> complete lack of anything remotely approaching C in the source. The use 
> of C in Singularity is approximately like the use of assembler in 
> C-based operating systems - the stuff that's impossible to do in the 
> higher-level languages, like turning interrupts into appropriate stack 
> frames and saving off registers during context switches.

Or, alternatively, House, which is a mixture of Haskell and assembly. 
(It contains 0% C.)

Of course, there's no software to run on it (unless it's written in 
Haskell - oh wait, I already said "no software", I'm repeating myself), 
and it's a highly experimental research prototype, not a production OS. 
And honestly, I doubt it'll ever be a production OS either...

Lots of very cool stuff like using the type system to ensure that 
hardware registers are accessed in the correct way, etc., but who's 
gonna use it?

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

Post a reply to this message

Orchid XP v8 wrote:
> Lots of very cool stuff like using the type system to ensure that 
> hardware registers are accessed in the correct way, etc., but who's 
> gonna use it?

Yeah, singularity does this with its device drivers too. Pretty cool, 
ensuring at compile time that your kernel-mode device driver doesn't 
step on anything else. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> Lots of very cool stuff like using the type system to ensure that 
>> hardware registers are accessed in the correct way, etc., but who's 
>> gonna use it?
> 
> Yeah, singularity does this with its device drivers too. Pretty cool, 
> ensuring at compile time that your kernel-mode device driver doesn't 
> step on anything else. :-)

Heh - do you remember back when a "data type" was just a thing to tell 
the compiler how many bits to allocate any whether to include the sign 
bit during comparisons? ;-)

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

Post a reply to this message

Warp wrote:

>   With all the talk about fancy new languages which are so super-efficient
> and so super-fast and so super-secure and whatever, I not seen too much
> discussion about one thing: What about dynamically loadable libraries?

GHC [currently the best Haskell compiler] used to be able to compile 
DLLs. At some point that code path bitrotted and stopped working; I'm 
not sure what the current status is.

According to the old documentation, it used to be a case of throwing a 
commond line switch, and your compiled program would call DLL versions 
of the Haskell libraries rather than being statically linked to them. 
You don't change any Haskell code, it's just a compiler switch.

Needless to say, if you have a few dozen Haskell programs, not having a 
dozen copies of the Prelude is something of a win. (!)

I'll see if I can figure out what the current status of this feature 
is... I'm curios myself.

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Each process does have its own garbage collector, but that's good 
> because each process can use a different garbage collector, depending on 
> the types of garbage it collects.

  But doesn't that make each program selfish? In other words, it only takes
care of itself not running out of memory but completely disregards any other
program running in the system at the same time?

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Certainly for general desktop or server systems, you might have dozens 
> of non-trivial applications running at once. In contrast, I think the 
> first target environment for Singularity is something akin to TiVo, or 
> Media Center, where you really don't have someone with dozens of windows 
> open at once.

  In a typical modern OS there may be hundreds of processes running even
if the system has just booted up and the user has not started any program
of his own. There are all kinds of drivers, services, task managers,
window managers, firewalls... you name it. Every single one of them uses
the same system libraries (eg. typically libc plus a few others in linux).

  Just because the user has not started any program doesn't mean there
isn't a big bunch of programs running.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> GHC [currently the best Haskell compiler] used to be able to compile 
> DLLs. At some point that code path bitrotted and stopped working; I'm 
> not sure what the current status is.

  I faintly remember asking about this subject in the other group once.
I think it was about how Haskell manages (or if it manages at all) to
create precompiled (possibly dynamically-loadable) libraries which
nevertheless work with any user-defined type and user-defined functions.

  In object-oriented programming this is typically achieved with dynamic
binding (ie. virtual functions): The precompiled library doesn't need
to know the user-defined type as long as it has been inherited from a
base class defined in the library. The virtual table attached to objects
of that class allows the precompiled library to call the proper user-defined
function. (In a way you could say that the user code is telling the library
which function to call for each of the virtual functions in the base class.)

  However, how does haskell manage to do this? Suppose you have something
like this precompiled into a dynamically loadable library:

foldl1 (+) someList

  Also assume the user has defined his own element type for the list and
the (+) function for that element type, and then calls the dynamically
loaded library by giving it a list with elements of that type. How does
the library know which (+) function to call? How does it know that a (+)
function exists for that element type in the first place?

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:48d92c0d@news.povray.org...
> Darren New <dne### [at] sanrrcom> wrote:
>> http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html
>
>  With all the talk about fancy new languages which are so 
> super-efficient
> and so super-fast and so super-secure and whatever, I not seen 
> too much
> discussion about one thing: What about dynamically loadable 
> libraries?

dlls make portable software hard.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Each process does have its own garbage collector, but that's good 
>> because each process can use a different garbage collector, depending on 
>> the types of garbage it collects.
> 
>   But doesn't that make each program selfish? In other words, it only takes
> care of itself not running out of memory but completely disregards any other
> program running in the system at the same time?

Yes? And how is that different from, say, Windows or Linux? Maybe I'm 
not understanding your point.

I don't think I've ever written a program for Windows or Linux and 
worried about how much memory other processes in the system might be 
using at the moment. I think I did exactly one program like that on the 
Amiga. Not that I intentionally used more memory than I needed, mind.

What I was describing in that quote is this: The real-time programs use 
a real-time GC, the interactive programs use an interactive GC. It 
really doesn't have too much to do with how *much* memory they use.

Obviously if you have your memory management hardware turned off, you're 
going to have a hard time doing demand paging of stuff off the disk, but 
systems worked with that restriction for years and years. And they have 
mechanisms in place to let you turn that on for particular programs that 
want it, IIRC.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message