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

In article <1eyu0q09t1jks$.1fhbeh6r1b6tr.dlg@xxxxxxxxxx>,
Coos Haak <chforth@xxxxxxxxx> wrote:
Op Sun, 24 Jun 2007 10:12:40 -0500 schreef none:

In article <137sb0raq9lv503@xxxxxxxxxxxxxxxxxx>,
Elizabeth D Rather <eratherXXX@xxxxxxxxx> wrote:
none Byron Jeff wrote:
<snip>
It's a Harvard architecture that's difficult to access and slow to
update. So transferring little bits at a time is a highly desireable
trait.

Yes. But you need somewhere to transfer them to that's a little more
accessible than that. PIC doesn't seem to support ram development,
which is the best way to do incremental testing.

This is the reason I'm wanting to use the host as a remote execution
environment. The model you see is:

1. Compile words on the host
2. Transfer compiled code words to RAM.
3. Test/Debug code on target recompiling and reloading as necessary.
4. When finished transfer code to more permanent memory on target.

A perfectly workable model.

I doubt it, what about inline data (like literals, branches etc.)

Coos, I was describing Elizabeth's model of development, not the one I'm
proposing.

You have to have two different token interpreters: one for executing code
out of data memory (that would be RAM I assume) and one for code in code
memory. One of them would have to have an extra indirection. As they say
around here: two believers in one bed, the devil sleeps between them.
Look at the 8051s, here it is possible to overlay code and data regions, so
the CPU does not know it's executing from RAM.

So then exactly how do you untether the target from the host? Again I
was describing the model that Elizabeth described to me in her previous post.

<snip>

BTW you snipped my proposed model without comment. Code only transfers
once to the target and it goes directly to flash. No need for tracking
two different token streams.

BTW I realized that I'm still trying to figure out how in the heck forth
compiles a number into a definition. What is the xt for a number?

It's the address for (or call to) a word that pushes the actual value on
the stack, followed by the value:

... [xt of LIT] [value] ...

So the number is inlined into the code.
Code or data space?

Code. PICs are incapable of execute code directly from RAM.

I believe that pushing a number would have to be inlined in an STC
implementation because the hardware return stack is inaccessible. So you
can't read it in order to get the address of the value to be pushed, nor
can you modify the stack in order to return back to the code stream
after the value upon return. finally you can't leave the return address
on the stack and jump back to another location because the stack is
circular and limited and you'll overflow it. In short in an STC
implementation you can't make a call to a word to push the actual value.

Hence you'll have to inline it and put the actual code to push the value
in the code stream.

Of course all of this will go into flash where it can be executed
directly.

There may be different versions for 8, 16, or 32-bit literals. It has
to advance the interpreter pointer or PC beyond the value, in addition
to pushing the value on the stack.

That's problematic for an STC that doesn't have access to the hardware
return stack. It'll have to be inlined.

Many Forths synthesize the second stack, be it the return or data one, no
problem here.

The data stack will be synthesized, as will a nominal return stack. But
implementing with STC means using the PIC's hardware return stack. It's
unmapped in memory. It's invisible. Can't get to it.

Coos, the PIC 16F family is a weird bird. The only reason I'm still in
it is because of years of investment. Funnily enough forth may finally
free me from it. But to do it, I still feel the need to implement a
workable forth for me on that platform.

BAJ
.

Relevant Pages

  • Re: Build your own Forth for Microchip PIC (Episode 837)
    ... Transfer compiled code words to RAM. ... When finished transfer code to more permanent memory on target. ... I doubt it, what about inline data ... to pushing the value on the stack. ...
    (comp.lang.forth)
  • [PATCH 6/7] remove all remaining _syscallX macros
    ... * mainuse the stack at all after fork(). ... * calls - which means inline code for fork too, ... "Conditional" syscalls ...
    (Linux-Kernel)
  • [PATCH] x86: style fascism for xen assemblies
    ... * a view to being able to inline as much as possible. ... push %eax ... * This is run where a normal iret would be run, with the same stack setup: ... In order to deliver the nested exception properly, ...
    (Linux-Kernel)
  • [PATCH 6/6] remove remaining errno and __KERNEL_SYSCALLS__ references
    ... * we need this inline - forking from kernel space will result ... * mainuse the stack at all after fork(). ... * calls - which means inline code for fork too, ...
    (Linux-Kernel)
  • Re: Macros
    ... > of local variables and stack usage. ... > (even though I can't begin to understand machine code). ... code size and thus increases the risk of cache misses and the like. ... you can use the inline keyword as a alternative to macros. ...
    (microsoft.public.win32.programmer.ui)