On May 2, 5:42 pm, John Larkin
On May 2, 8:18 am, John Larkin
jasen wrote:
linux in less than 256 kilobytes ???
====
was that ever possible?
Sorry, meg of course. Still harking back to the days of OS9 with 64kb
RAM....
My embedded products use a cpu with 2K bytes of on-chip ram. I've
rarely needed more, even on products with user interfaces and eternet.
2K bytes, Luxury! I did a multitasking[1] OS in 256 bytes.
[1] 3 is multiple, isn't it.
That ain't a lot of room to save even three contexts on three stacks.
Which CPU?
It was 8052. The fact that the registers are 8 memory locations and
the PSW selected which 8 made pushes for them not needed. There are 4
banks but we had to have one free.
I did a preemptive RTOS for the 6800 (the 8 bit one) with unlimited
tasks. Each task had its own stack, and the 6800 automatically pushed
all the regs onto the current stack on a hardware interrupt or an SWI.
So task context was mostly saved for free... all you had to do was
stash the stack pointer itself into the task header, and it was all
wrapped up... then run the scheduler to see who was up next.
The first micro I programmed was the 6800, I found it fairly easy to
work with. It had a lot more intructions than a PDP-8 but not so many
that I got lost among them. The little debugger IIRC: "JBUG" worked
quite nicely.
It is really too bad that the "personal computer" had to wait for the
IBM PCB to become a common item. Your OS for example could have
started the world on a much better track.
I agree that it is a very good teaching tool. I also think that
writing a set of 32 bit integer math routines and doing your own
virtual method dispatcher should be required before anyone is allowed
to write something important.
I sometimes use a little math/ascii conversion package I wrote for the
68K. The math format is 32.32, a longword of signed integer plus a
longword of fraction. That's adequate for near any real-world
variables. It's blindingly fast compared to floats (no normalizing!)
and conversion into/out of integers is instantaneous. All the math
functions saturate, so most of the time it's safe to ignore
exceptions, including division by 0.
I have the same sort of thing for 8051. Mine is just pure integer. I
have add and subtract in 4, 8 and variable numbers of bytes. There is
a 4 bytes times 4 bytes gives 8 bytes multiply and a 8 bytes divided
by 4 bytes gives 4,4 result.
I also have a 2^128 divided by 8 bytes routines for a fast 1/x type of
calculation and a 32 bit sqrt().
There is also a 32 bit binary to BCD and a number formatter and the
usual number inputter.
What is a "virtual method dispatcher"?
The C++ folks incorrectly call them "virtual member functions". In a
OO language there are routines that must be selected at run time not
at compile time. The usual way to do this is: All of your object
structures have an extra entry in them. This item is the Virtual
Method Table pointer. Since each type you declare can have a
different set of routines, there needs to be a VMT for each type.
Psudo code wise it looks like this:
; Compiling: Call GreenBall.Draw
MOV POINTER,@GreenBall ; Point to the object
MOV POINTER2,RAM[POINTER+VMTOffset] ; Address its VMT
ADD POINTER2,#(IndexOfDraw*N) ; Offsetinto the VMT
MOV POINTER2,RAM[POINTER2] ; Load the routine
CALL POINTER2 ; .. address and go
In 8051 land the VMT like thing would be in code space and the VMT
address would really just be an index into a table. The only place
I've really used such a thing in 8051 was to help in doing a mini web
server. For an experimental project.
