Jeff's UltraTechnology Blog

The Silicon Valley Forth Interest Group released the notes and videos from their Forth Day in November. I discovered that they had their video camera pointed at the speaker with only the bottom right corner of the video projector visible.

In the SVFIG mail list we heard that the slides from most presenters from Forth Day have now been posted at: http://www.forth.org/svfig/kk/11-2010.html

and that most of the videos can be found at: http://www.forth.org/svfig/videos/fd2010.html

We should expect those two pages to be merged together.

The nice thing about high definition video cameras is that one can put a 4x3 video at 1024x768 resolution in the left side and have a third of the scree left over to capture the presenter on video. One can then remaster it down to a slower frame rate and the lowest resolution that still shows what is on the computer display and being presented. This year there were presentions with big fonts in PowerPoint and presentations with big fonts in colorforth. Both were displayed on the video project for everyone.

Here is a jpeg image of a frame from an HD Video I shot of Chuck's 2006 FireSide Chat. Click on it once or twice to see it in full resolution.

I assumed that that is what SVFIG was going to record to video. This was something I did for years and was happy to let them do instead. But when I looked at the videos for this year I realized that they had filtered out all the video from the video. They had video of the presenter but not the video presented by the presenters.

SVFIG then collected the "Slides" from the people in PDF format so they could offer what some people presented on video to them on their web site. But because they didn't video the video they filtered out all the coloforth presentations and only passed on PDF slides to people instead.

I went ahead and made a few slides from the colorforth screens I used. It isn't as good as the live video where you see what the editor, compiler, simulator, and ide do keystroke by keystroke. But it is better than just a talking head talking about video that you can't see.

I guess I have odd expectations of what might interest people in the Forth Interest Group. The PDF file that Greg Bailey did was generated by a tiny amount of Forth code. I would think people interested in Forth would be interested in the tiny amount of Forth code needed to generate a PDF file. But it seems that they would need the Forth code in PDF format before they could see it at all the colorforth video output was not recorded at this year's Forth Day.

There were about forty people who attended the Silicon Valley Forth Interest Group's Forth Day this year. It was fun seeing friends and hearing about what other people are doing with Forth. It is always nice when people can get together to discuss Forth without anyone objecting to their use of Forth or wanting to take up their time telling them that they should be using something else instead.

I found it interesting that there were more reports on Forth in hardware and software than about Forth software for conventional hardware. In 2009 Leon Wagner of FORTH Inc. gave a presentation where he built a RISC CPU for a FPGA and used SwiftX to compile Forth code for it. This year FORTH Inc. had Brad Eckert show a Forth CPU and generate Forth code for it. Along with Green Array Chips presentations there were other presentations on Forth in hardware and software.

I enjoyed Dr. Montvelishsky's presentation on a 3D steroscopic machine vision application for a robot. It was similar to the one we did for BMW research. The problem with the previous system was that it consumed too much power. They liked the version that could run the whole thing from a small solar cell.

Green Array Chips President Greg Bailey told of plans for 2011 and plans for on-chip flash and/or large on-chip SRAM blocks. He provided some background and insight into the company's strategy.,

I showed some simple F18 processor code examples running in software simulation and on hardware using the Interactive Development Environment. Softsim is available now in the public release of ArrayForth and the IDE will be provided before chips and development boards are shipped to customers. Differences between colorforth and more conventional Forth were shown, differences between Pentium colorforth and colorforth code for targeted Green Array Chips were shown. Differences between software simulation and the Interacitve Development Environment were show.

In Pentium colorforth N FOR NEXT performs N interations and exits and removes the index from the return stack when it reaches zero. On the target colorforth code for F18 processors FOR NEXT counts down past zero so performs N+1 iterations of a loop. The word ZIF which is a sort of forward NEXT so that FOR NEXT loops can perform N interations when that is desired. NEXT takes an address argument left by FOR or BEGIN and resolves the NEXT branch when it is compiled. ZIF compiles an unresolved forward NEXT which is resolved by a THEN.

The words IF and -IF and the associated UNTIL and -UNTIL are also different on Pentium colorforth than in target colorforth. On the Pentium version they use actual Pentium status flag rather than the contents of the top of the stack. So in target colorforth you can say:

... IF

... 0 OR IF

... 0 OR DROP IF

In Pentium colorforth variables are created as variables when they are defined in the editor.In colorforth variables are initialized to zero when created in the editor. In traditional Forth variables were initialized when they were compiled but in ANS Forth they are not. Variables are normally initialized somewhere and in colorforth are often initialized in a sequence of yellow interpreted code after the place where they are defined when the compiler is running. If they have a yellow sequence they will be initialized when the code is compiled. Sometimes variables are initialized in compiled code executed by the application.

In colorforth the variables in the source are actually variables created and tagged by the editor. They are initialized by the compiler or by an application. Because they are live their value, in the source code, will reflect the latest change to their value that has happened.

While a program is running or after it has stopped the contents of the variables in the source code reflect the last change the application made to them because the variables in the source are the application variables. Variables are live in the source code. Numbers and variables in a program are actually numbers and variables in the source itself and make for more powerful programming tools. By itself live variables is a very powerful debugging tool built in at a very low level in the system.

One of the innovations in colorforth is that variables are live. If you look at the source code for a block, edit it or list it, then have a program change the contents of that variable or if you change the contents of that variable on the command line you will see the contents of the variable change on the screen. You don't have to open a special watch window, you don't have to refresh the editor view, a previously edited or listed display of the source code will change on the screen as its contents change in the background.

I would not expect people who have never tried them to easily appreciate how powerful and productive they can be. I have just touched on a couple aspects of these things. The implications of what you can do with them are profound.

It is a powerful thing to be able to do all these things at edit time, at compile time, and at runtime with no effort. Many people are not using Forth tools at edit time so they simply cannot use these features of Forth systems. I can imagine some of it being done in other languages. One can think of it as simply a program treating its source code as data. But it does use database and spreadsheet like features way below the level of files and uses them to contain and manipulate source so that more can be done with it in all time phases.

Variables work a certain way in Pentium colorforth but are not used the same way in the target code for the f18 processors.

Many Forth provide a way to view the stack or give the user a default view that includes a stack view. Some Forth provide a way to specify that you want to watch a variable and see a live view of its contents. They may let you specify a variable to watch or to place a variable's address into a memory watch window. But that is not as powerful as having all variable automatically do that in the editor while giving the abstract source code view.

Like blue words in the source the live variables in the source are an example of how Forth spans more of the time dimension than some language by letting the user specify edit time, compile time, or runtime and do editing and compiling in applications at runtime as well. Live variable in the editor and blue words in Forth are examples of expanding the power of Forth at edit time.

Wil Baden provided excellent examples of being able to cut and paste Forth code in an editor to create macros in Forth that editor can execute by doing a call-back to Forth. In colorforth this whole process is made as simple as possible by saying that blue words execute when the editor encouters them. The first thing I did in my demonstration of colorforth was to turn the word SEEB from white to yellow. This word means "See blue words."

I explained that even though they are not visible on the screen when SEEB is just a comment in white at boot I still see them in my mind because I know a blue word had to perform the return or reverse return or tab that I see there in the colorforth editor display. But when SEEB is executed on boot you actually see the blue cr or -cr or tab on the screen along with the effect that executing it caused. These blue words make spread-sheet and other on-screen macro execution possible and support the use of edited blocks with blue words as templates for other operations.

I showed the Pentium colorforth tools to convert to or from ASCII and to HTML as well. I showed various I/O drivers and utilities such as the ADUIT tool for source code management. The ADUIT utility lets one see blocks that have changed relative to a previous release and let one toggle the block display between the two versions to highlight the change. Like other things in colorforth you can feel that it uses different parts of your brain than a less visual tool which relies on more use of symbol processing in the brain of the user.

I showed the powerful set of tools that do things that are very difficult with ASCII source code in files spread out over multiple directories, disks, or networks. It should be easy to "find" words in a Forth dictionary after they are compiled but when working with source it is very useful to be able to search all sources for all definitions of a given word or all places where it is used or to search for where literal numbers are used anywhere in any source. These things are easy, simple, trival and fast when Forth can do more at edit time. For many people these things are so difficult that they don't do them at all and don't even know what they are missing. One might say that a side effect of being forced to use ASCII files as containers for source are that you don't have a lot of useful and powerful forth tools to make the work easier.

I showed how Pentium colorforth displays the numeric value of a word as it is being typed in to the command line before it is executed. I also showed how it displays what is on the stack on the left side of the command line. If you start with nothing on the stack and type "DROP DROP DROP" then enter "1 2 3 4" you will see that you have a "4" on the stack. You have the word "C" to clear the data stack and set the stack pointer to its default value.

The target colorforth offers the word "unext" which works like NEXT but branches back to slot-0 of the same instruction word in which it runs. It discards any address argument provided by FOR or BEGIN so that it can use the same syntax as NEXT. Instead of a five nanosecond memory operation like NEXT it is a two nanosecond operation so one can adjust the timing of loop timed by unext in two nanosecond intervals. A no-operation or "nop" instruction is specified with a period. Since it is in the stack or alu class of instruction it executes in about one and a half nanoseconds. So with two nanosecond changes and one and half nanosecond changes one can tweak timed operations to about half a nanosecond. Pentium colorforth does not have the equivalent of a unext operation but perhaps it could be added by using a repeat-previous instruction and count down instruction.

In addition to the simple bit-bang pin-toggle loop examples shown the use of I/O and math rouintes in ROM were shown. One can use ROM code to read from the SPI flash, read synchronous, asynchronous, or one-wire asynchronous signals. Other ROM code includes multiplies, fractional math, left and right shifts, triangle trigonometry, polynomial approximation, taps for fir and iir filters, table interpolation, pwm output and more. The software simulator compiles the ROM code along with any user application code and provides a way to get hands-on exerience with using these ROM functions and see some well coded examples of machineForth. With very limited on-chip RAM on each node it is important to understand what the ROM code offers to let programs in RAM be smaller and do more.

At the end of my presentation I ran a little program that fit on one node that copied itself in two dimenstions and carried a bitmap with 144 pixels. On each node it would then index into the two dimensional bitmap and decide if it should stay on or go to sleep and in doing so leave a pixel on or off in the softsim display. I just wanted to see I could write that fairly quickly and get it to fit on single node. I joked that I wanted to show Forth on the simulated chip.

At the end of Chuck's Fireside Chat I presented him with a framed wafer of Forth chips to go on his home or office wall. I has about five thousand clusters of twenty-four Forth processors or about one hundred and twenty thousand Forth processors on one piece of silicon. With thirty-two, forty, or one hundred and forty-four processors per cluster the number of clusters goes down but the total number of processors on each wafer goes up. Ideally if one wanted to use wafer scale chips one would want surface mount flip-chip pads for I/O and if there were clusters they should be connected to one another on-chip using parallel connections like inside of clusters.

SVFIG will put videos of all the presentations on their site at some time in the future.

There are few topics where people make arguments from a position where logic will be of little help. On these topics dialog usually can't go anywhere but to name calling or hate speech. When in a discussion what does one say to a comment like the one made by Christine O'Donnell, "You know what, evolution is a myth. Why aren't monkeys still evolving into humans?" Richard Dawkins said, "spectarularly stupid" but that doesn't forward dialog.

One of those topics is Chuck Moore's colorforth. I understand it is different, very different than the things in computer science that you know or that you do every day. It is natural that you might have no interest or want to deal with something so alien to you.

It is natural that there are people who use a different language than you, you would be an alien in their community. They might look differently, have different tastes in food or style and different rules for proper social behavior. Dealing with an intense exposure to such alien culture is difficult for many people but a bigger part of the modern world. Still most people never do get much exposure to the real details of other cultures.

In any situation the dominant culture will get most of the exposure, this is sort of the definition of a dominant culture. You can't avoid exposure to the dominate culture and it is easy for everyone for the most part to see the parts of it that they are suppose to see as that is part of the culture as well as not see things that they are not suppose to see. Part of culture is to see things the way the culture says they should be seen. That is always part of the culture.

It is easier to understand when a minority culture hates a majority culture that wants them to maintain a low profile or assimalte until they are not a minority culture. Still minorty cultures for the most part don't hate. Most to the hate is a consequence of how some people of the people respond to and focus on the hateful chatacterization of the minority culture.

A minority is likely to have a strong cultural indentiy but also see itself as a part of the larger dominant culture. The dominant culture on the other hand may consider minority culture as alien and not really part of their culture.

But if you are part of a minority culture where almost everything is about the dominant culture there are some special problems that you will have. Your culture can't get the exposure that really define it because what is exposed to everyone is the dominant culture. Often people in a minority culture have a serious concern that the little exposure their culture gets in the dominant culture does not represent them well, has to be limited by definition, and may be represented only in hateful caricature.

People who want to deal with the problems of the a majority culture treating their minority culture badly because the only exposure their culture is given is hateful caricature have some special problems. If you say that a solution is for the majority culture to get more exposure to the real details of the minority culture this goes against the very tennants of the majority culture and the counter argument will be that the minority culture needs more indoctrination and assimilation into the majority culture. This is the problem the minority culture needs to reduce but any attempt to get more exposure that a minority culture thinks represents them properly so that they can be treated fairly is likely to simply produce more hateful caricature of their culture.

If the dominant culture believes that the earth is six thousand years old and bases their world view on a group of facts associated with that fact a minority culture that has a world view based on history and science will have all the cultural problems that happen when a majority culture wants a minority culture to assimalate and blend in. They have lots of proof that ideas like evolution are wrong. Monkeys don't change to humans at the zoo.

What can you say when that is the dominant culture? Promoting science instead of God may be seen as a very bad thing and characterized in a hateful way. If a minority group makes any effort to get the majority culture to address the problem they see through education the response they are likely to get is that there is a problem to be addressed in the educational system that led to an assualt on God and that the clear solution is to get the science out of the educational system and replace it with scripture instead.

My use of the word "God" may make the argument seem very culturally specific and will most likely cause some readers to feel insulted or that their own culture has been assaulted. I appologize for hurting anyones feelings and wish them no harm. I ask anyone who feels any of that to go back and reread the last paragraph but substitute the best words for you to be the opposite of the words "God" "science" "scripture" "education" and reread the paragraph.

For a Christian person who might have felt the tiniest bit of resentment or disagreement with that paragraph they should picture if they were living in a dominanlty Muslim culture based on whatever exposure they have had to whatever they think that culture is like.

Promoting Christianity instead of Islam may be seen as a very bad thing and characterized in a hateful way. If a minority group makes any effort to get the majority culture to address the problem they see through education the response they are likely to get is that there is a problem to be addressed in the educational system that led to an assualt on Islam and that the clear solution is to get all exposure to Christianity out of the educational system and replace it with scripture in instead.

Perhaps you can't relate to either of these cases and want a rather odd variation. I have been doing almost all of my computer programming in the Forth language for the last twenty-five years. Any language creates cultural boundries. I live in a world where there is a dominat programming culture. People cannot avoid exposure to it. They cannnot help but seeing it and all the books all the classes in the educational system are about it. Most of the blogs and websites and discussions are about it.

So I belong to a minority culture where we get very little exposure and the little we do get is mostly hateful caricature. And this hateful caricature is the only exposure in the educational system or the business or hobby computing culture as well. Having said that I am willing to repeat what is common knowledge and suppose to be taught about the minority culture of Forth.

Forth isn't really a programming language at all, it is a religion. Forth is a write only language. Forth's very limited value was only in the past on very small machines. Forth had some value thirty years ago but then C won and Forth died. Forth is a joke. Forth is a cult. There has never been a single decent program in Forth. Forth stinks.

Those are all statements taken from popular magazine articles and columns or that appear again and again in blogs and newsgroup discussions. They are the things the dominant culture say about us and teaches about us. Part of the culture is that this is what people are suppose to say about Forth.

These things seem like hateful caricatures to me. but don't seem out of place in the view of the dominant culture. Every one of those statements are as wrong as they could be and are meant to protect one culture from mixing with another, understanding, or being understood by another.

The problem is no different than the same problem of a minority culture in a majority culture in many other contexts. If you try to address the problem that you think this is an untrue and unfair if not hateful representation of your community and that it just encourages unfair or hateful treatment the effort is seen as an assault on the majority culture which requires that the amount of hateful caricature and dominant cultural indoctrination needs to be increased.

What can you say when the arguments presented are monumentally stupid and hateful? My response has usually been to go away and provide some explanations of what we really do, documentation, code walk throughs, tutorials, benchmarks, essays, interviews, transcripts, and videos that I think represent out culture accurately. Consider that the only exposure the dominate culture gives is that we are dead, religous extremists, or cultists. And in the dominant culture those are about the worst possible things that people can be.

But no matter what you do people argue that they went to wikipedia or google and everything said the same terrible stuff about what your subculture does. They don't want to listed to what we say we do.

You can't avoid exposure to the dominant culture. If you try to get what you think is the tiniest bit of accurate exposure to your minority culture no matter how small may be seen as a major assault on the majority culture that requires a major response. This is suppose to be less of a problem in the American "melting pot" culture. But as is always the case many things are supposee to be diluted until there is no longer any trace of taste of them in the mix because they are just too alien to be accepted within the majority culture.

When the minority culture wants to get what they think is a little fair exposure so that they can be treated fairly rather than in some hateful way the response is likely to be that they need to go away and get more indoctrination into the majority culture until it is no longer a problem. When I try to tell people what it is that I and other Forth programmers around me actually I the dominant culture requires that many more examples of a hateful caricature be produced in response.

What's ironic is that a dominant culture is required to provide more examples of their view a minority culture than that minority culture is suppose to provide of themselves. In the case of my programming culture one of the favorite facts used to prove that the only characturizations that are correct about us are the ones most easily available. In fact there simply is no and had never been any information available to learn anything about Forth at school, at the bookstore, or on the Internet than what the dominant culture provides. And I quoted from that previously.

But as I said before often when confronted by a number of people who all felt that the only characturization that should be provided of what I do or what I and people around me have done should be the sort of thing I quoted above from magazine columns about Forth.

I have told people that there was a lot of actual information about what we really do or really did that got put out in front of the public. Most of what is out there and easy to find if from the C programming culture and which we do not thing characturizes us fairly or accurately. And though much less than the information available about the dominant C language computing culture we have actually put a lot of information out there so that anyone who want to actually understand what it is that we really do can do so.

When people have made it clear that their only exposure to what we do or have done has been hateful caricature I have tried to direct them to the things we have made public about what we were doing. Here is a short history of information we thought characterized what we do and did.

Things from the 80s: cmForth the public domain 6k optimizing native code metacompiler for Novix. Dr. Ting's Footsteps in an Empty Valley. The first dozen issues of More on Forth Engines. Documentation from Novix and Harris. The cmForth port to RTX. The development of the 32-bit 100MHz Shboom. The development of machineForth. Papers on a number of forms of parallel Forth. Presentations on the start of VLSI CAD tool development in Forth. ANS Forth started and was offered details of machineForth for consideration. The ShBoom manual.

Things from the 90s: Chuck's presentations on okad, MuP21, machineForth systems. Full machineForth systems. A megabyte of html describing ANS systems written in machineForth. Dr. Ting and Chuck's VLSI Hacker's Forth toolkit. The OK386 manual. FORML presentations on the evolution of machineForth and the introductions of parallel programming with benchmarks. Presentations on how to program GUI accelerators on Forth chips. ANS Forth finished. Presentations and write up of various applications. The documentation on iTV's 4OS and I21 chip, web browser, email, web host, and dozen web protocols. Forth Linda. Forth DSM. F*F. Dr. Montvelishsky's example of CSP in Forth similar to Occam semantics as a learning tool that runs on a PC using Forth multitasking to learn parallel programming. Dr. Montvelishsky's cordic and math functions in machine Forth that were 50 times faster than Intel's versions at the time. Explanations of colorforth. John Rible publishes college classroom designs and give classes in designing processors with examples from a tiny-RISC and a Forth designs in VHDL. The design class videos and transcripts are made available to the public. Twenty more issues of More on Forth Engines. Dr. Ting puts some VHDL Forth chip designs into the public domain. The nine gigabytes of video presentations and html transcripts hosted at the UltraTechnology site. The workstation in a mouse project.

Things from 2000: Chuck's presentations on 25x. Presentations on how aha worked. More issues of More on Forth Engines. How the public release of the stand-alone colorforth came about. How this version of colorforth worked. Presentations on how OKAD 2 works. Gigabytes of videos of presentations and programming tutorials hosted at UltraTechnology on programming of MISC. Dr. Ting publishes new manuals and presentations on his P16, P24, P24X, P32, and P64 processor designs. Chuck creates his colorforth web site. I add a blog. Presentations about early work at Async Array Devices and how it became IntellaSys. Explanation of the use of various CAD software. Presentations on new features in machineForth and hardware to improve application performance. Presentations on programming in colorforth and VentureForth. Presentations by a dozen Intellasys employees. Explanations and code reviews for a dozen applications and tutorials. Many details of many projects presented to SVFIG or EuroForth or through the IntellaSys website or UltraTechnology. Presentations of Forth soft radio are given. Reports on expensive comparisons between OKAD and convention tools were given. IntellaSys releases VentureForth with compiler, simulator, visualization tools, and a drag and drop framework. SEAforth24 and SEAForth40 designs are provided with detailed manuals. Presentations on ROM code details with lots of examples and code explanations for SPI packet boot, asynchronous autobaud packet boot, syncrhonous autobaud packet boot, 1-wire packet boot, external memory interfaces, analog I/O, interprocess communications, forward and reverse port pumps, math routines, message routing, and Forthlets are given. Methods and example of data-flow analysis and data-flow algebra are given. Arrangements are made for FIG to get free or discount chips from the first IntellaSys wafers. The hearing enhancement project and stereo vision projects are presented. IntellaSys does wafer production runs and describes the details. Explanations for what should happen when IntellaSys went away were given.

Things from 2010: Dr. Ting puts more chip designs into the public domain. Chuck adds a blog. Green arrays forms and gives several presentations. Many code examples are shown again but in improved forms. Green Array Chips GA4, GA32, GA40, and GA144 multi-core parallel Forth chip design documenation is provided. Demonstrations of colorforth softsim and IDE are given. A comparison of the performance of various modern Forth compilers on specific compiling examples and an OKAD like applicaiton are presented and published. More presentations to be provided by various people at the 2010 Silicon Valley Forth Interest Group Forth Day event.

Lots of the stuff I found interesting was never public information and I probably forgot some important things that were made public. In hindsight I think UltraTechnology was far too open and honest about what it was doing. The idea of $5 educational networked Personal Computers with workstation performance that could download Forth programs embeded in video broadcasts and mix input video with computer generated video was seen as an assualt on the dominant culture. It seemed that I had not appreciated the cultural acceptance of the digital divide. But people in some governments and militaries were watching closely and didn't need us to be so public to show interest and follow through. The competition was watching as was in the parking lot at ITV taking pictures of our meetings so they didn't need so much public information either. There were people breaking in and trying to break in to servers to learn about what we were doing. There was interest out there. But the way we are depicted in the dominant popular culture is quite different than what we say about what we were doing.

In retrospect I have wasted too much time trying to use logic to help the Forth haters understand what we do or correct the misreprentation by the competition. But there is that univeral cultural problem to deal with. Better I think to just ignore the haters and people with the spectacularly stupid arguments. Trying to deal directly with them is a waste of time. Now if I can just follow my own advice. It is probably better to just go off and work on some code, documentation, or on the next presentation.

I am suppose to present for the Silicon Valley Forth Interest Group again in a couple of weeks. It is fun to see old friends and hear about what other people are actually doing with Forth. I no longer bother to make videos, write transcriplts, and post it all on my site. But SVFIG does make and post videos of Forth Day presentations so there is more information available to more people about what this minority culture is really about and really like.

What's funny is that as soon as we step outside of a culture that understands the sort of Forth word we do we find people who react like they have heard we have been pursuading people to send us all their money and begin worshiping the devil.

To be honest I don't care whether you would want to do the kind of work we do or not. It would just be nice if the dominant culture could be a little gracious and provide us with an occasional opporutinity to say something about what we do without some group from the dominant culture needing to put on hoods. If they were just willing to let us provide a little description of what we that we think is accurate and fair without feeling a need to provide more counter characterization of what we do to defend and promote the dominant culture.

It used to amaze me that you could give someone the foor for hours to explain how the dominant culture sees software, something you cannot help getting exposed to anyway, at a Forth Interest Group meeting but when the inventor of Forth takes the floor for one hour in the year and begins to explain what he does in a way that he thinks is fair that the previous speaker could interrupt him preventing him from talking to shout things like, "That's not the way a C programmer would approach that ...."

What amazed me was that dominant culture was not willing to give up the floor for even an hour a year in a small group of people gathered to hear about Forth without bringing things to a hault because we obviously needed more indoctrination into the view of the dominant culture and be told again that that is not how C programmers see things. It seemed inappropriate to me but part of the dominant culture is that you are not suppose to see that as inappropariate. It is the responsibility of the dominant culture to indoctrinate minority cultures and get them to assimalate into the dominanat culture. Ok. You can gather to disucuss Forth once a year, but the floor must be given to indoctrination in C instead of Forth lest it get out of hand. But I do understand that this is just a univeral aspect of culture.

Newsgroups and chatrooms have the same problem of course. Discussions of Forth are allowed as long most discussions are about writing C or Perl or Java or MD5 or shells or using operating systems written in C or editors written in anything but Forth or topics where they never even mention Forth. It is the responsibility of the dominant culture to keep things fair and balanced.

Discussions about things like colorforth will solicit demands that you go out and use other languages instead. You don't want to use that, I don't want to stop using myForth. I don't want our customers to stop using ourForth. I don't want to stop using C. I don't want to stop using Perl and Lua. Stop doing that. Go out and learn Perl instead. Go out and learn C instead. No one should do that. Go out and learn Haskell instead. Go out and learn Python instead.

When the subject that some people do colorforth or different ideas comes up some people get very intolerant and don't think people should even be exposed to something that alien. So even if it only gets discussed once a year and Chuck Moore gives a presentation where it will come up then some people will be rather intolerant of letting people who know about the subject described it without the majority of people each giving a more dominant culture point of view and to limit how much minority information will be tolerated. But again it is just a case that dominant culture cannot have very much tolerance towards minority cultural views getting exposure. Cultural stereotypes make things simpler and it is the responsibility of the dominant culture to make sure that its point of view always gets to dominate.

I gave a short presentation today for the Silicon Valley ForthInterest Group. I said that there were several projects I could give presentations on including reporting on couple cute pieces of equipment I could review. I had wanted to look into doing some USB client code. I started by reading about USB and then got a couple devices to help me explore the problem.

I have a tiny litte Beagle Board USB analyzer. It has three USB ports. One you connect to your PC as the user interace and then is has two other ports you put between a USb host and USB client. It provides different views of USB messages at a sort of high level. I also got a tiny logic analyzer that has one chip with a USB connection on one side and 17 aligator clips on the other, one ground and 16 probes. It can capture a meg or so at up up to 16 or 24MHz. With these views I was able to see more about what was going on with USB.

My first analysis suggested that I should implement low level code first to handle resets, bits and packets. I wanted to try to get that on one node in under 64 words of code. The higher level protocol could then be handled by more nodes with access to flash memory to be able to deal with the larger amount of detail at the protocol level. I got the low level stuff mostly working but found the overly simple hardware interace I had set up produced glitches when I switched from bit read to bit right. I got some help from a hardware engineer on what should be a better external hardware connection to USB. Because I had a voltage level converter circuit in the simple design I did the signals looked good on one side of the converter but not the other. I will go back and do more work on it sometime.

I found some cute hardware; RSDV HS MMC. Those are reduced-size dual-voltage High-Speed Multi-Media cards. They work at 1.8v or 3.3v. They are about half the size of a regular MMC. They support SPI at 25MHz. The high-speed ones also have a mode where they use an eight bit data bus instead of a single pin. They can run up to 52MHz and 416MBPS. I want to hook one up in SPI mode so I can have removable flash, usable on a PC also, with gigabyte capacity. I also want to find out whether I can put several of them on a Green Array Chips external parallel bus and drive control signals on them in parallel. It could be used as a very raid solid state hard disk with very high performance. The literature also says that they can be written and erased very quickly for flash devices. I haven't done much with that project yet either.

I showed them the Green Array Chips public colorforth release that has the target compiler and softsim program. I showed them the user interface and a couple of programs that made an interesting visual displays on the interface as you saw the interaction of the 144 core running, communicating, and sleeping. Someone asked about how it worked as both a stand-along boot program and OS on some PC and also ran on Windows on a much wider range of machines and what it put on a PC when you installed it. I mentioned that Green Array Chips had short videos showing how to download and install it and what you got. We also started with some simple stuff showing the user interface, editor and softsim to help people get started.

I showed a version of colorforth with the Interactive Development Environment. I always change my ideas about what to show after I watch other people's presentations. So I pointed out how the softsim interace and the IDE both do the same sorts of things we saw in other presentations. They provide ways to see what is on the stacks and in memory. In softsim you can move a 4x8 node window around to see the most important registers in each of those processors in another area of the display, how the disassembly window worked and could be moved around and how you single step or go or control how many steps are taken before each update of the visual display.

I has showed the IDE before and said it would not doubt be shown again before people got real chips or chips on development boards and wanted to try the IDE on them. There was question or two about the internals, not on the PC but on the target chip and I showed how it set up a path for messages to go from an entry point on the chip accross other processors by executing code on their ports copying messages from one port to another. That way they don't effect the memories or most of the stacks on the nodes that help when you talk to a given node and deal with its stacks and memory in an interactive fashion.

I mentioned that Green Array Chips had been taking orders and the current retail price is $10 for 144 processors or just under 7 cents per computer in the cluster. That also works out to a maximum code execution rate of better than one hundred Forth MIPS per cent of retail cost.

I also mentioned the $1.99 Linux computers that had been mentioned in the SVFIG mail list. These are odd machines. The only I/O they have is USB. If you plug them into a computer with USB but that doesn't boot from a USB port they are just treated as USB Flash sticks. $1.99 USB Flash sticks are not anything too special. In fact there were both $1.99 and $2.99 models where from what I gathered from a brief exposure is that the $1.99 sticks don't have much Flash memory, 64MB or something. But if you plug them into a PC with USB BOOT and boot them up it boots up a Linux system running on the stick and using the PC as a peripheral mostly. The Linux on the stick lets you read/write the PC's hard disk, keyboard, mouse, and screen. It comes with a bunch of tools including a browser and a version of Lua all running on the computer controlling your PC, the USB computer on a stick.

The whole idea seemed similar to John Harbold's presentation on porting gforth to ECOS under a Linux from a USB flash stick. His presentation was about stuff I know next to nothing about. I hadn't tried any of these Linux Computers on a stick as I had been very busy recently. But I brought a box of them into the FIG meeting and gave them away to people who wanted to play with them. Maybe someone will give a report on what they did with them. Maybe someone will port gForth or some other Forth.

I also wanted to see if you could bypass the Windows security, short of encryped files on a PC with USB Boot. Since the idea is that when you boot in Linux on the stick the hard disk on the PC is just a peripheral to your system and you don't have to go through any password security to boot Windows on the machine. So it might be useful to rescue PCs with health problems or with forgotten passwords. Some people know a lot about Windows and Linux and might make good use of these $1.99 Linux computers.

I also did a very fast review of benchmarks I had done to test the performance of Modern Forth Compilers. I explained what I had tested and why and showed the results very quickly. There were some questions about why the results looked like they did.

I said that 353 posts to usenet thread about dictionary hashing options in Forth showed me that many people were interested in how Forth compiler performance could be improved. The reason that so many of the popular modern Forth compilers used hash functions in dictionary searches was to improve their performance.

Before I began a very brief presentation on benchmarking some modern Forth compilers I said,"First let me say that there is not just one way of doing Forth properly. For instance in Dr. Ting's presentation today on eForth for his custom 32-bit processor it is very hard for me to picture any more efficient way to make all the processors he has and test and debug both new hardware and software than the way he described of using eForth.

I said I had been told that modern Forth compilers no longer used the forty year old Forth compiler loop. I will still have to ask again about that on usenet since I still think that most still do use that forty year old loop. I know colorforth and aha don't but that's not most modern Forth compilers.

The loop I was talking about is the one described on page 28 of the Forth Programmer's Handbook. That pages shows the whole classic Interpret/Compile loop used for the last forty years by most Forth and I had been talking about its compile loop in compile mode.

Parse source for the next Forth word.

Search the dictionary for that word.

If found check if it is immediate.

If immediate execute it.

If not-immediate compile it.

If not found in the dictionary try to interpret it as a number in the current number base.

If it is a number compile it as a literal.

If it not a number it is an error.

I am pretty sure that that is still how most Forth compilers work. I realize that the phrase "compile it" has different technical meanings depending on the type of threading or code optimizer the compiler uses. Most modern Forth use subrouinte threading with inlined native code and other native code optimzation but we still use the term compile a Forth word and even have an ANS word to make the meaning portable COMPILE, (compile-comma).

I was told that I was out-of-touch with Modern Forth compilers because I questioned that all compiles take place before you can take your finger off the return key, meet some new 1/4-second compile rule, or are all *instantaneous* as my experience is that they are not like that. Maybe if you are just still doing 1980 sized applications in Forth on your 2010 PC you find your compiles are faster than mine. But to me whatever the term Modern Forth is suppose to mean it should mean something today other than still compiling nothing larger than what we did on the Apple II in 1980.

To see just how out-of-touch I ran some benchmarks against a dozen Forth that I have seen advocated on usenet in the recent past. I downloaded them from the Internet, installed them, ran a few benchmarks, and put the results on a web page.

The people at SVFIG agreed that because Forth applications may make extensive use of the Forth compiler in that compiler performance itself was important there. The 353 usenet posts to the thread "What are my options for dictionary hashing?" in comp.lang.forth this month showed how many people there are concerned about getting good compiler dictionary search performance and fast compilation.

I was pleased to see that when I installed a version of Win32Forth on my machine that it had a Forth kernel compile the rest of the Windows Forth system. I had no expectations that its compilation was going to *instantaneous* as claimed for some Forth systems. Nor did I expect it to meet the new mythical 1/4-second compile time rule claimed for some Forth systems. It wasn't and didn't.

At least in that sense I wasn't too out-of-touch with modern Forth compilers as has been said on usenet. People often claim that Forth compilers are small compared to many other things so compiling one should be a lot faster than a serious modern application. On my 2GHz PC it only took 16 seconds.

You have to very slow hands to not be able to get your finger off the Enter key before the compiler is finished as is claimed for other Forth systems. 16 seconds may not be a long time to compile a fairly small and modest application but it surely is not instantaneous, faster than a single keystroke, or even close to the mythical 1/4-second compile rule. In fact it was sort of what I was expecting given how long it took ten years ago.

Maybe I was a little out-of-touch with modern Forth compilers and their performance at what they do. I wasn't expecting all the results I got. Some things were faster than I expected and some were slower.

I wasn't too surprised that the portable Forth written in "C" was one of the slowest but not the slowest thing I tested. I was a bit surprised that some of the Forth I tested and see advocated so often were a hundred or a thousand times slower than others.

I only downloaded, installed, and benchmarked systems I had seen being advocated on usenet within the recent past. I wanted to be objective and not make any value judgements before or durring testing. But I was only willing to spend an hour or so downloading and installing each system. I included eleven systems in the less demanding tests.

If your Forth system is there and I was not able to download it and get anything to run on it please forgive me. If your Forth system made it into the test then good for you. If you are not happy with the results your Forth system got in the benchmarks then it is up to you to make it better and it is not my fault. All I did was look, measure, and report.

One result of all this was that it made me want to rethink aha and work on an aha 2. I didn't include aha in the main benchmarks because they were all run on the PC I am using now. It has a 2GHz AMD Turion64 processor and aha just runs on F21 with 7 to 25 MHz DRAM and 50MHz SRAM so it isn't really fair to make it run in a race against the 2GHz class of machine. I did include it anyway in a couple of extra lists to show that the approach does have promise for improving compiler performance.

For the last decade the modern PC Forth I have used at work are colorforth and SwiftForth from Forth Inc. and I have used them for different purposes so I have never bothered to do any performance comparisons even on those. I wrote the original VentureForth system for target compiling to IntellaSys chips from a PC and it was run under SwiftForth, gForth, and VFX Forth but was not a compiler for the PC itself. I worked with aha but it was only for the F21.

I suppose I had listened to some estimates that people in comp.lang.forth had given for the various PC Forth system's comparative performance levels but had not ever tested anything or even seen any actual tests that anyone else had ever made. And it turns out that I was a little out-of-touch with the performance of Modern Forth Compilers for my PC. My guess is that you probably are too.

You were not as out-of-touch as me if you can look at the benchmark results and say, "That is exactly what I would have expected." All I could say was that it was sort of what I expected. The exact results and order of the participants on all three tests did surprise me.

I was asked how aha achieved 0.000101 nanoseconds per ASCII character in the comment character per second compile test. I explained that the aha editor puts a tag on comments like other variations of colorforth but does use the Shannon-encoded characters like Chuck's Pentium colorforth. I explained that ANS demoted the use of counted strings because they wanted to reduce conflicts between code that uses a count and address on the stack and code that uses an address that points to the count of a counted string. I explained that I promoted counted everything, not just strings, in aha and the forthlets designed for VentureForth. The counting happens in the editor where it should.

In the big comment benchmark all aha had to do was read the comment tag from the DRAM source, execute a few instructions in fast SRAM to know it is a counted comment. Then it just reads the count, adds it the pointer and it past the big comment field in 202ns regardless of how many characters there are up to the limit of the memory size of the computer. I had only packed two ASCII characters per word so advancing the pointer past one million words of comments was two million characters in 202ns or 0.000101ns per ASCII character. People who didn't with CAD were not used to using picoseconds or femtoseconds. I said, "Yes that's 101 femtoseconds per ASCII character.

Aha does lots of stuff like that. It doesn't work like Forth that follow the forty year old compile loop described in Elizabeth Rather's book. Being able to compile Forth words to executable object code at a maximum rate of about 250 million source words per second on a $1 chip is also a little hard for people who haven't studied it or understand that at times compiling four source words into four executable words in memory takes one memory store.

You might find the rational for the tests and the results of the Modern Forth Compiler Benchmark tests interesting. The web page is Modern Forth Compiler Bencharks.

this is a test this is a test I saw a link to a very nice toy recently. Its related to my life outside of Forth and programming.

There are two web pages about it in French with some wonderful pictures of it and some bigger more expensive toys. If you don't speak French you can get the pages translated using the web.

I had some trouble distinguishing it from the full sized version in some of the photographs. You really have to look closely.

You can see more great photos and read about it at Les Grands Planeurs Rc and Stemme S10-VT de Grard BON...

Some related pages include Martin Hellman's Links to Soaring Photos, a very nice YouTube video of Garret Willat from Sky Sailing in Soutern California, and a great story about an adventure of the late Thierry Thys Spine of the Americas soaring adventure of a lifetime

Oh! I have slipped the surly bonds of Earth

And danced the skies on laughter-silvered wings;

Early this month I was directed to check out a blog entry about Yossi Kreinin's experiences with Forth. I found it interesting.

My-history-with-forth-stack-machines on the blog "Proper Fixation (a substitute for anaesthesia)"

I found it quoted me in several sections. The first two quotes I was happy with. Yes I have said that there is a difference between pros and Joes. There is difference. Joes usually want to play and results don't matter much. Joes may be happy to show others just how bad their code is.

Joes may want to learn or just have fun and are likely to do that no matter what they do. Often they want to write their own Forth but have no real reason to do so, no plans for what to do with it, nor any use for it in the future. Pros usually have a goal of doing something that has never been done before and they try to do the best job they can. Their job itself is likely to depend on how good of a job they do.

I tend to have a lot of opinions, more than I am comfortable with at times so I like to try to consider other pointes of view. But one of the things I have trouble understanding is when people say that they want to do Forth and then sit down to write code in "C" or something other than Forth instead. When then finish writing code in "C" they may feel that they have been doing Forth and show other "C" programmers how Forth is about writing code in "C".

What is Forth? Among other things it is compiler. I ran some benchmarks recently on a number of popular modern Forth compilers on my PC. The Forth mentioned in the article was one of them, pForth. I think the "p" is for "portable" like another older Forth in "C", PFE the Portable Forth Environment. (maybe instead the letter P in pForth stands for Paul.)

Forth has always been the most portable and easy to port language going back to the days when it was almost always the first language implemented on every new computer design. But here the term is being used in the sense that many "C" programmers think that "C" defines portability when they focus on the narrow range of machines where "C" is used. By numbers most computers are too small for "C" to make sense. On some machines "C" does offer some degree of portability.

But I wince a bit when I see people promoting a Forth written in "C" when the performance of the system is only about one percent of the performance of Forth written in Forth. Chuck Moore has said many times that good Forth code should be about one hundred times smaller than "C" code. That upsets many "C" programmers. I found it interesting that in every benchmark I had recently done that pForth was almost exactly one hundred times slower than the Forth I use.

We already know that many "C" programmers really don't like Forth at all and many Forth programmers don't like "C" at all. As Chuck always said when you show people Forth a quarter will love it, a quarter will hate it, and half will be indifferent. The ones who hate Forth often have experience with things like "C". Forth and "C" are sort of natural enemies because compete for jobs on the larger embedded systems.

I have even heard people say that they like Forth because it is good as a simple debugger to help them debug their buggy "C" code. While true it is usually a statement that the person only likes 1% of Forth but doesn't know, denies, or doesn't think much of the rest of it. If that is the only good thing they can say about it then I think they hate Forth. It makes me think of a quotation.

" There's nothing I like less than bad arguments for a view that I hold dear." Daniel Dennett

When someone evaluates Forth by looking at something written in "C" because the author knew "C" instead of Forth I wince. When they then show it to others I wince again. I think they are not giving Forth a fair chance at all.

If you show them an awful "C" compiler written in Forth they will tell you it is because Forth is awful. If you show them an awful Forth written in "C" they will tell you it is because Forth is awful. And many people take the 1% performance Forth stuff seriously.

Here we have someone who jumps into Forth, right into the "C", gives it a brief look and writes that he "sort of understood it." Then he showed "C" code. He sort of got it too. That sort of thing usully takes about fifteen minutes.

He then quotes my comments about how professional Forth programmers and hobbiest who write Forth systems for fun don't have much in common. He seemed to get my point too that dead frogs stink.

But he says, "Ouch. Quite an assault not just on a fraction of a particular community, but on language geeks in general."

I hardly considered asking people to consider the nature of what they want to do in the name of Forth an assault. I have written things that were an assault on language geeks in general but that was hardly it. I say that it is not just language geeks but modern society as a whole where the emphasis on language has seriously diminished people's other mental and physical abilities. There are a lot of things that are very much like texting while driving. I just hope it doesn't kill you, your friends, or your family.

I don't mind people using 1% performance Forth, of using 1% Forth, or using Forth only 1% of the time. I only object when they tell others that it is the best Forth can do.

I have written a lot on my history of working with Chuck Moore on the design and programming of a half dozen generations of Forth hardware and a hundred different approaches to Forth software. Look at Chuck's history. He invented Forth and then learned what worked and what didn't by using it exclusively for programming for twenty years. After mastering Forth he declared that, "The software problem is solved." He felt that the problem that remained was that hardware was still inefficient and could be difficult to program. So he set out to take Forth beyond just software into hardware design. He wanted hardware to be Forth software also.

Only after twenty years of full time practice and of mastering Forth software was he prepared to attack the problem of designing hardware in software. In his first two efforts he didn't do it in Forth softwre but used the same conventional tools other programmers used. He was not happy with the ugly, inefficient, difficult to use, black box CAD software that had to be used. He wanted control and to understand everything he was doing. He wanted source to all the tools.

It didn't happen overnight. It was quite a problem to solve. The early days when the National Security Agency released the CMOS component library description to the public. when Chuck was learning from it, and when Dr. Ting wrote the Forth VLSI Hacker's Toolkit were very intersting times indeed.

Most hardware experts denied any knowledge of what their CAD software was actually doing beneith the hood. They had the same attitude as many programmers have, their tools are smarter than they are and they just have to blindly trust in them because there is no hope of them every understanding what they are actually doing.

When Chuck found CAD experts and people who had written CAD code they would almost always say that they could answer questions about 1% of anything because that was the most they knew. The other 99% was a black box that they had to blindly trust. Forth programmers prefer understanding to black boxes and have learned not to rely on blind trust.

After each few years and each generation of new Forth chip designs Forth software evolved too. To quote Marshal McLuhan, "It is a loop. We make out tools and then our tools make us."

But seriously, how can someone design a good Forth CPU without first having written lots of applications in Forth, and profiled their intended applications to know what this processor is going to need to do? Since a person can sort of get Forth in fifteen minutes they can jump into this loop wherever they want but will they have unrealist expectations?

Learning most things requires work step by step, stage by stage under the guidance of good teacher or better yet a master of the art. When people don't do that they tend to just perfect their bad habits. If they don't do their homework in the first place to get a strong foundation then they are likely to be building on soft sand.

The author of the blog wrote, "I defined the instruction set in a couple of hours."

I had ten years of experience programming in Forth and then I spent five more years working with Chuck testing software against possible design variations before we arrived at the F21 instruction set. Maybe I am just slow or Yossi is just that much smarter than I to get his results so fast. This chip's instruction set was designed in a couple of hours by someone with no previous background in Forth programming? He even admitted that he didn't even bother with homework like reading the excellent but twenty three year old book textbook on the subject by Dr. Koopman, "Stack Computers: the new Wave."

The author says he assumes that knowledgable people would have sneered at his machine. I wouldn't have had it been done as a learning project by a ten year old who had done his homework. But this was suppose to be professional quality Forth work. He was being paid. People were counting on him to do a good job and he jumped in with no experience, doing no homework, and designed the instruction set in a couple of hours?

Next the author showed his ability at writing in Forth by leaving Forth behind from the start. He wrote, "The first thing I did was write a Forth cross-compiler for the machine - a 700-line C++ file (and for reasons unknown, the slowest-compiling C++ code that I had ever seen)."

He didn't just leave Forth behind. He says he intentionally left out all the examples that drove him to drove him to Forth in the first place. He said he had no WORD, no COMPILE, no IMMEDIATE, no CREATE/DOES>, no nothing. He did just colon definitions, RPN syntax, and flow control words. One might think he was telling a joke not describing professional software development.

Then I looked at some of the Forth code he had written. Again I winced as it looked like someone who sort of got a percent or two of Forth.

Programmers without experience in Forth often have trouble with the whole notion of stack code at first. They are told that after a while it becomes like riding a bicycle, it is reflex and you keep your balance unconsciously while thinking about the problem being solved. They are told that it is quite natural and easy to do. This code looked more to me like a drunken sailor's first attempt to ride a unicycle blindfolded.

He quotes Chuck as saying that stacks are not popular where Chuck added that he didn't understand why they were not more popular.

Years ago I offered Chuck an explanation for that. I said, "Stacks are about the worst thing in "C" code. Their stacks are complex structures in memory. They are slower than memory itself. They are the source of all sorts of errors. They overflow. They underflow. They throw errors. They are a weak spot that malicious software and and viruses attack. They are completely different than stacks in Forth. When other programmers hear the term stack they think of the worst thing in the language they know."

I added, "It is easy to understand why what they call stacks in other languages are not popular and why Forth sounds so bad to them. To you stacks have come to mean something simple, fast, elegant and easy to program. You think of a stack as not being able to overflow, not being able to underflow, not being able to throw any errors. You think of stack as being many times faster than memory let alone stacks in memory! You think of stacks as faster than general purpose registers. You think of stacks as a mechanism to compress programs."

Look at F21 as an example. It has 2ns stack access and compare that to its 40ns to 140ns access to DRAM or its 18ns access to SRAM. We think of stacks as being smaller, cheaper, and faster than general purpose registers because that's what they are in our designs.

Consider how different stacks are in Forth and "C" by noting that the MuP21 had a total of ten cells in its two stacks. Chuck wrote that it was about the minimal size to allow one to write good Forth code. Compare that to the bug report I found in Bugzilla for GCC bugs. "C" programmers complained that there was bug in their compiler when you specified stack frames larger than 4 gigabytes!

It is hard to imagine a bigger difference in meaning for the same term, stack, than in the minds of those two types of programmers.

Then as if he wanted to prove Chuck's point the author said just the opposite thing as Chuck. He wondered why stacks were so popular at all.

Based on these exactly backwards ideas about Forth the author said that he began to miss a "C" compiler. Is there any wonder why?

He asked, "What does this say about Forth? Not much except that it isn't for me."

My answer to that question would be that it shows that no one likes Forth done in the worst possible way except programmers out to prove how bad it can be.

But in a sense he did seem to get a little of the problem he had. He wrote that a good Forth programmer would probably do everything differently. Indeed.

He quotes me again describing how Forth uses factoring of a problem to simplify it. In the example Chuck explained how other people use SPICE equations to solve three simultaneous differential equations in floating point to get a result to five decimal places that is actually only accurate to about 50% while Chuck carefully scaled his integer computation to get results that are actually accurate to several decimal places and by just doing a couple shifts and adds. But the author didn't get the lesson of fractional integer math at all.

When Chuck showed this line of code to someone he was asked how long it took him to write that line of code. He replied, "About fifteen years." He meant of course that only by making it better and better over and over again for fifteen years did it get to the point that it was as good as it was.

The blog author seemed to understand that he was really not doing quite the same thing as Chuck at all. He wrote, "This is Forth. Seriously. Forth is not the language. He wasn't as blind as many language geeks in that regard. He knew more than those who insist Forth is nothing more than a language syntax.

Then I found something where he quoted me again but didn't get my idea at all. I think he completely misrepresented what I had said. I had heard it before from Forth haters.

He said that according to Jeff Fox doing everything in-house was essentially a precondition to "doing Forth" at all.

What I have actually said is that if you are doing some percent of your work in something other than Forth then you are not spending that time doing Forth. Choosing to use Forth is a precondition to doing Forth.

We have heard all these same arguments before. "C" stacks are terrible so because Forth uses stacks it must be terrible. They can prove Forth is bad by showing us their Forth code. They would only consider Forth when it is in fact a "C" program that runs at 1% of the speed of Forth in Forth. They can write "C" programs in Forth but they are not as good as their "C" programs in "C". When they try (what they call) Forth they miss their "C" compiler.

I don't know why they say they miss their "C" compiler at all when they cling to it like a teddy-bear while claiming to be evaluting Forth. We have heard all that before. I have heard it many times. And I realize that these are the things that "C" programmers tell each other about Forth so they can sleep at night.

I tell the story about when Chuck gave his first public presentation on my chip, the F21. I was so happy that Chuck only talked about what he had done. Not once did he mention Intel, other CAD software or "C", not once! So when he finished I asked I guy I had never seen before what he thought of the presentation and he told me.

He said, "I hated it! He called me an idiot for using "C" all my life."

It is amazing how people people react when hear a factual account of what someone did with Forth. They questions assumptions they made in the past and often get very upset.

In comments and dialogs with other people at the end of the essay Yossi Kreinin said, "This is one of the pitfalls of integers - that they don't represent numbers less than one."

That's a perfect example of someone who has not yet grasped the basics of Forth programming or done any homework on its history. Scaled fractional integer math has always been one of Forth's strong points. He had even previously quoted an example of it and not realized it.

Chuck would often find himself at the opposite end of the computing philosphy spectrum from one well known "C" expert when Chuck started attending Silicon Valley Forth Interest Group Meetings. Chuck would be giving a presentation about his design work on small chips for Forth and say something like, "The best way to do this addition is with a very small adder that uses ripple carry. It is slower for large numbers than a bigger and more complex adder that would make the chip bigger and more expensive and power hungry. For small numbers the smaller adder is faster and thus you have the freedom to do add small numbers faster when you want to and all you have to do is add a nop before the add when you want to add large numbers. It is the best solution for this problem because it only adds a few dozen transistors to the design, lets the code run faster, and offers you more freedom."

Then Chuck would be interrupted by someone shouting, "The best way to do an add is to let the hardware convert the integers into floating point, do a floating point addition, then convert the numbers back to interger for you!"

The "best solution" to put an adder on a chip designed to cost a few cents and draw a few milliwatts is to add a few hundred million transistors so it will work like a Pentium? Someone needs to interrupt Chuck's presentations on the way small Forth chips are designed to tell him that?

It seems that a lot of programmers just don't get what Forth is all about or what small Forth chips are about. Desktop programmers today are so much the mainframe programmers when microprocessors were invented They don't undertand what the terms used in Forth mean because they assume that everything must be like "C" and on hardware designed to run their "C" code.

I found Yossi's blog to be an excellent example of many of the points I have made many times. I found it quite interesting read. Still I am sure my take on it is quite different than what most people will think of it.

01/22/10 Green Array Chips releases colorforth (native PC or Windows based) tools for its new GA4 and GA144 chips. Green Array Chips just released a couple versions of colorforth. These use the compression mechanism and have new color utilities and some of the code from okad2. One release contains the RAM/ROM/packet-compiler, software simulator, and IDE (Interactive Development Environment) for GA4 and the other for GA144. There is email help to get questions answered. I know some people have been waiting for a new colorforth release and others have been waiting for more information on the latest parallel Forth chips. The compilers and simulators and ide for the new chips should satisfy some people for a while. The last time I saw Chuck I mentioned that on my previous visit I had read a couple of chapters from a book I found on his bookshelf. The book was about Einstein and the chapter I read was about a dream that Einstein had that led him down the path toward General Relativity. I told Chuck that I had thought about the account of this dream and saw a parallel. In Einstein's dream he saw a herd of cows in a pasture where a farmer had installed an electric fence. He observed the cows as a group move up to the fence, touch it, get shocked, and all jump into the air at the same time. A little later in Einstein's dream he meets up with the farmer and mentions the cows and the electric fence. The farmer says that he just saw the herd of cows brush up against the fence and get shocked and one after another jump into the air in sequence. Einstein was puzzled by this in his dream because he had seen all the cows jump at once and he didn't want to argue with the farmer about the behavior of his cows. Later Einstein reasoned that from his position the electricity in the fence and the image of each cow being shocked was moving towards him at the same speed. Thus the image of all of the cows, each jumping at the same time was what he saw. The electricity was going one way and the image the other way for the farmer. He saw the same event that Einstein had seen as a sequence of jumping cows with the distance between the cows determining the electricity and light flight time between each witnessed cow jumping event. I said to Chuck, "This makes me think of how I have seen computing for a long time and how most other people see it. I have been watching all the cows all jump at once for a long time. I have said for decades that almost everything is "embarrasingly parallel." Most other people think cows always jump in sequence, that's all they have ever seen!" Many people are struggling with learning to think about programming for parallel hardware. Many of them have always insisted that most problems are really sequential anyway because that's the only kind of computing that they have ever seen from their end of the fence. An interesting subject in parallel processing is superlinear speedup. Some people dismiss superlinear speedup as something only due to increased total memory cache and in some cases it is. But cache is only one of many resources that does not scale linearly when parallel hardware is balanced. All resources are limited, but some things are limited to one per processor and those thing scale very linearly in steps of one. One might say that we have a one word instruction cache in the G18 core. It explains much of the superlinear speedup we see when we split many things out into parallel processes. There are other details. We can't poll a pin in a loop as fast as we can restart and r/w instruction on a pin change. A polling loop introduces a loop jitter into the timing about the size of two loops. A wake-up circuit is a hundred times faster than an event poll loop or interupt. If a processor has to poll multiple pins one expects superlinear slowdown. If multiple processors are used instead to poll one event each things scale in a linear fashion for a while. But one can use the much faster synchronization mechanism on G18 core and get superlinear speedup. It is not just that servicing two or three events will be two or three times slower than servicing one event in a polled loop. When we limit each processor to a single event we can get it to react a hundred times faster than a processor polling a single event in a loop. Some things, like using core as wire, reduce efficiency as measured by number of core. It often makes more sense to do analysis based on power usage or cost than the number of core required. Other core are not as cheap or low power as these tiny core. To get the highest speed the results are not superlinear since some core sleep a lot and only provided limited speed-up services to a neighbor. An instrucion offered to a neighbor can be executed slightly faster by that neighbor than an instruction from its own local RAM or ROM. To get the maximum speed from these little core things have to be split into very small pieces. When the pin I/O or neighbor I/O routing hardware is used parts of programs can be sped up quite dramatically. And using this mechanism allows for some superlinear speedup within a range and in applications with well matched requirements.

12/10/09 Green Array Chips Chips I returned recently from a meeting at Green Array Chips. I had forgotten how much fun it is to be around a group of such talented and creative people. When we were not dealing with plans, colorforth software, or new hardware we talked about other things. At one point I related a story to Chuck about how I had thought about a story I had read in a book on his shelf about how a dream about cows had led Albert Einstein to the theory of relativity was a story that applied to parallel programming. One evening I asked the group at dinner if anyone could explain Bell's Inequality to me. It was a problem that I had been chewing on for a number of years without much digestion and I felt I really started to get a feel for it. I can't explain my understanding of it to a six year old yet but I am working on it. At one point I was talking about the variety of BASIC, JAVA, Python and Forth computer stamps. I mentioned a BASIC stamp programmed in Forth at AMResearch. Charlie told me that he was the person who actually did the programming on that project. He didn't correct the facts I offered when I mentioned the project but I hope I can convince him to talk about that old project at SVFIG sometime. I saw him demonstrate the new target software simulator for OKAD II. Since Green Array Chips plans to release a new colorforth with target compiler, target software simulator, and Interactive Debugger Interface for running interactive Forth environment between colorforth on a PC and real Green Array Chips hardware I think he should give a talk and demo of the new colorforth softsim packages for the Silicon Valley Forth Interest Group. With new GA4 in 8 pin and 12 pin packages, and with the new GA144 back from fab and ready to have new circuits tested and measured and some potential new projects in the works things are pretty exciting at Green Array Chips. There was talk about options and about ways to teach OKAD II and full custom VLSI chip design to secondary school students. There would be much to be worked out but the project does interest me a lot. It will interesting to see what projects work out for 2010.

11/22/09 Silicon Valley Forth Interest Group Forth Day 2009 Plus One The Silicon Valley Forth Interest Group's Forth Day took place yesterday at Stanford and was enjoyed by about the same number of people as last year. It closely followed the agenda currently listed at the forth.org website which is pretty self-explanatory. SVFIG Forth Day 2009 Agenda SVFIG Forth Day 2009 Photos (at Forth.org) There was old stuff, new stuff, evolutionary stuff, and some innovative reports. Video were made and photos taken that will be posted by SVFIG just like last year. There was lots of interesting stuff. I won't comment on it all but am willing to answer a few questions if I can. Dr. Ting had an interesting approach to eForth in C. The report on details of the Forth Foundation Library should be of interest to a lot of c.l.f readers with opinions about library projects as it seems to be pretty mature at this point. Leon did a step-by-step demonstration of how to start a project, compile a system on a chip onto an FPGA with a soft processor core, target compile an application using Swift-X and get it all running very quickly while answering questions and making it all look easy. IntellaSys and Green Arrays had quite a few people attending and a few presenting. I already knew quite a bit about the hearing enhancement project but it was very nice to get a report and hear an actual hearing aid device working. I very much enjoyed Michael's presentation. The algorithms used in this hearding aid are quite sophisticated and the previous prototype which used TI DSP chips was nearly the size of a laptop. I was impressed by how much the size of the application had been reduced in the Forth version for S40. Since only a small fraction of processing power of the S40 is used in the application so much of the device doesn't consume power most of the time and battery life can be maximized. I would live to have one of the devices to play with to host s40 based interacive voice based apps in an ear bud. I talked about the Interactive Development Environment for target chips in colorforth and reviewed a version of the PWM Serial boot packet and/or neighbor boot routine from a GA4 ROM that I had presented earlier in the year to a small audience. I answered the question I had posed for the reader about the little optimization one could do on the routine I had shown. I talked a little about blue words and the design of the target compiler and IDE in colorforth. I talked about the blog entry I had made about optimizing your structures in Forth and got a few nods from Chuck for comments about the example code. I said I wanted to show more than what was normally show to beginners when the subject comes up. My finger is pointing to the GA4 chip which is both talking to the colorforth IDE on an asynchronous serial connection and being booted by the GA32 in the socketed blue board on the right which is also talking to the colorforth IDE over a USB/synchronous serial connection. There is also a small 1.8V to rs232 converter board above the GA4 board. The GA32 is sending a PWM Serial boot packet using XMIT routine at 31MBPS to run test code on the GA4. I pointed out that when one sets up a path to a target node in the colorforth IDE to interactively talk to it as if it were running a Forth interpreter with a command line that it had to be the smallest such Forth system as it uses the minimal amount of RAM and ROM. The minimum RAM/ROM footprint being zero. Chuck showed colorforth code for the Haypress Creek board and using the IDE showed several small applications using a small amount of the resources on the board to generate video and display several clocks in one of three fonts. Greg announced that they would soon be releasing several versions of colorforth with the compressed code, blue and grey words, multiple fonts, watermarks, documentation, and with a target compiler and software simulator for each of the GA4, GA32, and GA144 chips. All other OKAD application programs and the chip designs themselves will of course be stripped from these public colorforth releases. I had wanted to do an interpretive reading of John Gillespie Magee's poem High Flight but there really wasn't time. Chuck commented in his time that he had selected some poems at his website that were meaninful to him.

11/19/09 Silicon Valley Forth Interest Group Forth Day 2009 Minus Two The annual Forth Day in Silicon Valley is comming up this Saturday and I have offered to give a short talk (well short for me, I can still talk your ears off if given the chance). Since I haven't been going down to Silicon Valley on weekdays like I had been doing for a few years to work with interesting people at IntellaSys I look forward to seeing some of them at the Silicon Valley Forth Day get together. Chuck had a party up at his home in the Sierra last month and it was a fun visit. I said I would review some of the blog entries I made this year, and follow up a bit on the presentation I did at SVFIG earlier this year. I will show the Interactive Development Environment for target Green Arrays chips in colorforth. I am using the same IntellaSys board for the GA32 testing as I use with the SEA40. The board has a socket and all the 32 and 40 core designs have been put into the same package so they all work on the development board with the ZIF socket. All it needs is a USB cable to the PC and ventureForth or colorforth will recognize the board and allow target Forth development with incremental compilation. I also have a board with a GA4 that uses an asynchronous interface and is connected to a rs232 converter board. That one can be used with the tower I have that runs colorforth native and has a serial port or I can use it on a windows PC using a USB to serial card. Using colorforth windows hosted I can run two instances of colorforth in different windows. One can be setup to talk to the IDE on the USB bus to the GA32. I could show this setup and show how I used the PWM serial output on the GA32 to boot code on a GA4 while running the IDE to the GA4 in a different window. I can run the tests with either a direct connect between the GA32 and GA4 boards or with a capacitive connect. The only problem is that the GA4 board I have needs a small bench power supply and so isn't as portable as the GA32 board and hauling in a couple of boards and a bench power supply is one more thing to setup for a a demo. I probably will just show a GA32 talking to colorforth. As is often the case this is a year when there are some things we can freely talk about and some things that we can't. Some of the most interesting stuff as always is quite technical but isn't public so it isn't for Forth Day. But what we do with or have learned about the software is fair game as always. I talked about this IDE to SVFIG earlier this year and made a blog entry about it 10/17/09 Green Arrays GA4 Boot Software Simplified Again. But this time I will show the IDE talking to the hardware. I know that there is some debate about what constitutes a minimal Forth system, or a Forth system at all. The ability of the c18 design to execute an instruction stream of Forth opcodes on a real (not virtual) Forth machine removes much of the complexity of traditional Forth systems and reduces the amount of ROM and RAM needed to execute Forth programs. And the minimum is zero. A target c18 processor may have booted to ROM code or it may have booted to the address of multiple shared registers with other c18. In the later case zero words of RAM or ROM or needed on that processor as a neighbor or group of processors can feed it a sequence of Forth code to execute. Originally these chips all booted to ROM and executed some code sequence to be able execute incoming Forth code but over the years the design evolved so that most c18 boot to an RDLU multiport address and go to sleep waiting for Forth code without ever executing any ROM or RAM. These computers take about a nanosecond from powerup to get to a state ready to run incoming Forth programs with a delay of a couple of hundred picoseconds, they run Forth up to 700 million Forth opcodes per second, they draw only a few mw per billions of Forth opcodes per second, have high speed high analog hardware on board, scale in arrays, use about $.01 worth of silicon each, and only need simple Forth tools. The colorforth target IDE uses this to setup paths from the place on a chip where it connects to a target chip to other c18 on that chip. One can change paths and talk to different c18 in the grid at different times. The IDE lets one look at the stack and registers, put literals on the stack, fetch and store memory or registers, dump memory, or load and execute programs on any c18. It provides an interactive Forth user interface running in colorforth on the PC and possibly in multiple c18 nodes acting as temporary message pumps connecting the user at the colorforth console to the interactive Forth user interface on any c18 in the network. I will try to keep the demo simple with just one target chip, GA32, and show how easy it is to turn an lcd on or off on the target board with an interactive command or load and run a test program written in coloforth. I will also talk a little about the design of the code itself. This is after all a group of people interested in Forth and sometimes Forth coding that will the audience. The point I will want to make is that it is MUCH simpler than your typical target Forth not just because the target has no primitive defintions or virtual machine definitions but also because of the way the target compiler and IDE work in colorforth. Some things are done in a way that is very different than that used in almost all ANS Forth target compiling or meta compiling systems, and much simpler. The wordlist problem issues are simply avoided. The word DUP exists as a colorforth macro specifying a colorforth 32-bit stack operation and as a target c18 Forth word specifying a target 5-bit opcode for the 18-bit wide stack in the target compiler or as an interactive command in the target IDE. Color specifies type of use. There is a conflict that is not resolved. The problem that other people address with wordlists is simply avoided. The code is either colorforth code or target code or IDE code at any one time. There is no need to be able to jump between the three environments when using the IDE. Wordlists are not used to mix code in the three environments, things are simply defined in the order needed. When things are simply compiled from source in a programmer specified order many problems are avoided. I'll try to give some of my time to the guys who have made internal changes to colorforth this year. Or perhaps I will just ask them to list the various internal changes. But I would like to see they guys talk about the changes to color tokens, to the editor, the new fonts, the new Green Arrays Softsim application that might get released to the public, the IDE and documentation, and possible plans to make a new colorforth release to the public. Forth day might be a good place to discuss ideas about future changes to colorforth. I may explore that a bit too and see what people think before I do my presentation. I made a trip to Austria in 2007 to work with the team developing the hearing enchancement project for IntellaSys. It is a fascination project. I followed up with a visit with my old friend Soeren Tiedemann in Berlin. He showed me a really great time. One thing I found remarkable was that every morning that I was in Austria or Germany there was at least one morning show from a gliderport somewhere. Rarely does TV show people flying in sailplanes here in the US. The hearing enhancement project moved to the US for porting to IntellaSys technology and was the only project that continued after most everyone working for IntellaSys got laid off back in January of this year. Dr. Montvelishsky stayed on to work on the hearing enhancement project and will be giving an update at Forth Day that I look forward to with great anticipation. As the original author of ventureForth I look forward to seeing what Dennis Ruffer has done with front end. The idea was that we were trying to enable other people to do that sort of thing and it will be interesting to see him demonstrate what he has done with it. I expect to be educated by John Rible's presentation on his new double square root code. And as always I look forward to seeing Chuck give his presentation as he is always entertaining. If I left your presentation out don't be offended I am sure I will enjoy it and will write something about it. It is wonderful to see the technical success with cad, circuit design, chip design, packaging, layout, and system programming. I hope at some point that there will be a project generating financial success so that the details of the technical success can be shared with more people. If you like Forth because it is simple and easy or exceedingly productive then this is good Forth stuff. If you prefer stuff only on the most well troden paths then this probably isn't for you.

10/27/09 What's Wrong in Forth Programs? I followed a link near the end of my last blog entry to Chuck's page about good Forth being only 1% as big as typical C according to Chuck. I found the section of the page "What's wrong with C programs?" to be a gem of information about how Forth is suppose to be different than C. Chuck lists problems intrinsic to C and problems in C style. Let me review Chuck's comments in the context of Forth style. Chuck's comments will be in bold. What's wrong with C programs? * Some problems are intrinsic to the C language: o It has elaborate sytnax. Rules that are supposed to promote correctness, but merely create opportunity for error. Forth starts out with minimal syntax and you add syntax as needed. Syntax limits language and language limits thought. But some people use many more rules for spelling Forth words or more rules for formatting the layout of their code than needed. Rules are dogma. People who have high social dependency and or high latent inhibition will be compelled to fix this problem with Forth by legislating standards and expanding them. o It has considerable redundancy. This increases trivial errors that can be detected. And program size. Brevity is good. A shorter proof is a better proof. Shorter, clearer code has fewer bugs. o It's strongly typed, with a bewildering variety of types to keep straight. More errors. Typing is a crutch for crippled programmers. o As an infix language, it encourages nested parentheses. Sometimes to a ludicrous extent. They must be counted and balanced. Keep as much of it simple Forth as possible. The algorithms and the execution is postfix and it makes it easy when the source code has the same structure. The stack means fewer names and natural postfix notation. o It's never clear how efficiently source will be translated into machine language. Constructs are often chosen because the programmer knows they're efficient. Subroutine calls are expensive. Compilers must be simple and straightforward. You need to be smarter than your compiler. Chuck once questioned why people want complex optimizing compilers, "Because they want to write non-optimal code?" Learn to write optimal code and see in your minds eye what the compiler will do with it. Today students are taught that the processor is impossible to understand (who really understands everything about each model of just Pentium, or even one model?) and that the internals of the OS and compiler are too involved to concern an individual and that what is needed is to stay at an abstracted level of view and ignore all the bugs. The complexity of the processor and the compiler are a status symbol. People actually brag about how the compiler they use is much smarter than they are. This is not suppose to be the case in Forth. o Because of the elaborate compiler, object libraries must be maintained, distributed and linked. The only documentation usually addresses this (apparantly difficult) procedure. Yes, there is this notion that an elaborate optimizing compiler makes it possible to always use the same portable source code. Libraries are worse than syntax when it comes to limiting thought. It is a process of institutionalizing people's mistakes, the same ones fed to the cut and paste generation that does not even grasp the notion of plagerism. * Others are a matter of style: The points above are not just a matter of style, they are the principles from which the design of the language evolved. The Forth language is words. Stacks are needed to make simple words work. Words, stacks, and blocks isn't much but it is Forth. Forth simply isn't about elaborate restrictive syntax, complex rules, redundancy, restricted typing, complex compilers, and portable libraries. These things that aren't there in Forth for good reasons not because we need them. Not only is this some of what distinguishes Forth from C but from a Forth programmer's point of view these are the things Forth was designed to avoid and not the things that need to be added into Forth. According to Chuck Moore these are the things intrinsicly wrong with C that need to be right in Forth. It is easy to corrupt the Forth language design and try to make it more like C but it is really easy to just try to use C style inside of a system designed to be very different than C. What Chuck lists as style errors in C are certainly a good list of style errors to be avoided in Forth. o Code is scattered in a vast heirarchy of files. You can't find a definition unless you already know where it is. Files. That's about all that one needs to say. But Chuck says vast heirarchy and it is certainly true. I have seen Forth programs factored exactly like the C programs they were modeled after right down to the same factoring of source code into hundreds of files in dozens of nested directories that can't be navigated in a portable manner. This is after all the style promoted in the Forth Scientific Library design, much of which seems simply copied from C or Fortran source then expanded in the name of a style of portability found in C. Some promoters call it "good coding be damned style Forth" and others call it, "a shining example" of Standard Forth. Personally I think the term nightmare is more appropriate. It is what makes libraries the nightmare they are. Reason after reason compounded one upon another making each problem at its own layer an order of magnitude worse. Hundreds of files in dozens of directies for a single library component and a plan to put hundreds or thousands of these components into portable Forth libraries. This alone can make things hundreds of times more complex than with a Forth approach. I think it an excellent example of how complex one can make things. Show me the source code you need to list all the source code to a dozen applications each factored by someone else into hundreds of files and dozens of directories from the library. Can you write a word to display all the source to a dozen real applications in a few minutes and a couple of lines like other people do in Forth? I was thinking it would be fun at Forth day to show a two line definition word that lists all the contents of the system in this case compiler, OS extensions, editor, OKAD system and parts, circuit simulator, various design rule checks, chip layout, chip simulation, gds file translation, target compiler, chip descriptions, target ROM code, target testbed code, target RAM code for testing, tethered Interactive Development Envirnoment, a few other apps, and all the shadow screen documentation, and then run it and show everyone all the souce code to everything. o Code is indented to indicate nesting. As code is edited and processed, this cue is often lost or incorrect. This reminds me of a presentation to SVFIG by Wil Baden where he showed rigiorously spelled and visually laid out code and made the comment that the amount of indentation on each line was "correct." I asked what "correct" meant in that context and he replied that "Two characters is the correct amount 