KOSH [Kommunity Orientated Software Hardware]

Weekly Summary

Week:  15th February 1999

Number:  006

Mailing List:  kosh-hardware-o

In the mailing list this week, the following items were discussed.
Please do not email the scribe regarding any of these topics, it is 
not his job to answer these questions, but merely to report the topics
of conversation. If you have any queries about this summary, please 
email summaries@kosh.convergence.org, stating the Summary Number, and
Mailing List Name and he will try to answer your queries.

a)

Subject:  CPU Independence (Hardware)

Summary of Debate:  One strategy is to have CPU (and RAM) live on a
                    seperate card which can be swapped to upgrade
                    the CPU.  If the HAL is upgraded at the same
		    time as the CPU upgrade, the rest of the system
		    could remain in place.  Another approach would
		    be to have all code in a SCISC  (Super Complex
		    Instruction Set Computing) form, with a compiler
		    at the hardware level that translates the SCISC
		    instructions into native binary for whatever
		    CPU is present.  Here an upgrade can be done
		    entirely by changing hardware, without changing
		    software.

b)

Subject:  CPU Independence (Software)

Summary of Debate:  GENOS uses a VML (virtual machine language) to
		    provide CPU independent distrobution.  In this
		    scenario the VML code is translated to native
		    code when the software is installed.  Another
		    approach is to use Slim Binaries, which are
		    compiled at run time.  

c)

Subject:  CHRP

Summary of Debate:  Under CHRP, with a CPU on a card solution, there
		    can be a forth interpreter in the bios rom of
		    the CPU card.  Then each additional card in the
		    system has drivers for itself on itself in
		    on board ROM, coded in forth.  (These drivers
		    can be later replaced by the OS after the OS
		    boots.)

d)

Subject:  Heterogeneous Processors in the same machine

Summary of Debate:  Currently there are a variety of CPU on a card
		    options (for example an x86 on a card to be
		    inserted into a mac for x86 emulation)  It would
		    be cool if the OS could take advantage of these
		    extra CPU's and schedule extra tasks to run on
		    them.  (ie when you are not doing emulation, but
		    your main CPU is bogged down)  Implementing this 
		    would be very difficult.  One possiblity would
		    be for the HAL to perform diagnostics on each
		    card that could potentially be used, passing 
		    the results along to the scheduler.  Another
		    would be to have a seperate scheduler for each
		    CPU, and when one becomes idle it offers to
		    help the other.  If Slim Binaries were being
		    used the idle CPU could even compile code
	            before it is needed, to be ready to run that
		    code if the first CPU requests it.  In other
		    situations "nearest neighbor" algorithms would
		    be involved.  

e)

Subject:  Philips trimedia chip

Summary of Debate:  This is a cheap chip, which is designed to do
		    audio/video processing, but could be run
		    standalone in a Kosh console. 

f)

Subject:  8-bit machines

Summary of Debate:  If we could get kosh running on 8-bit machines it
		    would be very cool.  This could allow access to
		    other wise lost data and programs.  Another
		    solution would be to emulate older systems, as
		    emulation seems to be improving (examples in
		    680X0 emulation were cited.)  
		    Current 8-bit embeded systems would be another
		    thing Kosh should consider.  One point to remember
		    is the issue of bankswtiched memory.