[Tfug] OS written in Assembly

[Bexley Hall]

Hi Judd,

> I think you guys might be dismissing this a bit early.
> In the world of PCs it is probably worthless. However in the
> growing world of Net computers, smart devices, and their ilk
> this is actually a very valuable solution. 

There are *lots* of alternatives to chose from.  I think
the cost (time/re$ource$) to maintain something like this
will put it *low* on that list.

Consider, if you are doing something like you propose (below)
it would probably be in significant quantities.  The cost
differential in large quantities for this approach vs. something
written a bit cleaner (less efficient) would be negligible.

Plus, having written it in ASM, it is *tied* to the x86.
Many "non desktop" solutions use ARMs, etc.  You don't really
think someone would try to *port* an ASM-written system to
a different processor family when they could start from
scratch (or, port a system in a HLL to that other hardware
platform "overnight"?)

> This style OS would fit will with a sensor system
> fitted to a garage parking slots. You could plug in at any
> point, or access them via HTTP to see the status of the
> parking in that section, hit the floors master system, and
> find out all the parking spots data. All from an OS that
> would run near flawless for years without requiring reboots

What makes you think it would run "flawlessly"?  Just
because it is written in ASM doesn't mean it is any more
ROBUST than something written in a HLL.  A crappy ASM
programmer (or *designer*) will write crappy code.

[Note that I am not making that assertion about this product;
just a general observation]

> etc. And could be put on micro device architectures with
> supplemental flash card inserts so you could literally pull
> backup of the data live. The output is almost sufficient
> enough for a large LCD display to the drivers pulling in to
> know where they can park.
> 
> It's more deterministic OS structure means that it
> would actually be a much better choice for communicating
> with PLCs. 

I don't see how you can make that assumption from the data available
on the website.  E.g., I see a laundry list of "features" but
nothing to really back up those claims.

E.g., how does he extend real-time guarantees to the TCP/IP stack?
Are real-time mutexes used consistently (or, do major subsystems
ignore timeliness in favor of a more traditional implementation)?
What scheduling algorithm does he use (or, does he think running
the jiffy at 1KHz -- instead of, say, 100Hz -- make it "real-time")?
What provisions exist for determining and handling missed deadlines?
Does the code perform run-time sanity checks (e.g., are ASSERTs
enabled) and REACT INTELLIGENTLY to anomalies (or, does it just
panic()?)

I.e., Until you have a better feel for what's under the hood,
you can't really decide what you are buying (into).

E.g., folks have touted running web servers on small PICs (!).
But, when you look closely, its not what anyone would consider
a *real* server!

> Anyways, just my .02.

You might want to look at QNX.  Years ago they had a demo
that fit on a floppy (that really *does* have real-time
support, etc.)

Inferno tries to address many of these issues, as well, with
a small footprint and "platform independant" VM (inferno
applications are typically tens of KB instead of tens of MB)

<shrug>  FWIW...

--don