Slashdot Mirror
Ask Chuck Moore About 25X, Forth And So On
Chuck Moore is, among other things, a chip designer. His latest design, the 25x, is based on a 5x5 array of X18 microprocessor cores, and could provide 60,000 MIPS with a production cost of about one dollar. And Moore has the chops to back that up: he's been designing tiny, efficient processors for many years. He's also the inventor of the programming language Forth, which has evolved from a miniscule but radically fast language "difficult for a human to read" (according to The Secret Guide) to the even more radical colorForth. How radical? Try "includes own operating system; has own 27-key Dvorak keyboard layout; meaningful color syntax." How's that for starters? Ask below your questions for Chuck about processors and programming (ask all you'd like, but one per post, please) We'll pass the best ones on to him, answers soon to follow.
What kind of signalling method are you for inter-proccesor communication?
And what led you to design/implement this array?
How do you see the processor evolving in the future, right now Intel / AMD are trying to make things smaller and smaller, but I feel that there is more viable solutions out there, what do you think?
Many high-level languages compile into C code, which is then compiled with gcc or whatever. Do any use Forth instead? I understand Forth is a stack-based language: doesn't that present problems when compiling for CPUs that mostly work using registers?
-- Ed Avis ed@membled.com
From the 25X webpage:
A 7 sq mm die, packaged, will cost about $1 in quantity 1,000,000. Cost per Mip is 0.
At that price, I'll take a few billion MIPs, please!
Many high-level languages compile into C code, which is then compiled with gcc or whatever. Do any use Forth instead? I understand Forth is a stack-based language: doesn't that present problems when compiling for CPUs that mostly work using registers?
Anyone remember the first outfit to sell a FORTH engine?
I heard that the Novix design had been included in Harris's standard cell library, but that was probably more than ten years back.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Do you have a direction in mind as to where Forth/colorForth and the 25x could go? e.g. do you see them in handhelds, set-top boxes, etc?
Potato chips are a by-yourself food.
What market niche will the new grid-array processor be targeted at? 60 BOPS is a fair value for a buck. But is the power consumption ridiculous? Or would this be suitable for deployment in various mobile applications? Or is the only way to get this high of projected performance by clocking the chip like a six year old on chocolate frosted sugar bombs?
And an aside:
My ignorance of Forth might be showing (one of the few I haven't had kicked into me over the years) - but wouldn't "meaningful colour syntax" represent quite a nasty disadvantage for those who are either entirely or partially (red-green) colour blind?
And speaking of Dvorak... anyone know where I can get an ergonomic, full sized, keyboard with a Dvorak key layout. I can probably remap the keys on the existing MS keyboard, but the idea of switching the keycaps is nasty. It'd be better to have a keyboard that sent the right scancodes.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
What is the most revlutionary (i.e., it is scoffed at by those in control/power) idea in the software industry today? Explain how this idea will eventually win out and revolutionize software as we know it.
Amazing magic tricks
Forth is a very cool language: I first used it running on an Apple ][ a couple of decades ago, to write programs to control lasers for laser shows at a planetarium. The combination of interactiveness and performance was great - it allowed details of a show to be reliably tweaked right before and even during a show. This was one of those situations where the tool really made a difference to the end result. Other languages available on the Apple at the time couldn't really compete.
I don't have a question for Chuck, but I'll come back when I think of one.
Now that sub-$1k computers are running in the GHz range, it seems that all the computational tasks on a common desktop system are not processor-bound.
3D, rendered-on-the-fly games get well over 30 frames per second at insanely high resolutions and levels of detail. The most bloated and poorly-written office software scrolls though huge documents and recalculates massive spreadsheets in a snap. Compiling the Linux kernel can be done in less than 5 minutes. And so on.
It seems that the limiting speed of modern computers is off the processor, in IO.
What then, do you forsee coming down the pike that requires more processor power than we have today? What's the underlying goal you intend to solve with your work?
Want to learn about race cars? Read my Book
I learned forth early on in my programming career; it was very memory and CPU efficient, something that was important on early microcomputers. It was also a great deal of fun (though far less fun to try and understand what you wrote a week earlier...). Today, even small, cheap microcontrollers are able to run fairly sophisticated programs, and it is far easier to cross-compile stuff on a 'big' machine and just drop the compiled code onto the development board.
Forth has (in my eyes) always been about small and efficient. Today, though, embedded apps are more likely to be written in C than in forth, and the "OS as part to the language" thing isn't as compelling today as it was in the eighties. Where is forth being used today, and where do you see it going in the future?
/Janne
Trust the Computer. The Computer is your friend.
From the web pages, I don't see any mention of access control.
Can this processor be used in a multi-user, general-purpose mode?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Somewhat off topic, but the Open Firmware system used to boot all current Sun, Apple Macintosh and I think also IBM machines is a Forth implementation.
Basically its a Forth interpreter with a stack, and a device tree. You can literally 'cd' and 'ls' around the PCI and other busses on Sun workstations.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
umm, that's an old communications protocol. I think you mean 25X.
sulli
RTFJ.
This one would probably require a bit more time to answer than you probably have available, but a quick rundown would be cool: Where do you see programming languages headed -vs- where do you think they SHOULD be headed? Java, C#, and some of the other 'newer' languages seem to be a far cry from Fourth, but are languages headed (in your opinion) in the proper direction?
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
Chuck,
I've read everything on your site & also Jeff Fox Ultratechnology.com site about your Minimal Instruction Set Chips, their design, performance etc.
What advice and tools would you recommend to anyone today starting out and wanting to follow and build upon the path that you've set out?
Very Interested?
No, just millionaire.
You guys need to scale back on your advertising.
No, my bad - you're either that experimental NASA reuseable space plane or the ham packet radio protocol.
Someone on Slashdot has recommended Forth to me as "perfect middle ground between ASM and C." I have looked at the FAQs and could not find a quick-and-dirty overview of the language.
I am looking for the simplicity, control, and elegance of ASM. But I also would like to enjoy some degree of abstraction and features that reduce the drudgery of programming. I have looked at HLA and Terse but they are platform-dependent, unless I write my own compiler. Do you think Forth meets these criteria?
Another thing. Just from peeking at the FAQ I see Forth uses postfix expressions (among other things), which seems a little dated. I assume this was implemented for compiling on resource-constrained machines? Do you plan on giving Forth a minor face-lift?
(If you could microcode the "instruction set", all the better. A parallel processor array can become an entire Object Oriented program, with each instance stored as a "thread" on a given processor. You could then run a program without ever touching main memory at all.)
I'm sure there are neater solutions, though, to the problems of how to make a parallel array useful, have it communicate efficiently, and yet not die from boredom with a hundred wait-states until RAM catches up.
What approach did you take, to solve these problems, and how do you see that approach changing as your parallel system & Forth language evolve?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The 25x concept looks like it could really a damned interesting idea. But one of the questions in my mind is where you want to head with it? Is this something that is to be used for very specialized research and scientiffic applications, or is this something that you envision for a general 'desktop' computer for normal people eventually?
Secondly, if you are considering the 25x for a desktop machine that would be accessable by people that aren't full-time geeks, what about software? Forth is a lost development art for many people (It's probably been 10 years since I even looked at any Fourh code) and porting current C and C++ application would be impossible - or would it? Is there a potential way to minimize the 'pain' of completely re-writing a C++ app to colorForth for the 25x machines, which could help to speed adoption of a platform?
Davis Ray Sickmon, Jr - looking for something to read? Check out my three free novels at MidnightRyder.org
First: Great to see you here. I really enjoyed a FORTH like language on my Altair 8800 (written from an old Byte book "Threaded Interpretive Languages" or TIL's) because BASIC was SLOW and assembly tedius.
Only question I have is about the choice of ShBoom for a microprocessor - any story behind that??
I sure wish I could get a uP like an NC4000, RTX2000 or PSC1000 - inexpensively.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
a beowulf cluster of these!
You're offtopic, and surely will be modded down. My reply to you will not be modded up. Nevertheless: You, (along with millions of others) have mistakenly identified Slashdot (and millions of other sites) as public services. Sorry, tax dollars didn't pay for Slashdot. Its privately owned. It belongs to its owners, who may do whatever they please with it, enact whatever rules they wish, and so forth. If you don't like it, write to the owners with suggestions. They'll ignore you if they like. Your only other option is to go away. Period.
-Leperflesh
I am allowed to criticize you: you are not allowed to criticize me. Sorry, that's just how things are.
I played with forth back in the early 80s on an Apple II. It's really a remarkably powerful and efficient programming system. I was able to write programs in forth that ran at nearly the speed of the equivalent assembly language, but were much easier to read and maintain.
Two excellent books worth finding, both of which are probably long out of print:
"Starting FORTH", Leo Brody, Prentice Hall, 1981.
A very well written book aimed at the absolute beginning programmer. Brody uses cartoon drawings to illustrate the operation of the forth operators, and over the course of some 350 pages, explains not only how to program in forth, but how the language works under the covers and how to extend the compiler. Highly recommended and extremely novice-friendly.
"Threaded Interpretive Languages", R.G. Loeliger, Byte Books, 1981.
A more technical work, Loeliger describes and explains the implementation of an almost-but-not-quite-FORTH language. The book contains (and explains) the full source code, assembly as well as high-level, for the interpreter.
This is going to be a stupid question...but one I suspect many will have.
What is Forth? Why is it useful? How fast is it in terms of useful computations? X MIPS, when comparing miniscule Forth instructions to CISC Intel instructions isn't really a good comparison. So how many *useful* computations can it perform compared to modern processors? What has it been used for in the "real world"?
I recall a company creating a transputer -- basically an array of FPGA's, all doing 4-bit add operations, and claimed X thousand MIPS, where X is large. How are Forth machines different?
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
onto the embedded system. RTFA
I've followed you at http://www.ultratechnology.com for years now and I'm a big fan of your outlook on technology. Now, when are we going to see your chips in use? Your cpu would be great in a game box (for example). If your stuff is being used, please tell us how it is being used and for what purpose. Thanks.
I love Forth, always have. From the first hand-entered FIG listings to the excellent Win32Forth, I've known this is the "right" computer language. So why doesn't the rest of the world see what is so abundantly clear? Is it because they can't make the small mental leap to RPN?
And why isn't Forth used more as a platform? Is it speed, security, advertising, what? I've never understood why the Forth community will take an excellent implementation right up to the point of being useful, then leave it without developing any applications. I can see an efficient, user configurable web cruiser built on any one of a number of Forths. But nobody has done it. Ditto for httpd servers. Why?
And to the rest of the world, please stop parroting the old line about Forth being hard to read. It isn't. You can pick up most of what you need to know in an afternoon, then begin to enjoy some very elegantly stated code.
What part do you see Forth playing in the future of GNU/Linux and other FreeSoftware and OpenSource operating systems (*BSD, *[A-Z]*[T/N]*[X/CS] etc)?
How do you forsee such a synergy affecting the popularity of both parties?
-Marvin
* 5 x 5 array of cores: 60,000 Mips
.5 J/s. Divided by 60,000 million instructions/second implies that this can execute 1 instruction while consuming only 8.3e-6 Joules of energy. What I'd like to know: Pretending for a moment that the instruction was simply to flip a single bit, how close does this come to the absolute limit dictated by Information Theory?
...
* Max power 500 mW @ 1.8 V, with 25 computers running
500 milliWatts is
324006
2400 MIPS per processor, 25 processors for 60,000 MIPS total. For reference, a 1 GHz Athlon is about 3000 MIPS. Of course, it's hard to compare the two because the instruction sets are so different.
I don't think the 25x has an FPU, though, so no analogous FLOPS comparison.
It may not be clear to rest of the Slashdot audience that they are asking questions to a legend of the field. The FORTH language could easily have been what C became, and only luck decided the fate of each language.
I was truly amazed when I first found a FORTH compiler for the Apple II. It was so alien to everything else available, yet so advanced, so ahead of the pack.
So, as for a question, do you think the growth of the appliance and handheld markets can give FORTH a chance to achieve a mainstream status? What steps are being taken to bring FORTH compilers to Palm OS, Windows CE and such?
Do people actually buy stuff from all of those pop-unders* you guys have ON EVERY STINKING WEB PAGE?!?? Does it really fit in the palm of your hand? Neat!
.
.
*Yes, I know that is X10. It is a joke. Live a little.
I don't think you really want such a keyboard.
You MIGHT want one that sent the same keyboards and someone had already switched the keycaps...
and I could see some usefulness in on that switched between the two modes in hardware, except it's probably exorbinantly expensive, due to the low production run. That alone is reason enough not to get one...
But there are a bunch of things which map to a keyboard geometry, the one foremost in my mind being IJKM as arrows... and there are others, some I've programmed for testing reaction time. There's no reason I can think of to swap the keycodes around, and several not to, unless you're trying to fool everything, which I don't think you are. At least, if I were going to do that, I'd want an A/B switch.
- Arete
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Forth is small and efficient enough that the UltraSPARC PROMs contain a small interpreter. You can write Forth code and store it non-volatile RAM, to be executed at powerup.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
For-- is wel- kno-- for sto---- all key----- as thr-- let---- and the len--- of the nam-. Why was thi- des--- dec----- hel- ont- eve- aft-- mem--- bec--- che-- eno--- for spa-- not to be an iss--?
Racists should be sent back to where they came from
Good Forth programming factors the code into many small 'words'. Getting the most from such code requires very efficient flow control mechanisms. (fast jump and function call/return)
In small systems, this is ultimately tied to memory access speed and latency. Asynchronous RAM is single-cycle, but slow (and thus drags the CPU down with it) whereas Synchronous (aka: Pipelined) RAM introduces at least one cycle of delay between the read and the result, although with a much shorter cycle time.
Assuming none of the usual L1/L2 cache schemes used on most computers, what do you think is the best scheme to keep the clock speed up and the flow control efficient?
The history of computer programming is in part the history of moving away from bit flipping a la "Add S to T if T0=1 (multiply step)". More people get more done faster when working at a higher level of abstraction. For what applications is such register-centric work still worth the investment in development (both in training the programmer and in developing the programs)?
And will there be a reprint? Do you think the relative difficulty of finding a book made Forth less accesible, or the relative difficulty of Forth made publishing less attractive?
'Starting Forth' was great, though I read it before I had a computer to hack on (circa 1979 or '80).
Is it frustrating?
Note that since most Forth instructions are zero-operand (they implicitly operate on the stack), you only have to encode the opcode, not any additional address or data fields. That means that each instruction is only 5 bits long, so you can pack 3 of them into an 18-bit word. That's why the chip can execute so many instructions per second -- if you have three contiguous primitive instructions (as opposed to high-level words which are subroutine calls and require addresses), you can pull in three of them with each memory access.
There's been lately a bit of discussion on non-text or non-linear programming languages; from purely visual programming languages like Jaron Lanier's Mandala to literate programming languages like CWEB, there seems to be a trend beyond ASCII-linear text programs. Your colorforth seems to be an effort in that direction
Question is: where do you think this field is headed? Will non-ASCII programing languages be niche players, or will some of them become as widely used as PERL or Java? Is there something fundamentally different you can do with non-ASCII PLs? Or something that you can't do with other programming languages, like C++?
PS: I had a glimpse of Forth ~20 years ago with a Forth interpreter for the ZX Spectrum, which beeped and printed color squares while it was interpreting stuff. Quite funny, indeed! Or maybe a harbinger of ColorForth...
It's just a BloJJ
But Japan has mastered the tiny HAMBURGER!!!
The 25X system reminded me of IBM's Blue Gene computer, where a large number of inexpensive CPU cores are placed on a single chip.
The biggest problem in dealing with a large number of small cores lies in the programming. I.e. how do you design and code a program that can utilize a thousand cores efficiently for some kind of operation? This goes beyond multi-threading into an entirely different kind of program organization and execution.
Do you see Forth (or future extensions to Forth) as a solution to this kind of problem? Does 25X dream of scaling to the magnitude that IBM envisions for Blue Gene? Do you think massively parrallel computing with inexpensive, expendable cores clustered on cheap die's will hit the desktop or power-user market, or forver be constrained to research...
Most of the questions I see here are FAQs (e.g. "What is Forth?") that you don't need to ask Chuck. It seems that people don't really understand what he has been up to, so here's a general overview.
He did create Forth, yes, but that was thirty years ago. And while Forth has been relatively unchanged for the last twenty years, Chuck has kept evolving the language in a quest for the minmum interface between a human and a computer. The "OS" talked about in the intro is only a couple of kilobytes (yes, kilobytes).
He works not just on software, but does true systems work: a combination of software and hardware. And that is what he is trying to minimize. The system as a whole, not just a programming language. He has been designing processors hand-in-hand with stack-based languages. So he can do things like write a compiler for his language in a hundred lines of code. And he has a chip that uses _milliwatts_ of power and only 15,000 or so transistors.
If nothing else, realize that Chuck is one of the few people single-handedly creating microprocessors. And he's way, way out there. Remember the recent Slashdot post about asynchronous logic? Chuck has been designing chips without proper clocks for ten years now.
My question to Mr. Moore: Linux is seen as a more stable and reliable alternative to Windows, but at the same time I wonder if it's real progress or just a similar incarnation of a traditional operating system. Is the concept of "operating system" outdated?
Imagine a beowulf cluster of these... :)
if you want people to think you know what you are talking about, just put ".com" at the end of everything you say.com
I don't think anyone will argue with the fact the Forth programming can allow one good programmer to generate small programs with amazing functionality compared to other languages, but do you feel that Forth advantages map well onto large scale projects? Forth has obviously been used for complicated embeded projects, but has it ever been used developing a GUI word processor or CAD program from scratch? If so, did it hold onto it's small application virtues, or if not do you feel that it would?
Thanks for delivering a language that has proven to be great on memory constrained systems for years.
Chuck,
What are your views on Object-Oriented programming and how it would relate to forth?
From reading your webpage, it appears that the X25 is a 5x5 array of asynchronous processors that execute an assembly language very similar to Forth. How do they communicate and share information to do useful computations?
ANSI/ISO Standard Forth requires 31-character names as a minimum. You'll be hard-pressed to find a modern Forth that uses 3 characters plus length for symbol storage, though it was a useful technique in the days when memory was scarce.
RAW is a tiled microprocessor, consisting of 16 MIPS cores, connected by a rectangular network. The best part of it is that you can connect many of these chips together to form even larger computers (the network will just extend outwards).
It's nearing completion, there are some good results. You can check out http://cag.lcs.mit.edu/raw/ for details.
m
You would think that array machines are especially wanted for signal processing applications, wouldnt it make more sense to dedicate more area to arithmetic in relation to the rest of the CPU for the 25X? To have most of the area dedicated to the stack which would not even be running at full speed during arithmetic operations seems like a waste.
o/~ Join us now and share the software
It seems like each new generation of mainstream microprocessors requires more power and generates more heat than the last. I see that your processor array reverses this trend. What do you think is the main advantage of low power consumption?
Do you ever wonder what could have been if the
world had gone with Forth or something like Forth,
instead of C & UNIX and their decendents? Do you
think that it could have been possible?
I remember the happy days of programming my Amiga
in JForth and MultiForth. Those were much more
powerful and flexible systems than the C compiler
I had originally used to program the Amiga.
It seems from the X18 architecture and the general format of Forth that it would be efficient at executing java bytecodes or at least as a good target for on-the-fly translation, since the JVM is also a stack machine. Java even has enough multithreading that it might be able to make use of having 25 processor cores on a chip.
Have you looked at Java as a high-level language for these systems or at Java bytecodes as a way to make common software available to users?
o/~ Join us now and share the software
o/~ Join us now and share the software
information is immaterial
The 25X has lots of MIPS for grinding away on small amounts of data in each CPU's stack, but it looks like getting data on and off the CPUs from memory is the bottleneck, especially since the CPUs implement this in software - this means it can crunch very hard on very localized bits of data, but it's tough to give a single CPU enough for, say, a Fast Fourier Transform (at least for the interior CPUs). What kinds of applications work well on this sort of machine? How much cache is it practical to build around it? Has anybody built a bignum multiplier with it?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I used Forth a couple of times in my younger days, for a PC data collection board, and STOIC, a VAX/VMS forth that an excellent editor was written in. So I'm familiar with some of Forth's strengths.
But Forth hasn't taken off, either in the general market or in its target market. In the same time period, numerous other languages have either become quite popular or have become well established in niches: C++, Java, Perl, Python. Companies like Cygnus have made mucho $$ supporting C in embedded environments, supposedly a natural niche for Forth. And research projects which involve, say, downloading codelets into an operating system to filter network packets tend to use Java or interpreted C instead of Forth.
If you could somehow wave a magic wand and create projects to make Forth popular, what would you do? What vendors would begin to offer Forth as an alternative, what killer open source projects could be done far more efficiently with Forth, and what great benefits could firewall vendors create by letting admins add little arbitrary packet filters written in Forth?
o/~ Join us now and share the software
o/~ Join us now and share the software
Can you tell me if ColorForth has a spell checker? If so, what was the rational for building it? Is it compiled into the kernal?
It seems that forth is the last remaining
example of a language being used in a system where
everything, from the chip design to the OS, is
tailored to work with a single language. Back in
the 80's, there were similar systems written in
lisp, but there are no more. While there are occasional
proposals for a scheme processor floating around, nothing's really come of it. OTOH, a lot of the programs I run in linux seem to have their own separate scheme/lisp interpreter implementation. I could be running gnumeric (using guile), sawfish (rep), siag (siod), the Gimp (I forget what its scheme is called), and emacs (elisp) at the same time, which seems to be a wasteful setup.
Do you think there's a place for a scheme-based OS, and would your new project be useful for such a project?
(currently testing something about signatures here)
Your philosophy seems to be one of minimizing the solution and the problem at the same time. That is, not only do you write the least amount of code to solve a problem, but you also reduce the scope of the original problem to make a solution easier, sometimes drastically. What are the limits of this philosophy?
Moore rejects most of the innovations in computer architecture of the past 20-30 years. No superscalar execution units. No pipelines. No caches. No floating point. No huge memories. Just simple little stack machines with high clock rates.
Nobody seems interested. Not even the digital signal processing people, who should like the repeatable timing and be willing to put up with the tiny memories.
So the real question is, what is this for?
You have talked of writing a tiny web browser, one in line with your view that you can write any application in 1000x less code than generally available solutions. What would your approach be to writing such a browser?
This is NOT a cross-compiler - all compilation is done on the Palm: http://www.quartus.net/products/forth/. Has access to complete PalmOS API to make full applications.
My question: The spec for the x18 CPU shows 128 words of ROM and 384 words of RAM, therefore for any general purpose computations there is going to be a *LOT* of memoty thrashing. Consequently the final performance is more likely to be memory bound than anything else. The problem will only become worse as the number of CPU's on the die increased. How do you intend to deal with this issue?
I've implemented both languages (20 to 25 years ago) and find them both to be gems. Well worth studying.
Stonewolf
I'd like your thoughts on the merits of Forth vs. Postscript and Lisp or Scheme. It seems to me the VM's for these are somewhat similar; Postscript may in fact be Forth underneath, but I'm not sure? And it also seems that prefix languages are more popular than postfix languages, maybe for psychological reasons. (And infix languages are even more popular, of course.) But I suspect you believe that the implementation of postfix languages like Forth is much more efficient. Can you explain why?
Have you ever debated the merits of the two approaches with Richard Stallman?
Would it be possible to write a compiler which goes from an infix source like Java, to a Forth VM instead of a Java VM? What advantages would that have?
What happened to the "Ask FCC Chief Technologist David J. Farber" interview questions (http://slashdot.org/interviews/01/01/22/1349237.
maru
www.mp3.com/pixal
Ultratechnology.com say you are using a colorForth based CAD package called OKAD, written in only 5000 instructions. How do you plan on getting that into the market?
When I program with Forth I find myself having to write and read a lot of comments that document the intent of data movements on the stack. Languages like C where most data is stored in named variables lend themselves to writing more self documenting code because the name of each variable helps document the intent of how the data in it is used (e.g. "loopCounter"). That documentation of intent is lost when writing code that just does stack manipulations in Forth (thus the need for comments, such as descriptions of what is on the stack at any given time). Of course, you can use variables in Forth, but that defeats the elegance of using the stack. Do you have any comments on this issue or recommendations for making self documenting Forth programs with a minimum of explicit comments about intent?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Cheers, Andy! PS. My Transputer stuff ..
Andy Rabagliati
Historically, Forth started out as more or less "open source" code embodying a set of elegant and powerful ideas. In the late 1970s/early 1980s there was controversy on whether the public domain Forths were killing the commercial vendors and at the same time giving novices a bad experiences using incomplete systems compared to more complete commercial solutions. What is your current feeling about open source / free software, especially as it relates to the past, present, and future of Forth? Do you think the open source nature of Forth has helped or hurt it in the long run?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Please!
I have long been interested in using Forth as the infrastructure for other languages, for example Squeak Smalltalk. However, when I have looked into this, it seems that fairly complex environments like Lisp or Smalltalk or Python with garbage collection and other features tend to want to have a certain infrastructure of their own -- a dedicated VM in that sense. There is also a performance hit unless the Forth system effectively just bootstraps itself out of the way. Especially in the context of Forth chips, what can you tell us about the promises and perils of other languages running on top of Forth? Are there ports of any other languages to your Forth chips?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
With many parallel threads and an internal cycle time much faster than external SRAM access time, won't this chip have a lot of trouble managing locks in parallel applications?
Will this restrict the set of applications for which this chip is useful, or have you come up with a clever solution to the problem?
Your philosophy of coding emphasises (or seems to me to emphasise) many of the same things recently elaborated by the new "fad", Extreme Programming. What's your opinion on this rediscovery? How strong is the correspondance?
How, if at all, does Forth help you to do things like refactoring and unit testing in ways that other languages don't?
-Billy
Forth code is interpreted when a program is loaded and that process typically defines more static code that can then be run. However, this can makes Forth code harder to tokenize and handle in a development environment -- since you can't know the meaning of a later chunk of Forth code without evaluating the earlier part -- since the earlier part may have redefined how parsing of the later part is done. Essentially, any chunk of text in a program can be arbitrarily parsed by earlier defined words. Other languages with macro preprocessors (like C) have some of the same issues, however Forth does this spectacularly, essentially allowing a Forth program to totally redefine how subsequent parts of the program are interpreted (such as for parsing custom little languages defining data structures). Do you consider this a major strength or weakness of the Forth language, compared to languages that have a less extensible syntax (like Smalltalk). How did you think of it? Can you tell us of any especially novel or surprising ways this capability has been used?
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Someone wrote a Postscript program around 1987-88 that allowed the interpreter to compile Forth words straight from the command interpreter. It was all of two to three 8.5 x 11 pages of 12 point text, if memory serves.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
I've been reading the ultratechnology site, and I'm dissatisfied with the lack of real details. It almost seems evasive. (It reminds of the writing of new-age gurus.)
But, what I want to know is, what is that software you make really like? Can you take us through a real-world use of OKAD?
But given that some large percentage of our genome is identical from person to person, I imagine we could be stored as a diff from a "reference human" in far less space than that.
He also makes unrealistic claims and confuses toy systems with replacements for industry-standard systems.
His processor designs are poorly specified and buggy as hell, and he just kind of glosses over that (and remember to mix in 3 or 4 NOPs between each useful operation to avoid overheating the chip...). His MIP counts are inflated, because his instruction sets approach turing-tarpit level. For example, if you wanted to do 64-bit floating point operations, you'd probably need to consume 40 or 50 machine ops for each addition, never mind more complex operations.
This new chip is going to be completely I/O crippled and I doubt it will ever get past prototype stage.
OKAD is to the VLSI CAD stuff used by people like Intel and AMD as ed is to MS-Word. Sure, it's smaller, cleaner, and in some ways much more powerful, but it's also strange, hard to use, and it doesn't do the same stuff. OKAD couldn't be used to design something like the Athlon, or even something like a 486. It's made to design tiny chips, like Chuck wants to make.
He dismisses a lot of real problems. He claims that software is easy, but never writes anything hard. Everything is non-standard and isolated from the distressfully complicated real world. Basically, he makes it easy by making things nobody but he would want to use.
The machine on my desk can read, interpret, and process thousands of standard data formats, connect to other computers using dozens or hundreds of standard protocols, recompile and run many thousands of legacy programs, and emulate almost every machine more than a few years old. When I want to do high-speed graphics processing, all the slow crappy code gets out of the way and doesn't matter any more. The machine he would replace it with would do none of these things, it would require all new software and would probably cost about the same anyway, after buying the RAM, hard disk (both for the vast amounts of data I want handy, which takes up far more space than code bloat), input devices, and monitor. That is, assuming it wouldn't need costly specialized versions of these.
He's really designing specialized embedded chips, without bothering to specify (or specifying wrongly) what they are good for. A quirky Forth chip with 486-level performance, support for up to 2 megs of DRAM, and video out? What on Earth for? The toy computer in a mouse doesn't do it for me.
And the new one: basically an embedded chip design, with a turing-complete but miniscule set of primitive integer operations, copied 25 times and laid out in a square array. Why, oh, why?!
Do you know what they're talking about using it for? A replacement for PC server clusters! On the grounds that you can fit as many MIPs in one small box! Wow! 60,000 bogoMIPs! Never mind that the chief assets of a server cluster are the hard-drives and RAM...
The I/O specs? Well, you could put an SRAM controller on the edge...
Cache? 256 KWords (18-bit, of all things) off-chip, which must be managed manually. Sold seperately, O/C. Each processor has 384-word on-chip DRAM, into which you must cram your whole program, or stop to load in new instructions whenever you want to do anything else. All "cache" must be managed by code in this tiny space, too since there's no hardware support.
Speed? Multiplication (18-bit) takes 125 operations. Realistically, we're talking under 500 MIPs, before taking into account the I/O problems and the difficulty of writing good parallel code. I'd be utterly shocked if you got more than 50 MFLOPs out of it, after some very careful optimization. Yeah, it's real supercomputer material.
Now it's starting to look like a $1 chip, non?
His Color Forth is very much like the BASICs on early home computers. They also served as both OS and interface. They were about as small, too, and provided essentially the same functionality. They were also tied inextricably to one platform. Hell, even MS got its start doing this stuff.
And yeah, it would suck to be color blind. Whatever he says about using different typefaces, I wouldn't want to distinguish between 8 different kinds of text with "italic", "underlined", "italic-underlined", etc. If it worked decently, he would have used that instead of color in the first place. We're talking about a system designed around his own poor eyesight, which doesn't account for other vision problems, and doesn't provide real advantages for those with good vision. That's typical of his work: exactly what he wants, what nobody else wants.
Yes, almost everything out there is bloated and ugly. The industry could stand to improve a lot. But Chuck Moore doesn't have the answers, in many ways he's just a smart-ass infatuated with some easy answers that don't work in the real world.
On the other hand, Forth is a very nice language. I agree that it should be taught to children while they are learning arithmetic. It's as simple as languages get, and gives you an accurate model of what's going on in the computer (execute the instructions of this word, then this word, then that word...). I see it as just another language, not language/OS/universal interface. It's very, very good for small, isolated systems. Being an extensible language that relies heavily on globals, it's very, very bad for large team-effort software projects.
Basically, read his work, but take everything with a grain of salt.
---
You'd be surprised at the broadband connection available to things crawling around in your hair.
Genius is inversely proportional to website quality.
-... ---
you mean "i"?
What is the "killer app" for the stack machines you are designing?
-- clvrmnky
Among the touted benfits of Forth and the stack machine architecture are compact code size and high performance. However, you don't necessarily want to reduce the utility of an op to the point where it becomes a burden. The X18 may achieve 2400 MOPS, but when it requires 125 of them to do a multiply, performance can drop in a hurry -- and code size inflates.
The 0-operand instruction set architecture appears to be credited as the primary enabler of the benefits cited above. Yet I wonder whether the stack becomes a bottleneck. The X18 web page states, "An address register is useful to reduce stack manipulation. It also supports incrementing to address successive words in memory. Similar use of the top of the return stack provides 2 addresses for memory-memory moves." This sounds to me like a tacit admission that having only a stack for operands is problematic. From the table of opcodes listed, it looks to me like over half of the instructions in the X18 architecture just push data around -- and duplicating instructions for the address register, return stack, and data stack really sort of belies the claim of 0-operand instructions; as I see it, the operand is just encoded into the instruction.
In light of the above, I am led to wonder: How much of its time does the X18 or X25 spend manipulating the stack? How does this impact performance, code size, and programmer effort relative to an equivalent program hand-coded in assembly language or C for an architecture that uses general-purpose registers? How about Forth built for a GPR architecture? You appear to agree that more than one addressable operand register is needed. What is the right number?
I find your stack-based MISC designs very interesting. To me it seems that the basic idea is this:
When all operations are stack-based, there are no operands, only operators. That means that the only variable in each operation is the operator. Also, the Minimal Instruction Set Chip (MISC) design means that there are only a few operators to choose from. Therefore, the result of every possible operation can always be precomputed by the chip before the instruction has been fetched from RAM. Each instruction is also very small, only a few bits each.
Adding to this, the number of memory reads and writes is reduced by keeping the topmost value of the stack in a register instead of in RAM.
Is this a good overview of how your earliest MISC chips worked, and if so, how much of this has changed in your newer designs?
Why?
Many people complain about the RPN and many other argue that factor that can't be enough of a reason to spurn a language of the quality of Forth, but is it actually that maths as taught in schools the world over really does give languages like C a huge "familiarity bonus"?
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Chuck's CAD system used to design his processors is written in colorForth. That is really eating your own dogfood! I have some idea of what goes into writing a schematics and board layout CAD system from watching a couple of vendors struggle through the transition to GUI's. IC design is much harder. Amazing to see it done by one man. Can I download a copy somewhere?
Note that it wasn't used to design something equivalent to a Pentium. I think it was used to design a much simpler but not too slow CPU, and then replicate that 25 times with interconnections. And the user interface is often the hardest part of a program; Moore may have left that as simply a text console or something that takes a lot of work for anyone but the programmer to master. But still, I would think that to write a CAD program to do even that much well would take a a large programming team, and various routing algorithms that are held as trade secrets or patents by large corporations.
Mr. Moore, are the specs or a demo on the web somewhere?
So here's my question: has anyone considered adding a modern type system (e.g. Hindley-Milner) to Forth? Other typed assembly (intermediate) languages are appearing -- see http://flint.cs.yale.edu/flint/ for a nice example -- why not Forth? Static type checking in a mathematically rigorous context is a natural fit to a functional language; IMHO it's a wonderful aid to the programmer, and done right adds almost no overhead.
The trouble was, I couldn't read my code a month after I wrote it. The screen-based editor just didn't provide the flexibility I needed for documenting what I had done. Has there been work on, say, literate programming for Forth? Or even just a better editor?
Is is practical to use Forth in conjunction with an object oriented language? For example could you build a tighter Python interpreter (or JVM) in Forth rather than C? Forth seems to be closer to the machine than C, so it seems that you might be able to use Forth rather than C for portable, low level function calls.
From what I can see, current microproccessor ISAs are predominately serial, grabbing a job, filling up the pipeline blocks as well as possible, and using branch prediction/OOO to better fill the bubbles. They try to get a decent IPC, and crank it up immensly so the bubbles propigated will quickly move through the processor.
But new chip designs are moving towards a parrellel approach, either on these serial processor arhitectures (SMT, multi-core chips), or the ISA itself (HP's EPIC). EPIC and SMT fill in the bubbles more efficently, while the multi-core chips I assume just allow each thread to run on their own chip so more work can be done at the same time.
It seems to me that EPIC makes it easier on the average programmer, but harder on the compiler desginers. SMT boosts the incentive of using threading by programmers, and multi-core really forces programmers to deal with threads for optimal performance. Since threads can be a hassle, EPIC to me seems the cleanest.
As a chip designer, where do you think the future of microprocessor desgins should and will go? As someone who designed a multi-core chip, why did you choose this route?
"Open Source?" - Press any key to continue
I used Forth many years ago. When you wanted a development system ported quickly, it was an excellent choice. The downside of Forth is when you started developing large programs. It's simply not a good choice because it is such a read only language.
The part I hated the most about Forth was the fanatism of its followers. I remember one argument where the zealot insisted an optimized Forth program is faster than assembly language. That is an outrageous statement completely unsupported by the facts, yet he would not relent even after I proved otherwise.
I've since learned not to argue with religious fanatics.
-- Will program for bandwidth
I use a DvortyBoard (http://www.dvortyboards.com, ~$70). It's equivalent to a fairly cheap PC keyboard, but nice because 1) it's cheap compared to the fancy ergonomic models, 2) it's dual-labeled for Qwerty and Dvorak, and 3) you can switch it between the two modes with a single keypress (it's hard-wired). Comes in handy when your significant other (who can't/won't learn to remap the keyboard) needs to use the computer. Remapping is a pain in its own right, anyway.
Read my keyboard review.
Can you explain why Forth software tends to scale logarithmically in size as application complexity grows, as opposed to linear or exponential scaling of more mainstream development practices? As a longtime Forth follower, I understand this phenomenon to be a result of highly aggressive modularization, which you call "factoring. Can you describe how this seems to be more successful in Forth?
Forth could work really effectively in that environment, and Chuck got traction. But I think he is on a mission of a higher level, which I struggled to understand as a radio astronomer. It was about complexity before there was "complexity" as a theory. It's also about being "green" - using the hardware's capability fully. No bit or gate goes unused. No more RAM or I/O than is minimally required. It's about using your brains - it's a good thing to spend a whole day getting one line of code right.
So my question to an old friend - is the meaning in the Destination or in the Journey? Does Forth's market penetration matter at all? Or is it the fact that a few of us see the world a little more clearly?
-Martin Ewing
Fiat Lux.
When I built my first Internet node, the web did not yet exist, and one of the amazing things about the Internet was how friendly it was to the blind.
Now, with some computer experts estimating that over 50% of the Internet is incomprehensible to braille interfaces, and most computer operating systems devolving to caveman interfaces ("point at the pretty pictures and grunt") we seem to be ready to take the next step - disenfranchising the merely color-blind.
I realize that colorforth is not inherently discriminatory, in that there are a great many other languages that can be used to do the same work. The web is also not inherently discriminatory, because it does not force site designers to design pages as stupidly as, for example, Hewlett-Packard.
Would you care to comment on the situation, speaking as a tool designer? How would you feel if a talented programmer were unable to get a job due to a requirement for colored sight?
--Charlie
Wouldn't this make Forth and similar small-footprint environments a natural choice for devices such as sub-$100 PDA's, and why does it seem that line of development is completely unexplored?
-jhp
/. -- the Free Republic of technology.
You have said in the past (or at least implied) that portability of system and application code is not worthwhile, which flies in the face of software industry. How do you justify this position considering the popularity and success of systems and tools designed for portability such as *BSD, Linux and the GNU toolset?
Similarly, you complain that use of software libraries tend to provide solutions that are bloated, slow, and otherwise sub-optimal. Obviously, some common set of routines or primitives is required. What is, in your view, the proper level of abstraction for the core set of software routines? What do common libraries (C Standard Library, Win32 API, Qt, etc) get wrong? Are there not may application domains where programmer productivity outweighs run-time costs? Conversely, which application domains really demand the custom-fit, non-library approach?
Do you get more income from licensing your designs and related technology? From consulting? From something else? Is there much room for a "computer cowboy" in the industry?
If forth is as amazing as you state, why aren't standard linux drivers being ported to it? Your 1:100 lines of code forth to C proposition makes it sound like coding drivers should be a couple-hundred-line walk in the park.
I think you need to avoid the pitfall of thinking of a processor such as the 25x as general purpose. If this works, you're talking about more fundamental applications, like graphics processors, drive controllers, etc. implemented on a general purpose (sort of) processor. It would be very sweet to upgrade my video card with a software download - and not just like bug fixes and patches but whole new algorithms etc.
It's applications in communications are even more profound...
The way Forth is designed is not the way we learn to read, mathematics or many other things.
What is great to make the language compact and efficent is just plain horrible when a human tries to read the code.
I can have a go to try to understand code in other languages written by programmers with little regard for the people that will read the code. Such programmers writing Forth make the task impossible.
IANAL but write like a drunk one.
Yes. Mr. Moore, don't you think Flanders is a big jerk?
(10 bucks says this will be my first Homer quote that doesn't get modded up to at least 4!)
AC's cheerfully ignored
In his 1977 Turing Lecture, John Backus challenged computists to break free of what he called "the von Neumann bottleneck". One of the offshoots of that challenge was work on massive parallelism based on combinator calculus, a branch of mathematics that is far closer to Forth's formalism than parameter list systems (which are more or less lambda calculus derivatives). The prolific Forth afficionado Philip Koopman did some work on combinator reduction related to Forth but seems not to have followed through with implementations that realize the potential for massive parallelism that were pursued in the early 1980s by adherents of Backus's Formal Functional Programming paradigm. Given recent advances in hierarchical grammar compression algorithms, such as SEQUITUR, that are one step away from producing combinator programs as their output, and your own statements that Forth programming consists largely of compressing idiomatic sequences, it seems Backus's original challenge to create massively parallel Formal Functional Programming machines in hardware are near realization with your new chips -- lacking only some mapping of the early work on combinator reduction machines. It is almost certainly the case you are aware of the relationship between combinator reduction machines and Forth machines -- and of Backus's challenge. What have you been doing toward the end of unifying these two branches of endeavor so that the software engineering advantages sought by Backus are actualized by Forth machines of your recent designs?
Seastead this.
Historically, Forth has been strong in environments such as embedded systems where small code size was of paramount importance. In such environments, as in color Forth, the OS is also written in Forth. Do you see any role for Forth (color Forth or any other dialect) as a language that can be used productively on top of a standard OS e.g. Linux? Or does Forth have to control the whole show in order for its strengths to show themselves?
I don't know much about hardware design, being mostly a software guy, but I wonder if the job of pumping data to the processors couldn't be done by just one of the 25 processors.
In order to do this, it would have to communicate with the other 24 processors, to see how many instructions they have in their cache. Since there are 5 horizontal and 5 vertical buses, other processors would have to be "routers" for the data. If the top left CPU was handling the caching, then the left edge (4 CPUs under the top left) would hand off messages. 4 of the CPUs (to the right of the top left) would be able to send directly to the cache CPU (as would the left edge).
Another simpler idea is to have 5 of the CPUs (the top row) handle the caching, so each one can communicate with the other 4 CPUs in its column. And if necessary, the cache CPUs can talk to each other.
Since there are 384 words in each processor, the topmost processor in each column could load 96 words for each of its 4 CPUs. Then, feeding them more instructions would be as fast as the CPU bus.
Perhaps he could even make the cache CPUs different than the rest -- so they have more memory, 1536 words, so they can cache 384 words for each processor. And tweak them for memory access.
Question? What do you think of the above?
I feel fantastic, and I'm still alive.
I have always thought that Forth has a certain Taoist approach to the issue of computer programming and problem solving (not to mention that binary computers do all their magic by means of the interaction of the 0 and the 1, like the Yin and Yang). Note that, while I don't consider myself as a Taoist, I try to see the metaphysical and the practical side of things. In an interview about retrocomputing for the Spanish magazine Arroba, I said just that Forth could help in understanding the Universe, as everything in it is an active process, much like in Forth everything is an executable word, even variables.
Now, my question is: What kind of metaphysical/philosophical implications do you think Forth has, and what are your inspiration sources? Thank you.
algebraic notation is much easier for humans to comprehend than reverse polish notation
Not necessarily. Most English-like languages follow verb-object (VO) order (print x), but speakers of object-verb (OV) languages such as Japanese and Klingon tend to be more comfortable with programming languages that follow object-verb order (x print)
By the same token, infix notation (3 + 5) comes naturally only to those whose natural languages are infix, which includes most of Europe and the Americas. However, Irish and several Afroasiatic languages are prefix, which makes the (+ 3 5) syntax of Scheme more palatable, whereas Japanese is postfix (3 5 +) like Forth.
See also Fith
Will I retire or break 10K?
More recently I've taken up the study of Scheme, and I must say, I feel alot of similarity between the two worldviews.
But my daily work is Perl and C, doing web-applications. And I'm trying to break into the games industry. Both of these types of work share something in common: Code and "content" (business rules, user interface, etc) are tightly bound together and are difficult to abstract apart from each other. You'd think that a language that encourages easy extension and manipulation would be ideal in environments that have frequently changing demands. Nope.
Because my code has to interface with systems I don't have control over, and that those systems operate in a fashion difficult to cope with if your language doesn't share similar data abstractions, I have to use the same tools. Essentially, because I can't re-write everthing that my apps have to cope with, I need to use tools that make working with those external resources easier.
A convoluted way of saying: Because 3dsmax is a common modeling system, and that many, many programs work with its format, I have to as well, and I need tools which make that easier.
But I love the power and flexibility that the less-popular languages offer, such as Forth and Scheme. I'd love to be able to use those languages in my daily work.
I realize that Forth may not be the best language for, say, web development, but that is only because no one has bothered to write the tools and extensions to make it better. But in order to cope with highly structured data (like the results from an SQL query), wouldn't a type system be a useful core feature?
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
CHuck, being somewhat of an old time Forth nut , first let me point out that I'm a big fan. It was(is!) one of the most elegantly simple languages yet blitzkreigingly fast languages I've come across. Everything is a stack. Simple!
Anyway, One of the thing's I've liked about forth is that implementing a simple (subset) compiler for new platforms is stupidly easy for forth, I've rattled of basic compilers for subsets of forth in single days in the past. Was this a design consideration when you designed the language?
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
First a question that might be of interest to a broad audience:
If your designs are truly asynchronous then their performance will noticibly change with variations in process. How does a supplier explain why units sold on a Tuesday work faster than items on a Wednesday? With synchronous logic we (with the exception of the overclockers) generally give up some performance but get consistent performance by using the same clock rate on all systems. I ask this question because Weitek once made a Sparc FPU which could operate faster than a competitor's by enabling a special mode, but Sun would not use that mode because they didn't want customers complaining that they got a "lemon" with one of the slower chips. (They required a second source.)
And to round it out how about some detail for the hardware guys in the audience:
What tools/languages do you use for design, simulation, synthesis, test generation, place and route, clock tree synthesis, timing analysis, boundary scan, power estimation,...? Do you use Unix? Source code control? Have you tried prototyping in the Xilinx Virtex FPGAs?
Have you gone away from the COT (customer own tools) approach? Do you use vendor supplied libraries? If not how do you validate your libraries?
Have any of your hardware designs go into full production? What yields did you achieve?
How easy is it for somebody to integrate your cores into their own ASIC? Can any Verilog RTL jock do it, or do you need experienced full custom chip designer expertise and a COT flow?
Things are not as they appear, nor are they otherwise.
As a seasoned FORTHer [I used CSI MultiForth and then the excellent jFORTH by Phil Burk to write my popular program RGS - and others - for the AMIGA], I can say, Yes, there are object oriented FORTHs, such as ODE (Phil Burk again.. the basis of HMSL) and NEON.
FORTH is different form other langauges in that every "program" actually is an extension to the language, and you can also create compilers and assemblers very simply. Once you have wrapped a FORTH word around a piece of hardware, you can abstract it as far as you want to!
-- Real Stupidity is the Artificial Intelligence of the 21st century
One starts understanding Forth by thinking small. What makes Forth still an attraction for many computer users, even after three decades, is what made it so attractive in the first place. It goes very fast in very small places. In the 1970's, Forth was attractive because all computers were small. Today, there are still many applications that have need for small programs on small hardware. NASA uses Forth in space. Almost any application that puts a premium on small program size could use Forth. The embedded market comes to mind.
Forth is its own language, its own development system, its own API, and its own user interface. (Some also say that Forth is its own religion, but I digress.) Traditionally, Forth is built directly on top of the hardware so there is usually no operating system. This is something which it does particularly easily and well. With Forth, one doesn't need an OS. That hasn't stopped people from extending Forth so that it does run on an operating system. There are multiple Forth implementations for Linux. There's one that runs on the Palm Pilot, too.
Forth is extremely interactive. Working in Forth means interacting with Forth from beginning to end of a project. Forth is its own toolset. It includes editors, compilers, interpreters, etc. Often sophisticated tools unheard-of in other computing domains are available, like meta-compilers for compiling whole Forth systems from old ones, decompilers and disassemblers for creating source code from compiled code, and other fanciful things.
Windows users inevitably chafe at Forth. Not able to understand a simple Unux console where one is able to do everything a Windows user can do, the Forth console seems like a desert. To every typed command it responds with either cryptic gibberish or the equally puzzling ok. There is not only no graphical hand-holding, there isn't even an operating system to comfort the user. To the uninitiated it seems unnecessarily barren. To the everyday Forth user, that's just fine.
The Forth language and tools are small. There is only a rudimentary parser implementing an absolutely context-free and grammar free language. There is no error trapping unless you put it in yourself. All data is stored on a push down stack which operates with RPN just like an HP calculator. Floating point is not supported, but powerful rational integer arithmetic is. Savants won't have to dust off their rational approximations.
The language has compiler building elements built into it. You can create your own mini-compilers at will. The fact that floating point isn't part of Forth doesn't mean that it can't be. There are all sorts of extensions available for any number of purposes, including floating point and a bazillion operating system ports.
Although there is an ANSI standard, don't bet that adherence to the standard will mean code will be portable. Generally, so much of any given Forth installation is local enhancement, code just can't be made portable. Then there's the OS problem. A Forth running on top of an operating system is guaranteed to be non-portable to anything other than an identical installation. At least in the pure Forth environment one doesn't have the OS in the way of the standard Forth core functionality.
The Forth language is composed of a collection of words, each of which contains the implementation of a particular computing task. Forth words can be considered like functions in any of the more traditional computer languages. Where Forth differs is in the details of the implementation and the extent to which the Forth model is implemented throughout the system.
At the bottom, Forth starts with a core set of words which are written in the native language of the processor. But with Forth, even these core elements are not traditional machine language. All of Forth, including its machine language core, is implemented in Forth. Although Forth's machine code core is executed directly by the CPU, the entire process is under complete control of the Forth interpreter. Forth isn't slowed down by this interpreter control. The interpreter gets out of the way so that the native code runs at native code speed.
The Forth interpreter is tiny, even miniscule. On the general purpose processors of today, a Forth interpreter inner loop is a trivial task, often composed of a single CPU instruction which is assembled wherever it is needed. This kind of efficiency fairly screams for a hardware implementation. Thus, there are small, inexpensive processor chips which implement Forth in hardware.
The body of a Forth word is composed of two main elements, a code field and a data field. The code field contains the address of native code which executes the word; the data field contains information which depends on the type of word. For words coded in native code, the data field contains the actual assembled machine instructions for the word. The code field of such a word then points directly to the first machine instruction in the data field. For normal high level interpreted Forth, the data field contains the sequence of code field addresses of the Forth words that make up its definition. The word's code field then points to the Forth interpreter.
The inner loop of a typical Forth interpreter steps through the list of code field addresses in the data field of a word, dereferencing each, and passing the result to the CPU's instruction pointer for execution. On many architectures this is a single CPU instruction. If the referenced word is another high level Forth word, the current interpretive address is saved on the return stack (push context) and the interpreter inner loop is reentered at the next lower level. If the referenced word is one implemented in native code, nothing more need be done since the inner loop will have already pointed the CPU to the word's native code.
Each Forth word ends by jumping to the code that pops the stack to restore the interpreter to its context before it began executing the current word. Often a single instruction, this code is usually assembled in situ.
From another point of view, the Forth interpreter threads its way through the code until it eventually bottoms out at a word defined in native code, which the processor merely executes.
The reduction of a function call to a bare address saves considerable space. The interpreter for such encoding is so small that it can be placed in situ. There are Forth implementations which save the dereferencing step in the interpreter inner loop by placing the code in-line in the code field. Forgoing floating point for near native rational integer math adds tremendous efficiency. All of these savings are replicated from top to bottom in any Forth implementation. It's not surprising that compiled Forth is much smaller than almost any computer language known. Typically, entire Forth implementations are tens of kilobytes, not megabytes. Typical run-time programs are often very few kilobytes. That's tiny. To top it off, they run at near native code speed. That's fast and tiny.
Therein lies the longevity of Forth.
Want to know more?
Try the History of Forth at Forth, Inc.
When I write to the metal, I use assembly. Writing assembly is intuitive, easy to read, and with architecture knowledge and some thought, very efficient. (For some people, almost as efficient as theoretically possible.)
This article got me looking at Forth for the first time; and I must say, it's not reader-friendly. It is perhaps one of the ugliest, most difficult to read languages I've ever seen. Brainfuc% made more sense to me! (Note, I didn't try to _write_ any Forth. You tell me how difficult that is...)
My impression after going over Forth programs is that programs written in Forth are small because large ones would be suicidal. The gains over assembly and C seem to be from feature-loss rather than any advantage of the language.
Perhaps worse than Forth itself is the creator of the language, or rather, the claims he makes. He makes amazing claims about speed and size with about the same level of professionalism as claiming "Compute with amazing crystal power! The computing power of Atlantis could be yours!"--and with about as much evidece to back up his claims. Am I to believe a computer scientist on faith?
After claims of programs that are so many 1000's of times smaller and so many 10's of times faster, I finally (and with great effort) get enough detail on his programs to discover how this is: they are all but non-functional. His programs have been stripped down to the point at which there is almost no possible use for them; and have consequently attracted almost no users.
I prefer minimalism--I can enjoy Mozart as well as the next guy--but this is two 32'nd notes and nearly a staff.
I'm skeptical, as anyone should be. He claims that for 30 years, and after uncounted billions of dollars spent, computer scientists were just doing it wrong. He would propose a "superior" alternative. Programs that are faster and smaller, chips that use less power and are far cheaper, so on. All untrue claims.
Give this man the crackpot award. Maybe some brownie points if he really believes in what he's doing. Just don't get Chuck, Katz, and Alex Chiu together in the same room.
Most users (and I have to include myself here) are not overly interested in underlying architectures, only in running the game, office and browsing applications that are the consumers of 99.99% of the CPU cycles out there. These applications are built on top of a large pile of software layers virtualizing the CPU, memory, storage devices and network architectures. These layers also provide familiar (POSIX for instance) interfaces for the application designers to use.
Here lies the basic problem with new low level architectures: The applications will not be produced for these architectures because those middle layers do not exist - and vice versa. Radicaly different architectures (and massively parallel CPUs such as the yours fall into this category) have even larger problems because not only do the lower layers do not exist, but the theoretical work to properly exploit them are not well developed, and competence to use (for instance) highly multiple threading at those and the application level do not exist in the developer community.
This makes the already huge barrier to entry to new processors into a mountain range insofar as large market penetration (which can only be acheived by supplying those end user applications).
So...while I believe that the hardware is deeply cool, my questions are:
1) Raw CPU power is well and good, but it is just 'revving the engine' without the (large) software virtualization layers needed to exploit it. Where do expect that software to come from?
2) How many people to you expect to purchase/use these CPUs without application software? Without even hardware virtualization?
3) Do you have in mind any 'killer application' that would enable this design to survive perhaps in some niches?
Now, this might sound that I am being very negative here - and in a sense I am - but not because I do not believe the future of massively parallel processing (MPP) (because I DO believe!), but because there have been no shortage of similar approaches in the past (transputer for instance) that have hit the same barrrier reef and foundered, either sinking out of site immediately or surviving in undeserved exile in some tiny niche applications.
It seems to me that to enable this sort of MPP entrant to succeed needs a concerted effort to
a) Enable affordable access to motherboards
b) 'Conventional' language support (gcc?)
c) Software virtualization for the hardware etc. i.e. an operating system
d) Drivers
e) Training in multii-threading development.
If this seems to be a lot of work that is because it is!
If I am not mistaken, the FreeBSD bootloader is a Fourth interpreter. If you look at /boot you will see a few Forth scripts that comprise the default bootloader and "libraries". You seem to be able to write your own boot logic.
Somebody please correct me if I am wrong.
-j
Do you see applications for the x25 processor in areas such as brute force code breaking? This is not an i/o intensive process and it would be relatively cheap to build an array of x25 processors and offload part of the keyspace to each of them. In terms of $/key this is probably more effective than building custom processors.
Usually VM are stack-based because it is simpler, I think.
But the Tao-VM (used by these "Amiga" guys) is based on an unbounded set of register, I heard that they claim that it is the fastest VM..
Have you looked at the Tao-VM ?
I remember of flamewars in rec.comp.arch about register-based architecture vs stack-based architecture of CPU.
I think that there is the same design issue for VM..
Perhaps the major problem for contemporary processors is the latency of memory accesses. Adding still more levels of caching offers rapidly diminishing returns. While using short machine instructions will be of some help in reducing I-cache misses (although with the unfortunate prevalence of OO languages even this probably won't make much difference), it does nothing for the D-cache hit rate still leaving you with the problem of branch prediction and all the complications that entails for the CPU design (I'd hate to have to try to design an n-way speculative execution unit for a stack based architecture). Do you have anything in mind that might help resolve the latency problem?
My second question concerns Forth. Many virtual machines are stack based because compiling to such architectures is perceived as being easier than for register models. This is a highly contentious assumption and it is certainly the case that generating fast object code for stack architectures is much harder (the program tends to spend much of its time rearranging the stack; the alternative is to keep variables on the heap in memory, but then you lose the advantage of having local variables stored locally in processor registers or on its stack). So while one might argue it may be possible to get higher theoretical peak processing power on a minimalist stack processor (see my first question), do you think it's worth it given the difficulty of generating fast object code for such designs?
Have you seen other projects that aim towards minimalization and what do you think of the direction they have choosen to follow? What projects (commercial, univerisity, or open) do you see as heading in a very good direction?
The Elaboration:
Specifically, on the hardware side, the Pinky 1 bit processor with 4 instructions seems near your chip design philosophy: small and smaller. Have you had a chance to look at the ideas behind it? And on the software side, do you see any programming languages headed in The Right Direction? Such as the APL branches of J and K, where the community sees code concision playing a very important role in understanding and maintainability. [A slight warning: I am now a convert of the K and KDB religion, so I am definitely biased. If Arthur Whitney can out code Oracle, it must say something about K; my fragile little mind is still disturbed by some of his golf scores.]
The Thanks:
Also, thanks for Fourth. I arrived there via excursions into PostScript and Joy and try to use it often.
-j
Its design grew very unambitious towards the end, its just a couple of grad's tieing up the loose ends towards their Phd's... the real work is now being done in the Aries group (http://www.ai.mit.edu/projects/aries/).
For Chuck: To what do you attribute FORTH's falling off of just about all programmers' radar screens?
I am the Lorvax, I speak for the machines.
What are your predictions on free hardware?
This leads to the saying "if you don't like Forth, then it's your own falt". Meaning that the language is self-extensible and if it is missing something that you need/require/want then you should just add it. I've used OO systems for Forth which I thought were quite nice. It wouldn't be such a simple feet to add OO to some other langages (witness C->C++).
I took a look at UltraTechnology.com to understand your philosophy of ultrasimplicity. Two questions based on this philosophy: .. for example: gemstone+enhydra+apache.
=>Do you see forth working with the rest of the world's protocol standards (TCP, LDAP, XML, etc), or being isolated?
=>How would you apply your ideas to cases where large numbers of people (10^4 or more) have to share large amounts of data (100 Gb +), a situation today requiring something like a database , a metalayer product, and a webserver
...that's where I get all my information.
His claims about software are unrealistic for most other people, but accurately describe the software that matches well to his chips.
The problem is that you guys don't admit that this is a limited problem domain, specifically: easy problems that are neither memory nor computation intensive. You pretend that it has to do with the approach to creating the software, not the problem you need to solve. And for these problems, you don't need much power, so your painstakingly optimized software performs decently on these low-power chips.
You people don't have much of a clue, really, about the systems you're comparing yours to.
Our multitasker and memory manager with garabage collection and device managemnt fit in 1K. The jpg file read, decode, and display routine fit in 1K. The GUI library fit in a couple of K.
Ooo... A handful of trivial operations in a few K! I'm impressed!
Your "multitasker" is a cooperative multitasker without any real load management. Your "memory manager" is trivial garbage collection on a small, single page of RAM. Neither have any sort of protection against poorly written or hostile code. Crack open Knuth's TAoCP and see these functions implemented in a few dozen assembly instructions. Nothing new at all. I could write them with my eyes closed.
GUI library? Yeah, just like the toy ones commonly written into game engines. Ooo, but this one is skinned like Windows, so it must be functionally equivalent to Windows! I've written little GUI libraries that manage sprites and text, windows, focus, and mouse-clicks, in a day or two. They're toys, and they're utterly trivial once you figure out how to lay down pixels efficiently. Making one with a rich supply of widgets, support for multiple languages, and a component model is much harder.
Wow, a JPEG decoder! I'm impressed that you reimplemented a standard and hand-compressed the code instead of just using one of several completely free C implementations that have been tested and debugged for years. With how many thousands of test files from different sources did you test your implementation to be sure that it is real-world ready? And you managed to reduce the memory-needs of decompessing a 600X400 JPEG file from about a megabyte of image data (pre- and post-compression taken together) + 20k of code to about a megabyte of image data + 1k of code! Very sound software-engineering practice, I'm sure. You really know how to set your priorities.
And all this code was used in... what product did you put to market again? Since you're so sure of real-world applicability, you must be making an absolute fortune from your vastly superior development methods...
Most importantly, these things aren't portable or flexible in the least. They're hacks for one monolithic system, written all crammed together so that if you lose the original implementor, almost nobody will be able to read them. A thing like Linux or Windows is written to be very flexible and support a wide variety of commodity hardware, so you don't have to rewrite every piece of software when you upgrade one part.
Upgradability is very important. You can't access the web from a static platform, because the web is always changing, not just the content, but the specifications. This is why "information appliances" fail in the marketplace. If the architecture isn't tolerant of faults in these components, then the system doesn't work. That is why all the "unnecessary bloat" of defensive coding is used.
Don't get me wrong, you've made a very pretty little imitation airfields out of rocks and coconuts, I just haven't seen any cargo planes dropping off supplies.
Real programs, not bogomips.
Another example of how you people don't understand the performance numbers you use. BogoMIPS are a measure of unproductive operations (NOPs). The MIPS Chuck gives are essentially the bogoMIPS count. A technically and ethically sound MIPS rating would average over standard, common operations such as multiplication of numbers stored in main memory. Just because you're running programs on the system doesn't make your numbers anything but bogoMIPS.
He's suggesting supercomputer use, advertising 60000 MIPS, when the standard supercomputer reference, GFLOPS, probably comes in somewhere around 0.02 (seriously, think about doing a 64-bit floating-point multiply on these things, and don't you dare wave your hands and say that people shopping for supercomputers shouldn't be using 64-bit floats), compared to around 1 for a fairly standard desktop chip.
It's fun to play around with seeing how much you can cram into tiny programs, and sometimes it's useful. But most of the time, it's more sensible to write portable, readable code. And it would be loads of fun to play around with chip designs, but you can't just optimize for bogoMIPS and then claim effectively infinite performance by hand-waving over the I/O and programming for the freakish architecture. If you make bizarre, specialized chips you either have a realistic market or you're playing around. Chuck's just having fun, then mistaking fun for good product.
Worse, you're all mistaking an engineer at play, duplicating decades-old work, for someone doing cutting-edge research. (Ultratechnology indeed!)
There is nothing new about the idea of just putting multiple processors on one die, on a simple network. Nobody does it because it's too much of a pain to use. Parallel programming isn't easy. But it sure is an easy way to inflate your MIPS rating.
There's nothing new about tiny MISC chips. They're too hard to program and require too much cache to execute large programs efficiently. Go back in time a bit, and you'll see similar things all over the place. Look around the rest of the embedded industry, and you'll see equally small, cheap, efficient chips, with adequate performance and all sorts of different nifty specialized features, that don't require you to code everything from scratch.
There's nothing new about tiny programs. You can only do so much with tiny programs! The real world is messy, and dealing with everyone else's standards and bugs makes programs necessarily big (and lazy programmers make programs unnecessarily huge, but that's another issue).
a 2400 MIPS cpu you can route gigabit datastreams on separare I/O pins and do megahertz analog signals on other I/O pins at the same time.
Yes, it will make a very lovely piece of wire, once you build up a whole supercomputing architecture around it to feed it these gigabit datastreams, though there's no room for routing tables or anything like that.
---
You'd be surprised at the broadband connection available to things crawling around in your hair.
Assembly and forth are wonderful for systems that are limited by memory or time. That said, why isn't the colorforth system you made available on your website useable by pre-pentium pcs?
gforth (GnuForth -- check your favorite Gnu mirror, and available with Linux binaries) comes with three Object Oriented wordsets. One, a minimalist approach (that is, a "one screener", or toolkit within 16 lines), and two more full fledged versions.
The focus of much paid Forth work in the embedded environment means that there aren't as many generically useful public libraries as many newer languages, but it'll get there eventually.
I think you hit the nail on the head ... it's willingness to have a go. Elizabeth Rather from Forth Inc. says that when they run their Forth classes for, say, hardware systems engineers, they are doing useful things within a day or two and are competent in a week.
... FIX IT!!!".
... just as unreadable as any newly created language without proper documentation. Just as unreadable, in fact, as C code would be to someone who did not have access to documentation about C.
Of course, if you are used to infix "+", then getting used to also being able to see "take 5 and 4. add 'em." is a hurdle, but not a big one at all. Having the attitude of "prove to me without a shadow of a doubt that there is any purpose to me learning to see operators in an active 'just do it' sense" is a much bigger hurdle.
Similarly, learning to read "IF THEN" to mean
test IF-true this-action THEN-continue-with that-action
is a little hurdle to someone who comes in with an open mind, and a big hurdle to someone who comes in with an attitude of "that's not what I'm used to
The real benefit in readability comes when the stack operators and most of the standard FORTH words are used to define words that apply to the situation, and you can get code that reads like
XY-COORDS? IF XY>POLAR THEN
GET-OFFSET APPLY-OFFSET
The danger is the Forth technique of extending the language to fit the problem. There are so many Forth coders who are not trained in effective commenting techniques for Forth. Also, in so many of the places that Forth is used, it is used by one or a few people as a personal productivity tool, so there are no "house standard rules" for naming and documentation. It certainly can become unreadable
Suppose that you have one I/O and coordinator processor, and the other processors divided into eight work gangs of three processors each.
XX XX IO XX XX
XX XX XX XX XX
XX XX XX XX XX
XX XX XX XX XX
XX XX XX XX XX
Then each work gang has a supervisor, the 1 processor, and two followers, the "2", and "3" processors:
11 21 IO 31 41
12 22 51 52 53
63 62 61 32 42
13 23 71 72 73
83 82 81 33 43
Notice that each work gang has its own dedicated row or column. Also, notice that three work gangs have each member on the outside, one has two, and the other four (2, 5, 6 and 7) have a single member on the outside edge, so you have natural specialisation between tasks requiring more memory access intensive processes and more processing intensive tasks, if it is handy for the application.
Similarly, six work gangs of four could be:
11 21 IO 31 41
12 22 51 54 42
13 23 52 32 43
14 24 53 33 44
62 63 61 34 64
Anyway, I reckon that's how it would go.
I, in fact, used a Forth that almost did that. Not in the part read by the human, but in the part read by the computer. In severely RAM constrained systems, it made every bit as much sense as 2 bytes for the year in a date. This was a Forth for the Commodore 64, which I bought at a time that standard RAM for a PC was 128 and maximum RAM was 640K (not that normal people would ever need more than 256K, excpet as RAMDisk), and the way it made the Commodore 64 glacially slow disk drive tolerable while developing was by allocating a lot of that 64K RAM to block buffers.
ANS Standard, as many people have mentioned, required 31 retained characters minimum. And if you have names more than 31 characters long, it normally means that you need vocabularies and you are not using them (just as in C it would mean that you need to structure your functions somehow and are not doing so) -- the equivalent of ProcessFooBarReadTilDone is, with one deep vocabularies,
FooBar-Process Read-Til-Done
which means you have 31 characters for family and 31 characters for operation.
"Production -> Unfortunately the Internet appliance market has not grown as big or as fast as we had hoped it would."
The next big growth market will be in mobiles (cellphones back home in the US) with flexible voice/text messaging on as many channels as possible. That's at the stage of mid 1980's PC's, when a number of people have gotten used to it, but capabilities are sufficiently constrained that a new unit with a big step ahead will bring in a big upgrade as well as new user market.
To say that human genetic code is 700 MB large doesn't mean what you think it means! It means that there is a limit of 2 to the 8*700 million power, 2^5600000000 different possible genetic possibilities, if we were to just twiddle all the bits. Not that that would produce good results. But that is about 1x10^2800000000 different possibilities, which is a very healthy infinity for all practical purposes. Not 700 million possibilities or whatever you thought. 700 million bytes most certainly can describe human (genetic) uniqueness, etc.
Hello Chuck,
I dug up a quote attributed to you from an interview on Vancouver's CKNW radio station (host: Bill Good ) on September 19, 1991 (almost 10 yrs. ago!):
"Nanotechnology is something I'm really interested in. That's one reason my computers are getting smaller and simpler. I think I've got one of the few computer architectures that realistically can be programmed on a molecular level."
What are your current thoughts on this subject?
True: all you have to do is to provide the Forth words that change "color state" and use them to change the color token instead of saving them as text, since its seems that they are completely recoverable from the color text tokens.
And, indeed, as long as a screen reader knows how to read them as Forth words, you are set.
But all that the colors mean are one of a small number of states. Male/Female, low/high normal/firm tones of voice give eight different tones for the different "colors", and sorting them into a mneumonic hierarchy would make that an easy one to keep track of.
Similarly for color blind, italic, bold, and underlined give eight different possiblities, and the same hierarchy would make that as mneumonic for the color blind.
Since the "next color" spaces are just TOKENS, all you need is a display device that treats the tokens as changing some other state, and you are in business.
The point of the color source editor is that each word shows how it should be interpreted. There is no need to keep track.