Re: Structured Programming using Forth

On Apr 6, 12:04 pm, John Passaniti <n...@xxxxxxxxxxxxxxxxx> wrote:

MachineForth is the lowest level stuff. In 2004 we started adding
higher
levels of abstraction to the programming environment. Marketing has
said that software will released in stages starting with the low level
stuff. To understand the architecture or the inner working of low
level code some people will want to start with that sort of in-depth
explanation. Later people who work at a higher level of abstraction
can be brought it without needing them to become experts on the
low level stuff.

Can these tools be extended? Probably. Will they?

Don't be silly. They have. It is not my job to tell you when a given
feature will be released, or any such marketing information. But
since most of the information posted on IntellaSys in c.l.f is coming
from you I just wanted to correct your guesses that are a few years
out of date now.

That's a question I
have, and it's a question at the intersection of software philosophy and
marketability. Traditionally, the Forth community has looked at
optimizing compilers for other languages and said these were bad things.

Yes. Chuck thinks colorforth is entirely sufficient as a development
tool for the chip. And for him it certainly is. I like it too, but
insisted that people shouldn't require anyone to switch to something
so radically different as that just to program a chip.

If they want to license the CAD system and make high performance
custom VLSI analog and digital chips then they will need to learn
colorforth. But many many more people will just want the ability
to get software to do what is required of a project.

The traditional view is that the programmer should be in direct
control and the language implementation should be simple.

That is true. I have argued that we practice Forth at many different
layers of abstraction from the lowest to the highest. Forth experts
who can do wonderful low level stuff are great but there are also
people with important problem domain expertise who should work at
a higher level of abstaction to be most productive. I know you have
made that argument many times in c.l.f before and that a Forth
script offering a higher level of abstraction would be more
useful for a larger number of programmers than systems designed
for use by expert programmers.

So if Intellasys maintains that traditional Forth philosophy of
simplicity, I would expect they won't be coming out with tools that do
the optimizations for the programmer. They might have tools that give

I think you are guessing wrong. They seem to be more in sync with
your ideas expressed in the past than you are willing to accept.
Maybe you are just looking for an argument and will argue against
your own ideas if IntellaSys agrees with them.

the programmer metrics about how optimal the code is, and they might
come out with libraries of macros that offer pre-optimized code that
does non-obvious things. But a philosophy of simplicity in the tools
suggests they won't be extending their tools to be optimizing compilers.

Your assesement of the philosophy of the company and the things that
that suggests to you don't seem to jive with either my understanding
of what IntellaSys is doing or with my impression of what they have
made public.

I am not sure who you are arguing with except for your own imagination
of some companies' unpublished philosophy implies and suggests about
what they will be doing in the future. ;-)

Alternatively, Intellasys might take an different view-- that market
acceptance of the SEAforth chip will require that they make it as easy
as possible for engineers to use their chips. In that case, they might
extend their tools to optimize code, or even to automatically generate

Or they might have hired people who have been working on these sorts
of things for several years as they have reported repeatedly.

Once again, the things that you guess might maybe someday happen are
what we have been reporting has been happening for a few years.

code that takes advantage of the multiple processors. Such tools won't
be simple, but they'll make using the chips simpler.

We think so and we agree with you.

Is it one or the other or some blend between the two?

Or is the question about whether it will happen just too many years
behind it happening and being it being reported in presentations for
the last few years that the question is based on a misconception and
thus should be dismissed not answered.

I have no idea,
and part of the reason I'm asking these questions is that I know other
people do know (or strongly suspect) the answers.

The questions are certainly valid questions. I had hoped that the
Forth people with an interest in IntellaSys or the recent work of Mr.
Moore would stay as current as they could by taking advantage of
the regular and detailed presentations that have been made to the
Silicon Valley Forth Interest Group. The presentations for the
last few years have answered all the questions you pose and many
more while being framed in a way hopefully meaningful to people
with a Forth background.



That also brings up a limitation of the Port streaming method of
running a program, if it is executed on the fly and not stored, how
does it handle looping... ah, loops must be kept shorter than a
word!

Or if you can execute out of each processor's RAM, you could cache
several instructions. I don't know if data in the RAM is executable.

Correct. Looping in RAM or ROM is totally straightforward. In a
port a micro-next loop repeats the same instruction word without
an instruction memory fetch.

Other branch opcodes, jump, call, ret, IF, and -IF as well as normal
NEXT (loop) will require an instruction fetch from the destination
address. In the case of a port another processor has to write
the word that is read and executed by the other processor. Unlike
a micro-next loop a branch to a port will require an instruction
fetch.

One can read instructions in RAM, ROM or a port and can read
data from ROM and read and write data in RAM and ports. So port
code and read and write data in RAM and in ports. And data
can be instructions to other processors.

It is true that branching to a port, or branching in a port
instruction stream requires another port read, but one should
remember that ports are actually faster than RAM or ROM. So
while an instruction read is required it is faster than an
instruction read from RAM because you are executing a register.

I don't see a lot that is unique about the SeaForth chip at the
architecture level.

If someone wanted to program in ANS Forth, and choose to use eForth
on a SEAforth chip they could focus on portable Forth and pay
little or no attention to the architectural details. But an ANS
eForth on a small chip is nothing too special.

Like a soft core on an FPGA they would then have lots of unprogrammed
circuits to program to do custom IO. Like an FPGA the soft processor
wouldn't have to be very fast if all it did was shuffle data to
the fast custom IO circuitry. But then one would be back to all
the architectural details of what do make the chip different.

It may have some fancy low level chip design
techniques, but what is really interesting is how it will be
programmed to get high performance out of such small memories and how
the processing load will be shared between so many processors
efficiently.

The machineForth techniques are mostly those described in the last
sixteen years with a few new opcodes. The local memories are so
small that all those techniques desribed such as letting stacks
wrap freely in either direction without throwing errors or needing
to add DROPs or DUPs to balance things, auto-increment modes
replacing a line of Forth with an opcode, opcode packing, and
a few techniques are how programs are made small.

The partitioning of processes to processors is followed by attention
to whatever is the biggest bottleneck as one bottleneck after another
is reduced by code optimization or resource reallocation.

It's the architecture (multiple processors, small amounts of RAM/ROM,
the nearest-neighbor communications channel between processors,
eschewing dedicated hardware for software, multiple opcodes packed per
instruction word with restrictions such as addressability limits, etc.)
that in total is unique. You seem to be looking at each of these parts
in isolation and not thinking ahead to the point that I'm making:
Programming these chips is going to be *different*. It isn't going to
be Forth as usual.

I agree that for most people this is not Forth as usual. But there
are
people who have been desribing this stuff as Forth as usual for a long
time. This year will be 20 years of Forth as parallelizing
machineForth
on small parallel Forth computers.

Perhaps I should mention that although only nearest neighbors have
hardware interconnect the software and ROM BIOS permit routing of
messages from anywhere to anywhere. Remote execution is decoupled
from routing. Writing an opcode to a port is exactly the same
whether the neighbor is executing it or routing it accross the
chip, over a bridge to another node, over wireless link to another
node, out over the Internet and back to a different processor
somewhere else and executed there (as far as the processor doing
the write as a remote execute operation is concerned).

If you don't see that, then I don't think you've thought ahead.

I have. I've taken a few of the real-world projects I've worked on and
thought about how I would approach using a SEAforth chip. I've thought
about how my code wouldn't just have the usual dimensions of space and
time, but also placement, since which physical processor you use
matters. I've talked with the DSP folk where I work to understand their
concerns in synthesizing multipliers of sufficient bit width from the
SEAforth primitives. I've thought about how the idea of replacing
dedicated hardware with software on the edge processors would affect things.

Good stuff. How many more bits than 36 do they need in the algorithm
they
are using?

I can think of *lots* of ways in which the architecture of the SEAforth
chip will have a profound effect on how applications are written. You
seem to want to abstract all those details away with some arm-waving
"Forth is extensible" answer that doesn't really answer the hard questions.

I didn't read his 'arm waving' but perhaps he is just guessing about
some details and not always guessing right.

Best Wishes

.

Relevant Pages

  • Re: SN54LVT8980A JTAG TAP MASTER help..
    ... I have put the chip on a logic analyzer and have found ... >>when executing a instruction register scan or when I execute a data ...
    (comp.os.linux.embedded)
  • Re: 6809 SBC in development
    ... design material will be free and publicly posted as part of the N8VEM ... helps check out the chip selects, data, and address lines to make sure ... Z80 to set up some handshaking. ... attached to the port B of the 8255. ...
    (comp.sys.m6809)
  • Re: VON NEUMANN VS HARVARD
    ... have one write and one read port and snooping isn't an issue. ... For single and double operand instruction sets the dcache will ... Tell me where in the C standard does the language allow you to ...
    (sci.electronics.design)
  • Re: LPT port, anyone ?
    ... The chip has to be ... > Input pin to gather the data one bit at a time. ... put a signal into a pin that's pulled high by the chip port. ... >> for just some 5 sensors on one port. ...
    (comp.lang.pascal.delphi.misc)
  • Re: The coming death of all RISC chips.
    ... and dumping their own old ARM instruction set. ... number of execution units, is counter productive. ... unfortunately this chip was slower than the previous chip at getting ...
    (comp.arch)
Loading