Re: Build your own Forth for Microchip PIC (Episode 837)

In article <1182720423.354477.155050@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Bruce McFarling <agila61@xxxxxxxxxxxx> wrote:
On Jun 24, 11:12 am, byron@upstairs.(none) (Byron Jeff) wrote:
I see that I missed explaining something. Code isn't going into RAM. The
code is burned into the flash of the PIC. There's 4-8K of flash on a
typical 16F part now. And the only parts I'll even consider are ones
that can programmatically program their own flash.

Remember that a typical code definition will be two to seven words
long ... sometimes longer, but even then if there is a length
constraint, you can factor it down to a set of shorter words. So if
stored in Flash will be 14bit words, so that stored in Ram will be
2bytes (with the top two bits free), a 64 byte "loading dock", or
"BAY" in RAM to hold the data to be flashed is certainly workable.

That's just about exactly the right size. Most of the more modern of the
16F PICs require writing to flash in 8 word chunks and erasing in 32
word rows. To truthfully a 16-20 byte dock would be more workable.


And you got the RAM for that, given a 32 cell data stack and a 16 cell
return stack, plus the hardware stack as an auxillary stack for
primitives if its quicker to use than a software stack.

I'm going to take a first crack at a STC with some inlining. So the
hardware stack will actually be the word return stack.

So the umbilical kernel could be:
EXECUTE: execution token

Good.

ACCUMULATE: data (length counter of BAY incremented by one)

This too. While it could be factored into send individual bytes, sending
a 16 byte packet along with 2 byte address is a better model. I wouldn't
bother with a length byte, the packet has to be exactly 16 bytes because
that's the smallest chunk that can be written to flash anyway.

STORE: length ... error return if length does not match length counter
in BAY, reset length to 0.

Now that's interesting. I think that ACCUMULATE and STORE can be
combined. The only problem I see is that since erasure requires a 32
word row, there's have to be a way to copy a entire row to RAM, update
it in ram, erase the row in flash, then rewrite the updated row to
flash.

The cheap and simple to get started is to initally write words only in a
32 word alignment, erasing the entire row before writing. It'll cause
too much internal fragmentation in practice, but would be fine for a
proof of concept.

RETRIEVE: length ... report contents of BAY to master, length at the
beginning ... error return if comment length is longer than length
counter in BAY.

Maybe RETRIEVE can alleviate the problem above. The host can simply read
the entire row from the executive, update it as needed, ask the target
to erase the row, then fire back the row as 4 consecutive STORES.

Also to read the flash there'd be no need to buffer the data, simply
read it from the flash and fire it directly down the wire. So that would
facilitate keeping the BAY down in size.

... with 14 bit execution tokens, four functions can be encoded in the
two high bits of a two-byte word.

and some of first primitives that you store:

* take an accumulated string of data in the BAY and puts in the RAM
location as addressed in the first token in the string (partial high
byte disregarded)

replace RAM with flash and I'm with you here.

* use the address and length of a pair of tokens in the BAY to load
data from the RAM to the bay (length to BAY length counter)

Same here.

* read off the data in the BAY, starting with the BAY length counter.

Do you mean transfer the BAY to the host?

* copy a string from program memory based on address and length of a
pair of tokens in the BAY


That gives you the ability to load a primitive at a time, test them
individual by copy contents to the stack locations and then reading
the stack locations back, then colon definitions and do the same type
of testing.

This way, you don't need the full kernel to debug the individual
primitives. Of course, your EXECUTE does need to be in sync with your
threading model, so whether there is a token interpreter, or bit
threaded / token interpreter, or a DTC explicit ENTER/EXIT/NEXT, that
machinery will be in the Kernal and used by EXECUTE.

Understood. Shouldn't be a problem with STC. fundamentally word
definitions will compile to a series of calls.

Thanks for the insight.

BAJ
.

Relevant Pages

  • Re: 8051 memory interfacing questions
    ... >> it comes to interfacing memory to 8051. ... The Philips Mx range have 192Kb on chip flash ... For stack, see later. ... of RAM. ...
    (comp.arch.embedded)
  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... bytes because that's the smallest chunk that can be written to flash ... stacks, to set up the initial stack and read out the resulting stack, ... If the destination out of the BAY is data memory, ... That also simplifies EXECUTE ...
    (comp.lang.forth)
  • Re: Stack Usage in CCS3
    ... > routine that displays a message on my 4x20 character display. ... the size of the message and a pointer to the first ... > stack rather than passing an address. ... I re-linked the project and compiled the same code into flash. ...
    (comp.dsp)
  • Stack Usage in CCS3
    ... routine that displays a message on my 4x20 character display. ... the size of the message and a pointer to the first ... stack rather than passing an address. ... I re-linked the project and compiled the same code into flash. ...
    (comp.dsp)
  • Re: HPGCC: Various problems
    ... This way you could have all the calculator RAM intact ... where port 1 also gives possibility to fully use ... Remember the original Flash ROM of the 49G? ... I think that the user stack area could be taken from port1 ...
    (comp.sys.hp48)