Re: Structured Programming using Forth

rickman wrote:
On Apr 6, 2:37 am, John Passaniti <put-my-first-name-
h...@xxxxxxxxxxxxxxxxx> wrote:
foxchip wrote:
The comments about factoring of code into very small pieces are
correct that the only examples provided so far had been low
level things that focus on the 'resource constrained' techniques
rather than the tools at higher levels of abstraction. The internal
RAM (which might sort of act like cache) and internal ROM are very
small by almost any resource constrained environment standards.
Optimization requires focus on low level stuff and to size and
speed bottlenecks in most cases.
But even though the examples given so far are low-level kinds of things,
I can't imagine much changes as you get higher. You probably still have
to manually optimize things; I'm guessing the tools Intellasys provide
don't attempt to automate optimization at all.

I'm not saying this is good or bad-- it's just a consequence of the
architecture.

That's what I don't get about your posts, this does not follow from
the statements above. The degree of optimization in the compiler has
*nothing* to do with the archtecture of the chip! Why do you say
stuff like that?

My statement is that code optimization-- regardless of if it comes from the programmer manually sequencing instructions or from an optimizing compiler-- is a *requirement*. It is a consequence of the architecture which is predicated on a matrix of many small processors. This as I wrote isn't good or bad-- this is just a reflection of the design.

In your last reply to me, you disagreed with my statement that programming a SEAforth processor was going to be much more like assembly language programming than it would be Forth programming. Your reply was that Forth is extensible. But key to my statements was that the examples given so far in Intellasys's own documentation don't show extensibility. What they show isn't much different from a traditional assembler implemented in Forth.

Can these tools be extended? Probably. Will they? 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. The traditional view is that the programmer should be in direct control and the language implementation should be simple.

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 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.

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 code that takes advantage of the multiple processors. Such tools won't be simple, but they'll make using the chips simpler.

Is it one or the other or some blend between the two? 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.

A Flash device would be horribly slow and would never support adequate
speeds. That is why on even much slower ARM systems with external
Flash, the code is copied into RAM so that it can run closer to the
full speed of the chip.

It's slow if you assume you need to feed one of the SEAforth processors at the instruction rate. I guess that's the "port streaming" notion.

But that's not the context of my statement. As has been discussed, it's possible to implement a virtual machine to run those parts of applications (such as TCP/IP) that may be too large to implement inside a single processor. My understanding is that the SEAforth chip tries to replace dedicated hardware (such as memory controllers) with software. So a flash interface is likely to take up one of the 24 processors, and is free to use whatever RAM is left over as a cache to feed whatever processor is requesting the data.

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.

This isn't an issue if you're implementing a virtual machine.

Also, I'm unfamiliar with "bit-threaded." Care to describe what that is?

This reminds me of the story of Chuch showing off one of his new
versions of Forth (I don't recall which one) which had some very
different user interface designs and some very interesting
functionality. The people at the demo were asking tons of questions
about the chording keypad and ignoring the software!

My question asking for a definition of what "bit threading" means is somehow equivalent to others focusing on the user interface of a programming language? Someone tosses out an unfamiliar term and I asked for a definition.

I don't see a lot that is unique about the SeaForth chip at the
architecture level. 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.

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.

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.

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.
.

Relevant Pages

  • Re: Forth as an operating system
    ... What I'm more concerned about isn't the raw speed of the chip, but the effort involved in programming them. ... So if chip A takes twice as long to learn, write code for, and debug than chip B, we have to take that into consideration. ... That doesn't mean you can just hook up a USB device and you have a Master or Slave interface available. ... What would make the SEAforth chip make design engineers sit up and take notice is if IntellaSys develops a bunch of IP to handle the common kinds of interfaces and protocols. ...
    (comp.lang.forth)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... and just hone in on the stuff related to programming and this newsroup] ... moron that was taken from optimization which does hoist when to do so ... compiler design and optimization, including my 1976 text in graduate ... loop in a language in which the designers messed up, ...
    (comp.programming)
  • Re: Hardware Guru for Hire?
    ... PCs have only used the 512 byte sector size. ... The USB-to-FDC chip is a whole microprocessor PLUS an FDC chip WITH A FIRMWARE OPERATING SYSTEM. ... Also, in the context of my response that certain things might not be "programmable", I was defining "programmable" as "programmable from the PC via the USB connection", and I was referring to the "stock" version of the chip, not a version with custom external firmware. ... Things like what sector size and how many just minor programming thats ...
    (comp.os.cpm)
  • Re: Any recommendations for a good overview of pic and basic stamps
    ... >>loaded onto the chip via a cable linking the chip and a PC. ... > Another poster has covered most of the 'Basics'. ... However the Stamp module, would not even be ... > comprising a carrier board, programming cable, one stamp, manual etc., ...
    (sci.electronics.equipment)
  • Re: Any recommendations for a good overview of pic and basic stamps
    ... >>loaded onto the chip via a cable linking the chip and a PC. ... > Another poster has covered most of the 'Basics'. ... However the Stamp module, would not even be ... > comprising a carrier board, programming cable, one stamp, manual etc., ...
    (sci.electronics.design)