Re: you can't bash Microsoft enough



On May 3, 8:24 am, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 3 May 2007 06:25:48 -0700, MooseFET <kensm...@xxxxxxxxx> wrote:



On May 2, 10:24 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2 May 2007 19:35:35 -0700, MooseFET <kensm...@xxxxxxxxx> wrote:

On May 2, 5:42 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 2 May 2007 15:11:11 -0700, MooseFET <kensm...@xxxxxxxxx> wrote:

On May 2, 8:18 am, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 02 May 2007 09:31:56 +0100, Paul Burke <p...@xxxxxxxxxx>
wrote:

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.

Everybody should write one of these things once. But lately, I find
that a couple of simple state machines is all most embedded systems
really need.

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.




.



Relevant Pages

  • HC08 and RAM bootloader routine
    ... self-contained S19 file for a RAM-based message loop. ... contains FLASH programming routines and acts upon subsequent messages ... -nothing else uses this block of RAM and my stack is located at the ...
    (comp.arch.embedded)
  • Re: Help! Bug that I can not figure out
    ... depend on exactly how the C routines are declared. ... and the callee doesn't. ... Fortran however doesn't do optional arguments like ... Hence Fortran routines pop the stack just before ...
    (comp.lang.fortran)
  • Re: Calling a "procedure of object" routine w/variable parameters
    ... > Which calling convention are you using for your routines? ... > due to the way cdecl functions put parameters on the stack. ... Basically a Delphi routine is called from C, ...
    (borland.public.delphi.language.basm)
  • Re: Will undefined varialbes test as False?
    ... pointers on the stack and be able to walk through them to the stack base ... Public Sub r2 ... >>whether a function is being called from the Immediate Window or not. ... These same routines, if called manually ...
    (microsoft.public.vb.general.discussion)
  • Re: Suggested Alternative Unicode Implementation (for Rudy+ miscothers)
    ... Dunno. ... AFAIK, routines like Round and Trunc only do Extended, these ... I wasn't aware that the Delphi Math unit was universally ...
    (borland.public.delphi.non-technical)