memory, video, and a few thoughts

[Michael David WINIKOFF]

> I will again say: You can't allocate memory (address space)

OK, then we are allocating address space -- this would seem to imply that
the problem is then one for the compiler rather then the kernel.

> because it already exists!  It is just invalid.  Memory
> allocation is the process of changing invalid memory into valid
> memory.  All that should be returned is the error code.
> Additionally, address zero (and the nearby low addresses) should
> be reserved as invalid addresses, so chasing NULL causes an

Good idea

> immeadiate error.  (One of VMS's best desicisions, pity we can't
> also make hex 00 an invalid instruction...)
> 
> the size must (should) be exact.  Perhaps:
>         u16             at least 16 bits, unsigned integer
>         s32             at least 32 bits, signed integer
>         f32             at least 32 bits, floating point
>         u8e             exactly 8 bits, unsigned integer
> About the only thing that should require an exact size is
> something networked.

I think were confusing language and OS issues -- the OS has no real reason to
provide anything other then, say, 32 bits -- the language can subdivide this
any way it likes.


>         u18             at least 18 bits, unsigned integer
> We should support EVERY non-exact size up to the maximum
> supportable by the achitecture.  This particular type is useful
> to represent the time of day.
> 
> ---------------
> Both these complaints can be answered in the same way.  The
> feature (character set remapping and virtual memory) does not get
> invoked (save for one-time uses) until needed.

What ANDREAS was saying was that we SHOULDN'T implement extended character sets
that way -- rather we should have a 16 bit character set from the very start.

This is makes it smoother to use for non english (or extended english) character
sets.

> 
> While I am on the subject, I will say again that if Moose is a GUI
> only system I will disassociate myself from Moose.  I admit that
> Moose needs GUI support, but it needs text support as well.  I am
> not going to give up on Moose and text-based capabilities until
> forced.

I think we should plan to provide text capabilities -- invariably they'll be 
finished b4 the gooey.
We'll probably have a text UI for debugging purposes anyway --  I think 
programmers (especially those intending to modify the kernal/write devices
etc. would appreciate having the text UI 

--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.