From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5bcf30769d6d9599
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-08-29 10:43:07 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!chcgil2-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: ADA os talk
Date: 29 Aug 2001 12:43:04 -0500
Organization: LJK Software
Message-ID: <uISLa01h$X1r@eisner.encompasserve.org>
References: <mailman.998888394.11895.comp.lang.ada@ada.eu.org>
 <20010829113230.0ae3febd.tonygair@blueyonder.co.uk>
 <9miteo$t7r$1@nh.pace.co.uk> <bco+FIJl84O8@eisner.encompasserve.org>
 <9mj1l3$1mn$1@nh.pace.co.uk>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 999106986 9362 192.135.80.34 (29 Aug 2001
 17:43:06 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Wed, 29 Aug 2001 17:43:06 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:12568
Date: 2001-08-29T12:43:04-05:00
List-Id: <comp.lang.ada>

In article <9mj1l3$1mn$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> Allright - if you say so. :-)
> 
> Quite honestly, you are now outside my circle of experience & buzzwords.
> NUMA is a dangling pointer. So I guess I'll just agree and look smart by
> association. :-)

Sorry.  NUMA stands for Non Uniform Memory Access, where a given address
in memory may be "closer" to one CPU than to another.  This means obvious
(these days) synchronization mechanisms like spinlocks don't work the same
as they do in UMA circumstances.  If you buy a 4 processor system it is
likely to be UMA.  If you buy a 64 processor system it is likely to be
NUMA.

> IMHO, a basic Ada kernel is most likely to end up running on a single
> processor, but why build in that limitation? IIRC, early versions of WinNT
> Workstation would support up to 4 processors - don't know what it does now.
> Why not 65536 processors? You'd not likely get there - discovering that the
> overhead bogs things down at some point, but why build in that limitation?

That is my point.  One can avoid building in the limitation only by
specifically considering the difference between the way large numbers
of CPUs are connected vs. the way small numbers of CPUs are connected.

> Maybe the best strategy would be to identify someone's OS college text as
> the starting point. If they describe some set of OS's in sufficient detail,
> it would be a matter of saying "We need to implement chapters 3, 7 and 12 of
> this text." The basic requirements would thus be done and a good part of the
> design work is right there.

I am not sure the textbooks are there yet.