From: Jim Witte (jswitte_at_bloomington.in.us)
Date: Sun Oct 03 2004 - 22:26:09 PDT
> On 3-okt-04, at 23:01, Jim Witte wrote:
>> Except the OS doesn't matter - it's going to be replaced anyway.
> Er, yes, you're right ;-)
Well, mostly :) The platform has to be open enough that some
suitable POSIX host-OS has been ported to it. I also wonder about the
possibility of "pushing up" a lot of the functionality of the NOS, like
Network drivers, USB and Firewire, maybe even the lowest levels of
PCMCIA access, graphics card drivers, sound drivers, maybe even sound
codecs, up to the level of the host-OS. This would have a speed
penalty for the emulator, since the NOS could not then be the only
process running. But it would make porting new network drivers,
graphics card drivers, etc much easier, as "we" (whoever that would be)
could leverage existing open-source drivers, instead of having to
transfer everything down to the p-class layer within the emulator - and
develop a way to, say, interface the emulator with a GPU and do
vertex-programming or accelerated 2D stuff.
Another downside is that software written specifically to use some
"external" driver (maybe a special sound codec, or accessing a GPU with
special calls "out" of the emulator [similar to a software interrupt I
guess]) couldn't be run on Apple hardware, and would be hardware
specific, unless the "host-OS" drivers were themselves abstracted like
the p-classes in NOS. But that adds yet another level of indirection
to the hardware, which might or might not fall away when compiled
(function A calls function B calls function C gets compiled to a direct
call from A to C).
>> And remember, NOS is designed to be memory-resident, so it shouldn't
>> need to access the disk often (if ever).
> Hm, we'll see, but will this feature of NOS work if it's ran under
> emulation?
Certainly. I don't think parts of the Newt would *work* if the latency
were much more than it is for memory-chip access or card-memory-access.
Paul could answer this better - ATA support doesn't work with some
cards, and it might be because they are just too slow for the NOS to
work with - it wants data quicker than the card can provide it. Of
course, in due time, the entire object heap and garbage collection may
be rewritten - it might have to be, if the memory space expands much
beyond current limits. Didn't Paul say he got 8MB into Einstein? I
don't know if he was *using* all of that in the demo, but the more
memory you have, the more garbage can accumulate before the OS runs out
of space, and needs to GC. Currently, as we all know, when the Newton
GC's, it stops the whole system. If there are hundreds, or even
*thousands* of objects to be GC'd, this would not be good.
The most modern GC system I know of (which isn't much, I need to read
"Garbage Collection" by Jones and Lins..) is "incremental, generational
GC" Incremental means that GC is called very often, and clean up only
a small amount of garbage at a time. Generational means that the
newest garbage is cleaned up first, on the assumption the stuff that's
been around and accessed longest (like references created by the OS in
the bootup sequence and by the Extras drawer and stuff) aren't going to
go away, while newer stuff is going to change a lot. It "searches"
through the list of objects looking for garbage from newest to oldest
then (I think..)
> I still like the look of the OQO...
I do too. Another device I liked was the "HipTop" machine a while
back..
Or, a totally new machine made around the eMate shape :) (using the
guts of some existing PDA in a new shell)
Jim
-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Mon Oct 04 2004 - 00:30:01 PDT