Re: !p+, and thank you Jeff

vandyswa wrote:
I was thinking some more about the "codelet" guess on !p+:
for @b !p+ next
and looking at the SEAforth instruction set table, and I convinced
myself it won't work

Oh dear.

(although there's still the germ of a really cool
idea here). "next" is lumped in with the rest of the jump
instructions, which probably means it uses the latter half of the word
as the jump destination, and it probably rewrites P, so !p+ doesn't
seem like it would play to fill in blocks of code words.

Jeff mentions the F21 (which I didn't follow, though I still have & run
my MuP21), and interrupts.

What didn't you follow?

I can see !p+ as being a register-efficient
(though non-reentrant) technique for moving data into memory (don't run
it in ROM, though!). I'm pretty sure the SEAforth position papers said
interrupts weren't needed,

Interrupts are needed on machines that have as their main bottlenect
that they have only one central processor and if that central processor
has to do more than one thing. Mininal respone time for polling
will be related to how many things you have to poll. And the minimal
amount of time to process an interrupt to deal with asynchronous
events will likely be less than polling a list of things.

But like many other assumptions about what hardware will be
needed to run inherently hostile applications under a
one-size-fits-all OS will require a long list of hardware features
the assumption that interrupts are faster than polling is wrong
for our asychronous parallel processing.

Many of the features that give us an advantage over mainframe
style processing where one processor has to multitask and
protect the system from unpredictably bad software are likely
to be seen a errors by mainframe style programmers who
will think we need this or that hardware to fix our software.
Interrupts, watchdog timers, and one-size-fits-all OS are
examples of things that don't map to what we are doing.
Our bottlenecks are not based on only one CPU.

thus I was assuming no interrupt support in the CPUs.

They white papers explain that and the reason. People
don't like my explanations in c.l.f. But I think I have
explained it here too before. And a while back I started
a thread where I asked about our style of simple
embedded code and gave ten examples of things
that make it simpler and faster and eaiser to deal
with than mainframe style software. I asked if anyone
thought of this simple Forth software for simple Forth
hardware as bugs that demand adding more hardware
so it works more like mainframes. Yes some did.

You can save 1-4 words in a single instruction word, and
similarly get them back in two or three words (at least one to get the
lit addr plus the requisite @p+'s, and another holding the lit addr
itself). Seems useful for stack depth management,

Hmm. Stack depth managment is usually the biggest imaginary
problem to deal with with Forth programmers. I mean some Forth
programmers imagine stack depth managment problems that
we don't understand. We think Forth is about managing the stack.
Unless you are clueless about managing a stack you don't
have stack managment problems.

If you are clueless about managing a stack you may really have
a stack management problem that will then require other
complications and other problems.

We think that this is what distinguishes Forth from mainframe
style software. But sure if you do mainframe style software in
Forth, and we know you can write C or Fortran style in whatever,
then you will have stack managemnt problems requiring
mainframe style hardware to deal with the mainframe style
software problems.

and possibly for
implementing coroutines (though that style of coding didn't strike me
as a fit for this CPU).

You mean like a ;: opcode? Guess what?

I kept fiddling with !p+, trying to figure a way to have a peer CPU
supply at least *one* instruction word for my local CPU to execute
next. Then CPUs could, instead of sending message types or any such
nonsense, feed each other direct jumps to the handler for the message
which follows. But P walks forward after getting the data, so you'd
have to burn a whole instruction just to step backward. You'd do just
as well to accept a word onto the opstack, move it to the return stack,
and then ";" it.

You know there are people who like to put jigsaw puzzles together
from the back where the only clues they have are the shape of each
piece. I know people like this. And sometimes they make a point
to never look at the picture on the other side of the puzzle.

Piecing together this puzzle from the back side must be fun,
and I realize that many people don't want to look at the picture
one the front side of the puzzle. But I find it puzzling that more
people don't care about the big picture, how it all works,
hardware and software.

This is not an uncommon phemon in Forth. Forth is like a puzzle
and the picture on the puzzle is the application. Many Forth
programmers like rearranging the pieces from the back but
don't care at all about the actual picture, applications. We all
know that.

I look forward to getting to hear about more of the CPU, and its other
facilities which might leverage the very interesting !p+ opcode. And
thank you, Jeff, for giving us a little bit more to think upon.

I am not done. But it is an uphill struggle because obviously
there are quite a few people who will tell me to shut up and
who don't want the real answers to questions like yours presented
in this forum.

.

Relevant Pages

  • Re: how to program in Forth?
    ... LUDDITE LUDDITE LUDDITE!!!! ... But why is using the return stack for anything other than a return ... in minimal instruction space and I use the return stack for loop ... instructions and the hardware required to implement it. ...
    (comp.lang.forth)
  • Re: XP sometimes balks on boot-up
    ... to catch this trap. ... Memory corruption, other hardware ... The most common cause of this is hardware memory corruption. ... A kernel stack overflow. ...
    (microsoft.public.windowsxp.general)
  • Re: using MISC (post 1987 Forth hardware) opcodes
    ... This clearly had nothing to do with hardware in that an ELSE is ... Like dozens of other things Chuck explained his reasoning. ... for those interested in the conceptual foundation ... people ask why we de-emphasis the use of the stack. ...
    (comp.lang.forth)
  • Re: hardware errors, do C and Forth need different things in hardware?
    ... hardware is to people who are thinking C software ... need or want the sort of complications that this code avoids. ... If it confuses solutions for bugs it will introduce REAL bugs. ... back from the stack is greater than the size of the stack. ...
    (comp.lang.forth)
  • Re: write statement output buffer flush off on Sun
    ... > routine is usually greater than the cost of checking for a nonzero ... > are passed on the stack, passing the addresses involves memory traffic. ... branch - and it may involve additional instructions on some ... hardware, a conditional branch costs about the same whether it's ...
    (comp.lang.fortran)