Re: Structured Programming using Forth

J Thomas wrote:

[%X]

Werty comes up with dreams that programmers would tend to like, or at
least near-programmers. Programming with interlocking symbols that
only fit together the right way and that intuitively show what they
do. Wouldn't it be wonderful if you could do that! I had the idea of a
Forth editor that would display stack inputs and outputs as colored
lines, and when you type a word (or drag the icon) it draws the lines
to it and from it, and shows you if there's an obvious type error.
When there are 4 stack items and the word only uses two then the other
two would go under the word and stay down until some other word was
ready to use them. It was the same sort of idea except not nearly as
bold.

This is an idea that was written up in Forthwrite some years back in an
article by Gordon Charlton. A great idea but no one at the time saw a way
to accomplish it. If someone does manage to produce such an editing system
then please tell us (I can imagine it might be a bit like the National
Instruments VI editor).

Oh well. Ideas are cheap -- and yet when you don't have one, how
expensive it is! I'll offer a Werty-like idea that I presented here
years ago and didn't do much with myself. I claim that mostly, having
a sea of processors for a program isn't much more use than having a
sea of programmers for a project. You need a way to organise them. And
one traditional way to organise programmers is with the "surgical
team" approach. Each member of the team gets a specific job that they
do well. You might want each team member to have specific training for
their particular job, too.

Chuck is with you there. Intellasys are working on the hardware for the sea
of processors already.

So if you have a "surgeon" processor, you might want to have a second
processor whose primary job is to hand off data. The surgeon says
"scalpel" and expects to have a scalpel put into his hand, he doesn't
have a stack of recently-used instruments and do ROT and PICK to get
the right one on top. So the surgeon's assistant processor could
simply take the stack item he doesn't need for awhile -- knowing he
doesn't need it because her program says so. And the assistant
processor would have a program that tells her "Hand this one back
after 17 cycles". Or maybe "Hand this back after 17 cycles unless you
get a flag set on cycle 12, in that case hand this other item back on
cycle 15".

A whole processor just to handle local variables? Why not? It saves
the surgeon seconds, and over a whole operation those seconds add up.
If he thinks out his procedures carefully enough he can make sure the
right tools are usually on top, and that's more efficient when you
don't have a surgical assistant. If the assistant is there, why
bother?

Might be worth looking into with the Intellasys processors.

What if a surgeon had a prompter who reminded him what to do next. In
the heat of the moment he wouldn't have to do that planning, he could
work faster by instinct. What if the surgeon-processor's control-flow
logic gets done by another processor, that does nothing else? If the
surgeon generates a flag and then takes two cycles arranging its jump
or branch, the scheduler processor might prepare ahead of time and
then on receiving the flag do the work in one cycle.

The surgeon can hand off other tasks to assistants -- particularly
tasks that can be done mostly independently. Prep, cleanup,
anesthesia, etc. But the teammates that make him more effective are
central.

At this point the main processor has been reduced to an ALU. How is it
an improvement to split it into three processors? The answer is that
by having the machine code in three different local caches, the data
management and the control-flow logic can all run in parallel. There
are other considerations -- like they can each afford a simpler
instruction set because they do different things.

the problem then becomes that specificity of each of the processors can
become a little inflexible if they are geared to just one series of tasks.
Yes, it would be very quick and slick but if you needed to do a different
operation could it be changed as easily as having given the separate, and
more general, processors the task of the moment and then be able to
reprogramme for a new operation. A trade-off between generality and
specificity must be made and striking the right balance is fairly hard.

I can't promise that no on has patented this, but whatever parts of it
are not patented are published and free to the public domain.

Now I know I need much more play time. ;>

--
********************************************************************
Paul E. Bennett ....................<email://peb@xxxxxxxxxxxxxxxxxx>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
.

Relevant Pages

  • Re: Structured Programming using Forth
    ... Werty comes up with dreams that programmers would tend to like, ... So if you have a "surgeon" processor, you might want to have a second ... So the surgeon's assistant processor could ... Or maybe "Hand this back after 17 cycles unless you ...
    (comp.lang.forth)
  • Re: Structured Programming using Forth
    ... When there are 4 stack items and the word only uses two then the other ... What novel idea has werty had? ... So the surgeon's assistant processor could ... Or maybe "Hand this back after 17 cycles unless you ...
    (comp.lang.forth)
  • Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes
    ... | that instruction sequence. ... the cost is 6 cycles instead of 1 cycles. ... save the current data segment registers (the stack segment and code ... I kept the information that is saved on the stack exactly the ...
    (Linux-Kernel)
  • Re: Stack dances
    ... for even more complex stack ops)? ... that takes zero cycles. ... My curiosity re fxch was triggered when I realised that Intel engineers did not design equivalents for FPICK or FROLL into the '387 instruction set. ... FEXCH on the Intel. ...
    (comp.lang.forth)
  • Re: which way is faster?
    ... MOV ebx, ... cycles I read, inclusive, Using your previously posted technic. ... that you fitted each instruction to the entire sequence. ... Its allmost as you treat the stack as if some sort of evil monster. ...
    (alt.lang.asm)