Re: Structured Programming using Forth


On Apr 2, 7:34 am, "Alex McDonald" <b...@xxxxxxxxxxx> wrote:
On Apr 2, 1:21 am, "rickman" <gnu...@xxxxxxxxx> wrote:

I dunno, maybe John is on to something. Perhaps as bizarre as it
sounds, perhaps werty is the new messiah of programming...

wer-ty, wer-ty, wer-ty...

Puhleeease. I could type with my elbows and still make more sense than
werty.

If you were to treat him as an oracle, and try to imagine ways to
create the visions he alludes to, you might come up with something
really innovative.

You can tell something about who people are by what they want. Like, I
read about a man who was teaching hypnosis to MDs, who -- to make a
point -- told them about a wonderful innovation. They put a great
local anesthetic into the rubbing alcohol they used to wipe off skin
before they gave a shot, and the result was the patient didn't feel
anything after they did that prep. He invited some of the MDs to try
it, and they were completely anesthetised when he rubbed alcohol on
their arms.

He said it only worked on medical people, because it was something
that they would see as a wonderful improvement, it would remove a lot
of bother for them so they were eager to believe it would work.
Regular people wouldn't nearly as much care about that or believe in
it.

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.

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.

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?

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.

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.


.

Relevant Pages

  • Re: Structured Programming using Forth
    ... When there are 4 stack items and the word only uses two then the other ... So the surgeon's assistant processor could ... Or maybe "Hand this back after 17 cycles unless you ... the surgeon seconds, and over a whole operation those seconds add up. ...
    (comp.lang.forth)
  • Re: Structured Programming using Forth
    ... perhaps werty is the new messiah of programming... ... 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 ... Or maybe "Hand this back after 17 cycles unless you ...
    (comp.lang.forth)
  • On methodology (was Re: Use Case... advocacy)
    ... but that their presence on a team doesn't correlate with the methodology ... magnitude more productive than average programmers. ... one 'surgeon' - the recognised highly productive programmer, ... Any system which tries to divorce design from implementation will fail. ...
    (comp.lang.java.programmer)