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

In article <1182737074.816256.173580@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Bruce McFarling <agila61@xxxxxxxxxxxx> wrote:
On Jun 24, 8:15 pm, byron@upstairs.(none) (Byron Jeff) wrote:
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.

My idea was that the BAY can also be used to read and write to the
stacks, to set up the initial stack and read out the resulting stack,
when testing whether primitives work. So a string of 14-bit values,
with the top two bits telling the function (I'd use 00 for
ACCUMULATE). If the destination out of the BAY is data memory, the
upper 6 bits of the 14 bit value is just ignored.

OK that makes sense. You'd then need to have a length marker because the
size of the stacks are variable.


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.

Again, the double purpose of using ACCUMULATE to set up the BAY for
transfers to and from RAM or for Flash is why the STORE to flash is
seperate ... once you have execute code in flash, download data, and
store data to flash, you can build the balance of the umbilical
development system from there.

Got it. The BAY is a generic transfer point.

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.

I don't see why. Just make sure that MARKER's are aligned on word row
boundaries, so that when the MARKER is executed it cleans out all the
Flash from that point on.

But would that not limit words to 32 word boundaries in the flash? Fine for
initial testing by wasteful in practice.

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

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.

Neither reading the RAM to check the stack effects of primitives as
they are loaded ... so BAY can be dedicated for input from the host.

So the host is limited to sending packets of a constrained size, but the
target can send packets of the requested size directly down the wire.

That asymmetry makes sense.

* 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.

That's STORE. This primarily is to load the stacks with parameters for
testing.

There's really no need to have a separate command to differentiate RAM
and Flash. This is a discussion I already had with my students. The
address byte is going to be 16 bits. No pic address space comes close to
that. So simply subdivide the address space so that low address go to
RAM and high addresses go to flash. Then all you need is a single STORE
to determine to where the BAY is transferred.

You can even have an address space for the data EEPROM so that you can
transfer data to and from it.


* 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.

As noted above, this need not go through the BAY, it can be output by
the PIC directly

Right. The host will have a virtually unlimited BAY. In addition since
the host specifies how many cells it wants, it too can limit the size of
the packets coming back from the target if it wants.

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

Do you mean transfer the BAY to the host?

Yes, but given direct read flash and read RAM operations, this becomes
redundant.

No need for a double transfer. Got it.

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

... with the last word in the definition being a jump instead.

Woozy with confusion... I thought the last word would be a return. STC
uses the hardware PC as the "IP". So when you finish a word you retrieve
where you came from from the hardware return stack. That's a return.

Only exception would be code that's inlined into the instruction stream.
Elizabeth has already help me identify that literals would have to be
inlined for example.

Precisely ... and as long as you know you are working with an eight
deep R stack, that's certainly workable. That also simplifies EXECUTE
a lot.

Have to think about EXECUTE. I'm less woozy from for initial suggestion
about a jump at the end now. The problem is that we're not working in
RAM and we don't have access to the hardware return stack. BTW this will
be a 3 stack machine because we still need a R stack in addition to the
hardware return stack and the data stack. So let's differentiate by
having a R stack and a HR stack, OK? The HR stack is 8 deep and
invisible. Also we're working out of flash. So we can neither easily set
up a stack entry to return from to start executing, nor can we easily
setup a computed call (that would be very useful here). This is
complicated by the fact that for ordinary words we utilize standard
call/return semantics.

What's going to be needed is the concept of a special top level word
that both gets the ball rolling and knows to return to the executive
when it finishes. A MAIN word as it were. The easiest way to implement
this is to have a word that jumps to the executive and put it as the
last word of the MAIN definition (EXIT?). Another possibility (which would
slow down overall execution) is that we put that EXIT word at the end of
every definition and make it conditional based on some flag. If the flag
is set, we jump to the executive, unset, we return normally. I still
have to think how we could use such a construct because the flag needs
to be set just before you execute the EXIT token. Can't think of how to
make this transparent.

Great ideas. Thanks for the input.

BAJ
.

Relevant Pages