Dan wrote:
> My exokernel isn't even a kernel, it's just a gatekeeper.  I was trying to think of a good name for it:
> 
> Maat, Aker, St. Peter, Gatekeeper, Guardian, BlackSphere, or Garmies were the first that came to mind.

I think you forgot Zuul. :)

Dan Wrote:

> Lionello Lunesu Wrote:
> > Isn't this what's happening already?
> 
> Not arbitrarily sized ones.  If you have a buffer like so:
> 
> [slice0,slice1,slice2] = virtual address table [minemineminemine][7Mb][minemineminemine][24b][minemine] = data buffer
> 
> Iterate through your virtual array, and you're going to get a hit on the virtual address table, then on slice0, then on slice1 which will also load the 24b segment and probably slice2 for you.

On another note, this is done by the x86 system already for memory pages (4kb fixed block size).  If you need a 32kb array, you can take 8 pages from anywhere in memory and call it yours, and iterate through the array and it'll translate the address for you in the hardware via the "virtual memory" process.

: )

torhu wrote:
> Dan wrote:
>> My exokernel isn't even a kernel, it's just a gatekeeper.  I was trying to think of a good name for it:
>>
>> Maat, Aker, St. Peter, Gatekeeper, Guardian, BlackSphere, or Garmies were the first that came to mind.
> 
> I think you forgot Zuul. :)

There is no kernel, only Zuul.

And if you remap StdOut to StdIn and vice-versa, you get total protonic reversal.  That's bad.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> And if you remap StdOut to StdIn and vice-versa, you get total protonic reversal.  That's bad.

Right. That's bad. Okay. All right. Important safety tip. Thanks, Egon.

"Dan" <murpsoft@hotmail.com> wrote in message news:f0di8h$q2e$1@digitalmars.com...
> Dan Wrote:
>
>> Lionello Lunesu Wrote:
>> > Isn't this what's happening already?
>>
>> Not arbitrarily sized ones.  If you have a buffer like so:
>>
>> [slice0,slice1,slice2] = virtual address table [minemineminemine][7Mb][minemineminemine][24b][minemine] = data buffer
>>
>> Iterate through your virtual array, and you're going to get a hit on the virtual address table, then on slice0, then on slice1 which will also load the 24b segment and probably slice2 for you.
>
> On another note, this is done by the x86 system already for memory pages (4kb fixed block size).  If you need a 32kb array, you can take 8 pages from anywhere in memory and call it yours, and iterate through the array and it'll translate the address for you in the hardware via the "virtual memory" process.
>

Well, that was *exactly* what I was getting at! OK, granted, it's only done in 4KB increments, but that's when a regular array resize (copying the contents over to a new place) would actually start harming performance.

L.

Lionello Lunesu wrote:
> Well, that was *exactly* what I was getting at! OK, granted, it's only done in 4KB increments, but that's when a regular array resize (copying the contents over to a new place) would actually start harming performance.

That sounds enticing!
If you could put garbage collection into the kernel - even with tile-sized
granularity - that would make many things easier. And finally put the idle
thread to good use... :-)))


Regards, Frank

Alexander Panek wrote:
> Walter Bright wrote:
> 
>> Alexander Panek wrote:
>>
>>> I'm sure going to spend some time getting a proper codebase for further
>>> development done, and write some documentation about how to actually
>>> get to the point of being able to write an operating system with D. I
>>> think that's a major weak point of D, as it claims to be a systems
>>> language, but there's no actual system written in it from scratch,
>>> neither documentation on how to achieve that.
>>
>>
>> Andrei suggested that the source code for Minix, which is fairly small, could be transliterated from C almost directly into D. This would neatly resolve the issue, and provide a starting point for anyone wanting to take it further.
> 
> 
> True. On the other hand, a kernel written purely in D is something that really would (and will, arr) be cool! I just find it less exciting to code "C with D", so to speak.
> 
> I'll make sure to announce the project, once a few milestones are finished, on the newsgroups.

Linus T. started the same way. He had a Minix running on his machine, and piece by piece replaced stuff there, until no original code was left. (And then he /really/ started writing Linux.)

We should do the same thing. Figuratively speaking. So, do the thing in Cish D, and only when it gets bootable, start rewriting it in Real D (tm).

Brad Roberts wrote:
> Alexander Panek wrote:
> 
>> Walter Bright wrote:
>>
>>> Alexander Panek wrote:
>>>
>>>> I'm sure going to spend some time getting a proper codebase for further
>>>> development done, and write some documentation about how to actually
>>>> get to the point of being able to write an operating system with D. I
>>>> think that's a major weak point of D, as it claims to be a systems
>>>> language, but there's no actual system written in it from scratch,
>>>> neither documentation on how to achieve that.
>>>
>>>
>>> Andrei suggested that the source code for Minix, which is fairly small, could be transliterated from C almost directly into D. This would neatly resolve the issue, and provide a starting point for anyone wanting to take it further.
>>
>>
>> True. On the other hand, a kernel written purely in D is something that really would (and will, arr) be cool! I just find it less exciting to code "C with D", so to speak.
>>
>> I'll make sure to announce the project, once a few milestones are finished, on the newsgroups.
> 
> 
> Pardon the curmudgeon in me, but aside from being educational and being able to say 'see, someone's done it', what is to be achieved from inventing yet another kernel? 

The advertising value is simply enormous.

A lot of car makers (the smaller, the likelier) have always had some top models that give the brand prestige. Those cars were sold in very small numbers, and they made losses with them. But that was on purpose, because the prestige value sold much more "regular cars". I've seen it with motorcycles, cameras, watches, liquor, perfumes, and in service marketing!

In the 80's many companies had doubts about Turbo Pascal. But when Borland demonstrated that it was not only possible but downright straightforward to write a TSR with it, the acceptance was huge. It became a Serious Programming Language.

Oh, and speaking of cameras, somebody buying a camera wants it to have all the bells and whistles, even when they never end up using them. But they /have to be there/.

>  Anything beyond a toy kernel is an _enormous_ effort.

We don't have to beat Linux. All we need is to have a valid counterargument when the [yourLanguageHere]weenies start saying D is not for systems work.

Besides, the tinier the merrier. A small (e.g. Minix like) actually running OS (even if totally toy) is a good vehicle for trying out all sorts of things, without having to buy Annotated Linux Kernel Source Code ($200) or even worse, having to read it through only to test your little kernel heap algorithm.



---



For the less-than-midle-aged of us: a TSR (Terminate and Say Resident) was a killer technology of the time. Microcomputers (as "PCs" were called, emphasizing their laughable lack of memory and horsepower -- as opposed to Minicomputers, Computers and Mainframes) were single-user single-tasking, which effectively meant that you can't start a calculator while you're in the text editor, or make notes or look at your calendar while in e-mail (yes, we had e-mail at the time, in Europe too, before the WWW, or even before the Internet, or Usenet became available).

A TSR let you switch between two tasks, usually with some special key combination (like pressing both shifts or Ctrl-shift), and that was implemened with a wedge into the keyboard interrupt routine. Yes, you could have several TSRs running and switch between all of them -- if you were savvy. There was even a "multitasking" app, called Software Carousel, which let you run arbitrary programs while the others were suspended. But that came much later.

But the notion of TSR was common with the CP/M operating system (that the world used until PC-DOS (and later MS-DOS) usurped them) way before Bill got into the OS-game.

Georg Wrede wrote:
> Brad Roberts wrote:
> 
>>  Anything beyond a toy kernel is an _enormous_ effort.
> 
> 
> We don't have to beat Linux. All we need is to have a valid counterargument when the [yourLanguageHere]weenies start saying D is not for systems work.
> 
> Besides, the tinier the merrier. A small (e.g. Minix like) actually running OS (even if totally toy) is a good vehicle for trying out all sorts of things, without having to buy Annotated Linux Kernel Source Code ($200) or even worse, having to read it through only to test your little kernel heap algorithm.
> 
> 

Besides, there is all sorts of fun to be had in the "really really small OS" department. I've been toying with the idea of how to architect a micro-kernel with only about 5 systems calls (remap memory, create process, kill process, switch to process, jump to on interrupt, fixed size IPC). If I wasn't already +3x booked for time, I would be figuring out how to wright it, in D.