RE: concurrency research "hot" again?

[tjoccam@xxxxxxxxxxx]

Hi Eric and all,

You guys all missed the obvious one, which was the one I meant when I
mentioned an OS in a few kilobytes. This is DOS, and not bloated DOS - I
mean DOS 3 to DOS 5.

I got multitasking and multiprocessing to work over DOS years ago
(1993-1996), and demonstrated a multitasking prompt, a shared printer,
etc, without the OS even knowing I did multitasking. This is easy to do
using nested program segment prefixes (which DOS shares with CPM). Eric,
you are on the right track by mentioning occam as an OS, but it needs a
little more, like a command prompt (a single "wild" process which takes up
"the rest of the resources" - all the rest of the world is "tame
processes" which have fixed resources as in occam - the old Transputer
toolset used this approach without admitting it, because of course
everything was loaded from the "wild" side, the host).

DOS is a completely capable operating system, once you get around the
apparent singletasking restriction - it's far more capable than modern OSs
because you can access the hardware directly. Its only drawback (other
than vulnerability to stupid programs) is small size limitations like the
1MB limit. This is hardly an essential point - anyone could write a "big
DOS" that is 32 or 64 bit but is DOS in every other respect - and it would
still only be a few kilobytes in size.

Larry Dickson

>
> OS in kilobytes? No, I am not kidding.
>
> Some examples:
>
> - Occam. You might not consider it as an OS, but it has the essential
> runtime functions and the people from Kent might give you more concrete
> figures. I picked up that the Transterpreter code (and that more a VM)
> fits
> in about 10 KB.
>
> - QNX. I still have a floppy somewhere that boots and brings up a GUI with
> browser that connects to the internet. In case, such a floppy has not more
> than 1.44 Mbytes. QNX is also a COTS OS that has a message passing based
> architecture. Not as pure as CSP but a lot cleaner than these monolithic
> monsters like Linux and Windows. For VISTA one now needs 1.5 Gbytes of
> RAM,
> enough to turn you off forever from Windows. QNX has been bought by Decker
> and if you happen to have a GPS/multimedia of that brand in your car, it
> is
> likely to run QNX.
>
> - Our own OpenComRTOS is using a CSP-like model and can be made to fit in
> 1
> Kbyte (single processor) and 2 Kbytes (multiprocessor with full topology
> transparency). This is the L0 layer and with static linking like in occam.
> The L1 layer has more RTOS tradional services and is still being
> completed,
> but it will fit as well in a few Kbytes. The reason for this small size is
> that we used formal modeling. The previous RTOS we developed was called
> Virtuoso (and was the first preemptive RTOS on the transputer in 1991) was
> about 10 times bigger but still around nt more than 50 Kbytes.
>
> I am not a professor, although I do some research. The OSes above are used
> in industry. OpenComRTOS is put on smart sensors with an internal 16bit
> micro, 32 Kbytes of flash and 2 KB of RAM (for data). It also runs on top
> of
> Windows and ports are underway to e.g. the Cell processor, FPGA
> (microblaze)
> and others.
>
> I am more astonished that most "professors" in computer science (not all,
> mind you) keep on teaching about these monolithic socalled OO models
> requiring MegaBytes. CSP is unfortunately more or less forgotten. The good
> news is that thanks to the upcming multicores, it is being rediscovered
> out
> of necessity. But I find it shocking to see how much elementary knowledge
> of
> the transputer days seems to have been lost. Old geeks like this group is
> keeping it alive, ...
>
>
> ----------------------  FROM : --------------------------
>    Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx
>    Skype me at: ericverhulstskype
>    Mob. +32 477 608339
>    Systematic Systems Development Methodologies
>    Trustworthy Embedded Components
>    http://www.OpenLicenseSociety.org
> -----------------------------------------------------------
> " "Concept" is a vague concept", L. Wittgenstein
>
>
> -----Original Message-----
> From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
> Behalf Of Andrzej Lewandowski
> Sent: Thursday, February 15, 2007 2:25 AM
> To: tjoccam@xxxxxxxxxxx; 'Andrew Delin'
> Cc: 'Allan McInnes'; 'occam list'
> Subject: RE: concurrency research "hot" again?
>
> "If OS size is in  kilobytes.. " You are kidding, aren't you?... Or,
> maybe....  you are a PROFESSOR? This would explain everything...
>
> A.L.
>
>> -----Original Message-----
>> From: owner-occam-com@xxxxxxxxxx
>> [mailto:owner-occam-com@xxxxxxxxxx] On Behalf Of tjoccam@xxxxxxxxxxx
>> Sent: Wednesday, February 14, 2007 1:55 PM
>> To: Andrew Delin
>> Cc: Allan McInnes; occam list
>> Subject: RE: concurrency research "hot" again?
>>
>>
>>
>> Maybe I'm sawing the same old violin, but...
>>
>> I think the key to breaking out of the "incredibly difficult to
>> program in parallel" conundrum is to dump the baggage of the last
>> couple of decades and go back, not only to CSP, but also to elegant
>> (small) OS constructs. If OS size is in kilobytes, there's hope you
>> can understand COMPLETELY what it is doing, especially if the OS
>> restricts itself to resource loading and leaves run-time concurrency
>> to applications.
>>
>> The other thing is to accept a 5 or 10 percent performance hit in
>> order to keep clear, provable, traceable resource usage (i.e.
>> eliminate spaghetti). The "hit" is actually not a hit, because the
>> cost of code tangles is really much more; but if raw specs are
>> applied, you can always do it just a little faster by letting pointers
>> and dynamic constructs go wild.
>>
>> Larry Dickson
>>
>> > Last week I attended a presentation by BillG where he also
>> raised the
>> > topic of insufficient semantic richness in today's
>> programming models
>> > - saying new developments are needed in programming
>> languages to use
>> > the parallelism of multi-core CPU designs. In the same
>> conference, the
>> > head of MS Research also talked about these challenges.
>> >
>> > About 6 months ago I sat through a presentation about options for
>> > parallelism in .NET today, and it wasn't pretty - way too
>> much locking
>> > litter and thread invocation for my liking. Having to
>> understand the
>> > behaviour of the compiler so that your process control statements
>> > don't get optimised away, isn't goodness.
>> >
>> > There is a proposed MS approach which seems to be a form of 'CPU
>> > transaction', where entire blocks of statements effectively compete
>> > for resources and the OS or hardware detects a livelock or
>> deadlock or
>> > other problematic condition. At this point, blocks of process state
>> > are reversed by hardware. I need to find out more about this. These
>> > techniques will probably need to exist if you want to build
>> a robust
>> > OS on top of multicore, where applications with different "parallel
>> > heritage" must run together. Nonetheless, the best approach for app
>> > construction is to start along CSP lines, not to rely on
>> the system to
>> > reverse out of trouble...
>> >
>> >
>> > -----Original Message-----
>> > From: owner-occam-com@xxxxxxxxxx
>> [mailto:owner-occam-com@xxxxxxxxxx]
>> > On Behalf Of Allan McInnes
>> > Sent: Wednesday, 14 February 2007 1:25 PM
>> > To: occam list
>> > Subject: concurrency research "hot" again?
>> >
>> > It seems that concurrency is again getting "mainstream" attention.
>> > I've seen several articles in the popular press over the
>> last few days
>> > touting Intel's
>> > new 80-core "teraflop-on-a-chip" demonstration chip. Most
>> of the articles
>> > I've
>> > seen have made a big deal out of how difficult programmers
>> will find it to
>> > program for 80 cores, and how lots of research needs to be
>> done to develop
>> > new
>> > techniques for programming parallel architectures (here's
>> one sample of
>> > the
>> > articles I've seen:
>> >
>> http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?a
>> rticleId=197005746).
>> >
>> > At the same time, I've seen several links to "The Landscape of
>> > Parallel Computing Research: A View from Berkeley"
>> >
>> (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html)
>> > show up on various websites that I check regularly. In that report,
>> > the folks from Berkeley say, among other things:
>> >
>> > "Since real world applications are naturally parallel and
>> hardware is
>> > naturally parallel, what we need is a programming model, system
>> > software, and a supporting architecture that are naturally
>> parallel.
>> > Researchers have the rare
>> > opportunity to re-invent these cornerstones of computing,
>> provided they
>> > simplify the efficient programming of highly parallel systems."
>> >
>> > So is research into concurrent programming becoming a hot
>> topic again?
>> > And how many of these research efforts are simply going to reinvent
>> > the occam wheel?
>> > The Berkeley effort, in particular, sounds a lot like the
>> occam/transputer
>> > approach (at least at a high level). However, the tech
>> report in question
>> > makes
>> > no mention of CSP, occam, or transputers (OTOH, they also
>> omit any mention
>> > of
>> > Berkeley's Prof. Ed Lee, who has done a lot of work on concurrent
>> > programming models via the Ptolemy project).
>> >
>> > It'll be interesting to see where this goes. Hopefully
>> it'll lead to
>> > an upswing in funding for projects that can claim to be working
>> > towards support for massive  concurrency - like KRoC/nocc :-)
>> >
>> > Allan
>> > --
>> > Allan McInnes <amcinnes@xxxxxxxxxx>
>> > PhD Candidate
>> > Dept. of Electrical and Computer Engineering Utah State University
>> >
>> >
>> >
>>
>>
>>
>>
>
>
>
>