Slashdot Mirror

It is presumably an attempt at a joke based on the fact that Forth makes use of RPN.
https://en.wikipedia.org/wiki/...

I for one find Forth to be a fascinating language. The fact that it has been around for a while does not diminish it in any way.

I first heard of it back in the 80's while learning assembler on the 6502. I noticed it again while getting to know FreeBSD (loader stage 3) and decided to finally learn it when I came across some old manuals and software for my newly acquired PET CBM 8032 just a few weeks ago.

Ever since, I seem to notice it mentioned more and more, perhaps partly because of renewed interest in stack machines, but also because it offers an interactive way to boot strap a very small system with minimal resources.

It is available in some form on almost every platform that I know.

Following are some resources that I have found to be of interest. Hopefully those sites will not get badly hurt.

http://www.forth.com/starting-...
http://thinking-forth.sourcefo...
http://playground.arduino.cc/C....
https://www.freebsd.org/cgi/ma...
https://uwaterloo.ca/independe...
http://www.ultratechnology.com...

...

That's an old idea. The classic "one instruction" is "subtract, store, and branch if negative". This works, but the instructions are rather big, since each has both an operand address and a branch address.

Once you have your one instruction, you need a macroassembler, because you're going to be generating long code sequences for simple operations like "call". Then you write the subroutine library, for shifting, multiplication, division, etc.

It's a lose on performance. It's a lose on code density. And the guy needed a 1,000,000 gate FPGA to implement it, which is huge for what he's doing. Chuck Moore's original Forth chip, from 1985 had less than 4,000 gates, and delivered good performance, with one Forth word executed per clock.

Use OKAD, it's commercial quality and will fit on a floppy disk.

Seriously: http://www.colorforth.com/vlsi.html

Don't let the old-school lack of whizz-bang on the website fool you, this real stuff

http://www.ultratechnology.com/color4th.html

You're probably not smart enough for it.

http://www.c2.com/cgi/wiki?ColorForth

I'm not. I can't even find a download link or a sales page.

http://modest-proposals.com/colorForth.htm

Sam

Back in 2000 I realized that 50 Million transistors of 4004 the first processor ever created, would out perform a P4 with the same transistor count done in the same fab running at the same clock rates. it would be over 10x faster I work out. But how to use such a device?
I had been working with a 100 PC cluster of P4 based systems to do H.264 HDTV compression in realtime. I spread the compression function across the cluster using each system to work on a small part of the problem and flow the data across the CPU's.

Based on this I wanted to build an array of processors on one chip, but I am not a silicon person, just software, driver and some basic electronics. So I looked at various FPGA cores, Arm, MIPS, etc. Then I went to a talk giving by Chuck Moore, author of the language FORTH. He had been building his own CPU's for many years using his own custom tools.

I worked with Chuck Moore for about a year in 2001/2002 on creating a massive multi core processor based on Chucks stack processor.

The Idea was instead of having 1,2 or 4 large processor to have 49 (7 * 7) small light but fast processors in one chip. This would be for tacking a different set of problems then your classic cpus'. It wouldn't be for running and OS or word processing, but for Multimedia, and cryptography, and other mathematic problems.

The idea was to flow data across the array of processors.
Each processor would run at 6Ghz, with 64K word of Ram each.
21 Bit wide words and bus (based off of F21 processor)
this allows for 4x 5bit instructions on a stack processor that only has 32 instructions.
Since it's a stack processor they run more efficiently. So in 16K transistors, 4000 gates,
the F21 at 500 Mhz performed about the same as a 500Mhz 486 with JPEG compress and decompress.
With the parallel core design instead of a common bus or network between the processors there would only be 4 connections into and out of each processor. These would be 4 registers that are shared with it's 4 neighboring processors that are laid out in a grid. So each chip would have a north, south, east and west register.

Data would be processed in whats called a systolic array, where each core would pick up some data, perform operations on it and pass it along to the next core.

The chips with a 7x7 grid of processors would expose the 28(4x7) bus lines off the edge processors, so that these could be tiled into a much larger grid of processors.

Each chip could perform around 117 Billion instructions per second at 1 Watt of power.

Unfortunately I was unable to raise money, partly because I couldn't' get any commitment from Chuck.

below is some links and other misc information on this project. Sorry it's not better organized.
This was my project.

---------
http://www.enumera.com/chip/
http://www.enumera.com/doc/Enumeradraft061003.htm
http://www.enumera.com/doc/analysis_of_Music_Copyright.html
http://www.enumera.com/doc/emtalk.ppt

--------
This was Jeff foxes independent web site, he work on the F21 with Chuck.

http://www.ultratechnology.com/ml0.htm

http://www.ultratechnology.com/f21.html#f21
http://www.ultratechnology.com/store.htm#stamp

http://www.ultratechnology.com/cowboys.html#cm

------
http://www.colorforth.com/ 25x Multicomputer Chip

Chucks site. 25x has been pulled down, but it's accessible on archive.org.
http://web.archive.org/web/*/www.colorfo

Back in 2000 I realized that 50 Million transistors of 4004 the first processor ever created, would out perform a P4 with the same transistor count done in the same fab running at the same clock rates. it would be over 10x faster I work out. But how to use such a device?
I had been working with a 100 PC cluster of P4 based systems to do H.264 HDTV compression in realtime. I spread the compression function across the cluster using each system to work on a small part of the problem and flow the data across the CPU's.

Based on this I wanted to build an array of processors on one chip, but I am not a silicon person, just software, driver and some basic electronics. So I looked at various FPGA cores, Arm, MIPS, etc. Then I went to a talk giving by Chuck Moore, author of the language FORTH. He had been building his own CPU's for many years using his own custom tools.

I worked with Chuck Moore for about a year in 2001/2002 on creating a massive multi core processor based on Chucks stack processor.

The Idea was instead of having 1,2 or 4 large processor to have 49 (7 * 7) small light but fast processors in one chip. This would be for tacking a different set of problems then your classic cpus'. It wouldn't be for running and OS or word processing, but for Multimedia, and cryptography, and other mathematic problems.

The idea was to flow data across the array of processors.
Each processor would run at 6Ghz, with 64K word of Ram each.
21 Bit wide words and bus (based off of F21 processor)
this allows for 4x 5bit instructions on a stack processor that only has 32 instructions.
Since it's a stack processor they run more efficiently. So in 16K transistors, 4000 gates,
the F21 at 500 Mhz performed about the same as a 500Mhz 486 with JPEG compress and decompress.
With the parallel core design instead of a common bus or network between the processors there would only be 4 connections into and out of each processor. These would be 4 registers that are shared with it's 4 neighboring processors that are laid out in a grid. So each chip would have a north, south, east and west register.

Data would be processed in whats called a systolic array, where each core would pick up some data, perform operations on it and pass it along to the next core.

The chips with a 7x7 grid of processors would expose the 28(4x7) bus lines off the edge processors, so that these could be tiled into a much larger grid of processors.

Each chip could perform around 117 Billion instructions per second at 1 Watt of power.

Unfortunately I was unable to raise money, partly because I couldn't' get any commitment from Chuck.

below is some links and other misc information on this project. Sorry it's not better organized.
This was my project.

---------
http://www.enumera.com/chip/
http://www.enumera.com/doc/Enumeradraft061003.htm
http://www.enumera.com/doc/analysis_of_Music_Copyright.html
http://www.enumera.com/doc/emtalk.ppt

--------
This was Jeff foxes independent web site, he work on the F21 with Chuck.

http://www.ultratechnology.com/ml0.htm

http://www.ultratechnology.com/f21.html#f21
http://www.ultratechnology.com/store.htm#stamp

http://www.ultratechnology.com/cowboys.html#cm

------
http://www.colorforth.com/ 25x Multicomputer Chip

Chucks site. 25x has been pulled down, but it's accessible on archive.org.
http://web.archive.org/web/*/www.colorfo

Back in 2000 I realized that 50 Million transistors of 4004 the first processor ever created, would out perform a P4 with the same transistor count done in the same fab running at the same clock rates. it would be over 10x faster I work out. But how to use such a device?
I had been working with a 100 PC cluster of P4 based systems to do H.264 HDTV compression in realtime. I spread the compression function across the cluster using each system to work on a small part of the problem and flow the data across the CPU's.

Based on this I wanted to build an array of processors on one chip, but I am not a silicon person, just software, driver and some basic electronics. So I looked at various FPGA cores, Arm, MIPS, etc. Then I went to a talk giving by Chuck Moore, author of the language FORTH. He had been building his own CPU's for many years using his own custom tools.

I worked with Chuck Moore for about a year in 2001/2002 on creating a massive multi core processor based on Chucks stack processor.

The Idea was instead of having 1,2 or 4 large processor to have 49 (7 * 7) small light but fast processors in one chip. This would be for tacking a different set of problems then your classic cpus'. It wouldn't be for running and OS or word processing, but for Multimedia, and cryptography, and other mathematic problems.

The idea was to flow data across the array of processors.
Each processor would run at 6Ghz, with 64K word of Ram each.
21 Bit wide words and bus (based off of F21 processor)
this allows for 4x 5bit instructions on a stack processor that only has 32 instructions.
Since it's a stack processor they run more efficiently. So in 16K transistors, 4000 gates,
the F21 at 500 Mhz performed about the same as a 500Mhz 486 with JPEG compress and decompress.
With the parallel core design instead of a common bus or network between the processors there would only be 4 connections into and out of each processor. These would be 4 registers that are shared with it's 4 neighboring processors that are laid out in a grid. So each chip would have a north, south, east and west register.

Data would be processed in whats called a systolic array, where each core would pick up some data, perform operations on it and pass it along to the next core.

The chips with a 7x7 grid of processors would expose the 28(4x7) bus lines off the edge processors, so that these could be tiled into a much larger grid of processors.

Each chip could perform around 117 Billion instructions per second at 1 Watt of power.

Unfortunately I was unable to raise money, partly because I couldn't' get any commitment from Chuck.

below is some links and other misc information on this project. Sorry it's not better organized.
This was my project.

---------
http://www.enumera.com/chip/
http://www.enumera.com/doc/Enumeradraft061003.htm
http://www.enumera.com/doc/analysis_of_Music_Copyright.html
http://www.enumera.com/doc/emtalk.ppt

--------
This was Jeff foxes independent web site, he work on the F21 with Chuck.

http://www.ultratechnology.com/ml0.htm

http://www.ultratechnology.com/f21.html#f21
http://www.ultratechnology.com/store.htm#stamp

http://www.ultratechnology.com/cowboys.html#cm

------
http://www.colorforth.com/ 25x Multicomputer Chip

Chucks site. 25x has been pulled down, but it's accessible on archive.org.
http://web.archive.org/web/*/www.colorfo

Back in 2000 I realized that 50 Million transistors of 4004 the first processor ever created, would out perform a P4 with the same transistor count done in the same fab running at the same clock rates. it would be over 10x faster I work out. But how to use such a device?
I had been working with a 100 PC cluster of P4 based systems to do H.264 HDTV compression in realtime. I spread the compression function across the cluster using each system to work on a small part of the problem and flow the data across the CPU's.

Based on this I wanted to build an array of processors on one chip, but I am not a silicon person, just software, driver and some basic electronics. So I looked at various FPGA cores, Arm, MIPS, etc. Then I went to a talk giving by Chuck Moore, author of the language FORTH. He had been building his own CPU's for many years using his own custom tools.

I worked with Chuck Moore for about a year in 2001/2002 on creating a massive multi core processor based on Chucks stack processor.

The Idea was instead of having 1,2 or 4 large processor to have 49 (7 * 7) small light but fast processors in one chip. This would be for tacking a different set of problems then your classic cpus'. It wouldn't be for running and OS or word processing, but for Multimedia, and cryptography, and other mathematic problems.

The idea was to flow data across the array of processors.
Each processor would run at 6Ghz, with 64K word of Ram each.
21 Bit wide words and bus (based off of F21 processor)
this allows for 4x 5bit instructions on a stack processor that only has 32 instructions.
Since it's a stack processor they run more efficiently. So in 16K transistors, 4000 gates,
the F21 at 500 Mhz performed about the same as a 500Mhz 486 with JPEG compress and decompress.
With the parallel core design instead of a common bus or network between the processors there would only be 4 connections into and out of each processor. These would be 4 registers that are shared with it's 4 neighboring processors that are laid out in a grid. So each chip would have a north, south, east and west register.

Data would be processed in whats called a systolic array, where each core would pick up some data, perform operations on it and pass it along to the next core.

The chips with a 7x7 grid of processors would expose the 28(4x7) bus lines off the edge processors, so that these could be tiled into a much larger grid of processors.

Each chip could perform around 117 Billion instructions per second at 1 Watt of power.

Unfortunately I was unable to raise money, partly because I couldn't' get any commitment from Chuck.

below is some links and other misc information on this project. Sorry it's not better organized.
This was my project.

---------
http://www.enumera.com/chip/
http://www.enumera.com/doc/Enumeradraft061003.htm
http://www.enumera.com/doc/analysis_of_Music_Copyright.html
http://www.enumera.com/doc/emtalk.ppt

--------
This was Jeff foxes independent web site, he work on the F21 with Chuck.

http://www.ultratechnology.com/ml0.htm

http://www.ultratechnology.com/f21.html#f21
http://www.ultratechnology.com/store.htm#stamp

http://www.ultratechnology.com/cowboys.html#cm

------
http://www.colorforth.com/ 25x Multicomputer Chip

Chucks site. 25x has been pulled down, but it's accessible on archive.org.
http://web.archive.org/web/*/www.colorfo

I would really like to be able to talk directly with the OLPC People, I haven't made any attempts as of yet.

I have alway been very good at squeezing out the most from minimal hardware.

The PXA has a what they call "Wireless MMX" this is an FPU !! The similar MMX that is supported by the x86 processors!

http://www.theregister.co.uk/2004/04/12/intel_ships_bulverde/

We are paying around $15 per chip for the PXA270's right now and I know the price could easily come down, but the PXA3xx is the newer lower cost chips with increased speed and more I/O.

Anyhow I don't see anyone complaining about the processing power and graphics on the iPhone and that plays all kinds of cool graphics tricks.

Why does OLPC care so much about MPEG4?

Last time I worked with a bunch of MIT Media Lab Weenies was on a project called charmed. they pushed me out and made something that looked like an old army canteen based on PC104.
http://creativetech.inn.leedsmet.ac.uk/staff/rb/Wearable.html

It never went anywhere. At the same time I was working on a 3rd gen of my wearable based on a new super chip that I was working on with Chuck Moore. http://www.intellasys.net/products/index.php this was based on http://www.colorforth.com/ X25 chip, sorry he pull that page down. http://www.ultratechnology.com/ml0.htm see X25

We did get a prototype wearable done from this.

In the mean time I also made the mistake of teaching some Chinese how to build the goggles, be never the the funding to keep them exclusive to my project. http://www.dnull.com/goggle/p.html BTW: I get them Whole Sale cheaper, and that site is not the manufacturer but a reseller.

My whole system BOM was $35 in quantity, technically what I had would do the job of the OLPC except for power consumption and it's wearable screens not laptop style, but maybe better if your herding goats. After all who cares about getting middle class kids cheaper PC's let mom buy them a new Laptop for $750.

Also SATA, no way, use SD Flash now. USB sure the kids in Africa and India will have all the latest USB gadgets as soon as Fry's open up a store there, NOT.

The Gold Leopard King PC is literally one chip, probably some 8 bit core, most likely downloaded from opencores.org with Pirated game roms and Sells for $5 (350 rupees). There probably using the same fabs for digital watches and calculators. I'd love to know how to find them.

We could put one or more 500 Mhz arms in one chip, 64Meg DRAM with 2 gigs of SD and a Kent Display and some simple wireless, Even a camera and get the whole BOM down to $20 to $30 in 100K volumes with about $10M in development. It would of course run stock Linux. The display wouldn't be fast for clear video, but slow video and good audio would be great. Or for a little more add a tiny 1x1 inch LCD for the video.

Again, why are they trying to build these things like High end Gaming machines. The point is to make something closer to the French Minitel http://en.wikipedia.org/wiki/Minitel, basically get them on the web, and E-mail and access to the worlds Knowledge and educational software. Not to be able to play WarCraft, surf porn and watch YouTube! Or worse yet create a larger army of 409 scammers.

Buy trying to play this venture using more traditional technology and , AMD, Intel, M$ etc, they just invited grinches to attack. Intel would have to kill this just to ensure there middle class parents

"Since the demise of LISP machines, the concept of a stack-based machine has surfaced repeatedly in virtual machines."

I guess I'm the only one who remembers the commercially available Harris RTX-2000

Putting a computer in a mouse has been done before, too.

They are supposed to announce the chip at a microprocessor conference in April.

It appears the new chip will not be available for general purchase. They don't won't to be in the chip sales business, just provide solutions.

Check out http://ultratechnology.com/fsc04.htm.

I suspect that http://enumera.com/ is behind this new company.

Oh well, it's not like it makes a difference because software just gets more bloated and inefficient as CPU speed increases. It's not like I can go to a web page any faster or load up a game or type an essay any faster than I could 4 years ago, yet I was using a 225mhz computer back then, and now I'm using a 1666mhz computer. Does that make sense do you? It doesn't to me.

That's why we need Forth!: Java done right, 20+ years ahead of time. Virtual machine, extensible language, bottom-up design, efficient, and can even be implemented on a chip.

Using C# will not make performances that much worse, because they intend to write mostly GUI program which spend 90% of their time idling, waiting for user input. Are you telling me you want your idling time to be optimized?

The bottom line is that C# is a high-level language and C is just a portable assembly. What does that mean to developpers?

• Faster development time: no need to hunt memory allocation bugs, pointer arithmetic problems, no need to reinvent standard stuff all the time. It also means that as a hobbyist developper, you can do more from 20:00 to 22:00 before going to sleep than in C.
• Reduced complexity: the programmer focuses only on the problem at hand, not on the machine-sepcific details as well
• Less security issues to worry about: no buffer overflows
• Less headaches: did you forget a star before a variable to derefernece your poiunter?

Users also experience benefits:

• Applications come out sooner, so less waiting time
• Applications have a whole family of bugs that cannot happen, so more stability
• More portability: if the VM runs on two platforms, it's pretty sure you can run the application on two platforms too.

Everyone benifits from the GNOME people using Mono/C#, and I don't think many people run a desktop GUI on their Pentium 133MHz, especially not GNOME. GNOME does not need to suit EVERYONE and work on every machine, that's just too limiting. If you want a light window manager, use Blackbox or IceWM or twm or fvwm2. The GNOME people don't have "being able to run on a 7 year old computer" up on their list. They do have "improving the quality of our software" and "giving users a great desktop experience".

For all those who think everything should be coded in C for speed reasons, I invite you to search Slashdot for the interview with Chuck Moore (of Forth fame) and go here to read interviews with the guy. If you find agreeing with him, you are stuck in the 60's-70's. If not, you might reconsider your position on the usage of byte-compiled, high-level languages for user applications.

Vince.

"What makes his designs important IMHO is that they are very simple compared to conventional chip designs-which makes them appropriate for things like very low power consumption and makes it possible for one person to understand/implement their design."

The Harris RTX-2000 was a stack-based processor.

One of the more interesting processor designs would be the FORTH based 25xC18 using 25 C18 cpu cores which could achieve up to 60,000 (!!!) MIPS using a very low power design. The 25xC18 was designed by Chuck Moore. The interesting thing about the FORTH processors is that they use an extremely small instruction set (~24 instructions) and require only ~10K transistors per CPU allowing for very fast and low power operation. It also allows one to add on-chip DRAM right next to the core allowing 1ns memory access to a small cache. I think stack based processors are the way to go when it comes to multiprocessor designs since stacks allow easy pipelining of instructions and data between processors.

You can learn more about FORTH based processors here. Here's additional information about the 25xC18.

The FORTH based processors have never become mainstream, I'm not sure why that is? If this thing ever gets into production, it will be pretty revolutionary.

We don't need bloated hardware and software to design fast portable computers which run circles around Transmeta in speed and power consumption. We don't need commonly used bloated embedded operating systems either (yes this includes embedded forms of Unix, too). We just use a different approach. It has been demonstrated to work very well, and perhaps even offend a few people :).

We don't need bloated hardware and software to design fast portable computers which run circles around Transmeta in speed and power consumption. We don't need commonly used bloated embedded operating systems either (yes this includes embedded forms of Unix, too). We just use a different approach. It has been demonstrated to work very well, and perhaps even offend a few people :).

Look at Chuck Moore's home page, at the 25x chip -- there ya go. This is not the first async chip Chuck's done. They go way back. Also have a look at UltraTechnology where plenty of that history is documented.

This sounds like something that OpenBOOT already provides. Microsoft is reinventing the wheel... poorly. FORTH forever!

http://ultratechnology.com

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?

I understand Forth is a stack-based language: doesn't that present problems when compiling for CPUs that mostly work using registers?

If you are interested in processors that are Forth-friendly, have a look at this processor round-up.

The most bloated and poorly-written office software was taking *minutes* to perform a variety of functions on my 900 MHz 384 MB system just last night. Can you have too much processor speed? Would you not want a faster computer for less money? In a world of computing designed and implemented by Chuck Moore, there wouldn't be bloated and poorly-written software. The most massive applications can be achieved with minimal equipment. See Chuck's OKAD for an example.

That sounds slow compared to Chuck Moore's new design.

I don't doubt that it will work as he says since his previous designs ran at up to 800 MHz with a 0.8 micron process (see the middle of this page).

Charles Moore has made several 'clockless' (well, self-clocked) asynchronous CPU designs and created his own CAD tools to do it. He is able to do this by keeping his designs very small and simple... but they are quite fast. Prototype chips of one of his earlier designs are available from Ultra Technology. So far he has been backed only by small companies, probably because he is ten years or so ahead of conventional system designers. -- Mike Losh

A number of times it has been mistaken for PC running Windows (tm) until I point out that there is no PC, just a mouse and a computer monitor or TV.

Not new, but still pretty cool. Too bad they don't show an actual picture of the whole setup instead of a screen capture.
--

Forth is an interesting dual to Lisp. Lisp programming encourages building the language, and hence the computer, up to the problem. Moore wants to dispell the levels of abstraction, but interestingly enough his language works by building up phrase books of words to map your problem onto the machine. He emphasizes keeping the phrase books as simple as possible, but in a way so does Graham in On Lisp.

A relevant USENET quote I cannot attribute: In Lisp, code is data. In Forth, data is code.

Forth is an interesting dual to Lisp. Lisp programming encourages building the language, and hence the computer, up to the problem. Moore wants to dispell the levels of abstraction, but interestingly enough his language works by building up phrase books of words to map your problem onto the machine. He emphasizes keeping the phrase books as simple as possible, but in a way so does Graham in On Lisp.

A relevant USENET quote I cannot attribute: In Lisp, code is data. In Forth, data is code.

There are Forth systems that do triple duty as OS, shell, and programming language, in under 5K.

Take a look at Chuck Moore's work. His attitude is that the right amount of software for pretty much any task is about 1000 words (tokens).

(geez, these spoiled youngsters, with their gigabyte ram and their terabyte hard-drives... no clue about the days when you were happy -- happy! -- to have 16 kb of RAM)
--

The astounding thing about X is how much code it needs to do almost nothing. Window management is up to a window manager. Hardware specific code is up to a device driver. Gadgets and such are up to higher-level libraries like Qt. Standard GUI niceties are left up to desktop environments, like KDE and Gnome.

The truth is that it takes very little code to do what X does. One of the most minimal windows managers for X, Blackbox, is approximately 12,000 lines of C++ (the author likes to give a line count). Think about that. 12,000 lines of code to simply act as an interface between you an X in a very minimal way. You could write an entire GUI, including hardware-specific code, in 12,000 lines. Maybe it wouldn't be KDE, but it shows how far off base we've become. Don't believe it? here is a functioning GUI, which doesn't use any external libraries for graphics, done in a few kilobytes of object code.

MISC has been used to refer to Minimal Instruction Set Chips for a while now. A little research would have shown them this; now the acronym recognition is severely diluted.
MIS Chips

I was using their description. I agree that it's a rather dubious one. However their processor is hard to categorise - I don't think I've ever encountered anything quite like it before.

I admit it is their description. I was going to let it slide on that basis alone. But then I figured what the heck. We raise a stink in almost every thread where a media article mis-uses the term "hacking". Why should we let hardware marketers mis-use the term RISC just as badly?

Also for a somewhat similar CPU look at the Motorola 68F3XX series.

Of course the addressing modes are very valuable for the kind of work this chip is intended for.

The addressing modes don't really make life simpler. They just let you do "LOAD ((R1)+R2), R3" rather then "LOAD (R1), R4; ADD R2, R4, R4; LOAD (R4), R3" (assuming target register is the last one). It doesn't save any cycles, even on CPUs where the double indirect plus displacement is faster then the two loads and add, the whole CPU is slower at everything for having the indirect mode!

Go back and read about the horror of the "fast" VAX in the Mashy essay I posted the link to.

Maybe this is why it is hard to categorise - the design (including the instrcution set) is optimsed towards doing I/O and networking manipulation.

The parts of the instruction set that make it CISCy aren't really needed for I/O. I don't object to the in-register byte/bit flopping. I don't object to the integrated Ethernet or serials. I definitely don't object to the integrated net booting.

To be honest I don't even object to the parts that make it CISCy, only that they chose to mis-lead people by saying "RISC" rather then "CISC and damn proud!". It's not the mistake that kills you, it;s the cover-up :-)

100 mips

Thanks. I couldn't remember.

Perhaps not - but it isn't really a classical CISC either. Perhaps someone needs to invent a new acronym ?

Well since it is "standard CISC with a bunch of peripherals stuck inside it to appeal to embedded network apps", I would go with "embedded CISC", or "embedded network CISC".

The Data sheet seems to push the "RISC" angle as an explanation for the low power consumption - and it certainly achieves pretty good results there.

The Motorola ColdFire is a CISC that goes up to around 200Mhz at very low power. The Motorola DragonBall is a CISC that is definitely the low-power brains behind current Palm Pilots.

CISC doesn't mean power hungry. Hell thanks to Intel and AMD CISC doesn't even mean slow-as-a-dog.

The "bottom line" for me is that, on paper, it allows me to build a solution with a hardware cost around half that I can achieve any other way.

Well, that's because it is a kick ass little CISC CPU.

I think perhaps my application is unusual - I don't want any displays or user interface (the customer explicitly wants a "grey box screwed to the wall that they can just forget about") - so many single board computers on the market would just sit there with half the chips never doing anything - but I can't be the only person who needs to do this kind of thing ?

To have totally no UI is a bit unusual. But to have no raster pixel display (LCD or otherwise) isn't uncommon. But most applications are either in such huge volumes that it's better to do a design just for that application (so you can save $0.03 by leaving off an address pin you don't need, or other stuff like that), or such low volume, that they are better off buying a board with parts they don't need.

I think you can normally get the "unneeded" parts down to serial ports by looking at the "BASIC Stamp" market, and the small SBCs that replace high-end stamps.

Or look at Chuck Moore's stuff. Sure it has the NTSC video generator, but are (well, will be, someday) dirt cheap. Oh, and it's definitely a CPU design that I have a hard time pegging as RISC or CISC. So you could win on that one :-) Besides it's so cool to fit the computer inside the mouse.

He st uck a whole computer in a mouse</a>, apparently just for the hell of it. Knowing him, it probably wouldn't cost significantly more than an ordinary mouse, either.

...if the general-purpose hardware wasn't so stupid. Of the millions of transistors on a modern chip, most of them are wasted in maintaining the illusion of sequential operation, while the OS writers go to considerable trouble to create the illusion of parallel operation.

Furthermore, there are the huge (in terms of transistor count) banks of flip-flops which just sit around most of the time, and the costly layers of cache all working their hardest to maintain the illusion that it is RAM. Meanwhile, software optimizers make sure to access memory sequentially to avoid upsetting this illusion, which would ruin the performance.

You can justify all this nonsense with the argument that software is written for sequential machines with RAM. It's a circular problem. If somebody would just release a cheap massively parallel system, the programmers would learn to use it efficiently.

You can make a complete processor in a few thousand transistors (as this guy has done, though he goes a bit off the deep end...), and you can add a bit (a few K) of high-speed RAM and network them easily enough to make a (dare I say it?) Beowulf cluster on a chip. Each might only run at one tenth the speed of a modern CPU, but you could have hundreds of them for the same cost, giving you bips and gflops for the price of mips.

It would also make the whole design process a lot easier and faster. One simple processor, repeated hundreds or thousands of times. Every advance in production would bring a direct and proportional improvement in performace, with a tiny added design cost. Forget special graphics or sound processors, just plug in more processor banks like you would add memory today and watch your system fly.

C'mon hardware guys, we software guys aren't that stupid! We don't need your illusion of a 386!

In what way is iTVC involved in this ?
Does anyone know what iTVC is up to these days ?
Are Chuck Moore and Jeff Fox still involved in iTVC ?
Chuck and Jeff have done some cool MISC processor designs in the past.
You can read about them at http://www.ultratechnology.com

"I don't remember saying that"
Sorry, you didn't, that was AndrewHowe. I wasn't keeping track of who is on this thread.

"I'll take your word for it"
Don't take my word too seriously, I don't have the C spec either. I'm going on what other people have said about the standard. And like I said, it may have been about the upcoming standard, not the present one (you've gotta love it, it's finally been around long enough for people to comply and then they go and change the thing).

"However, without an integer type big enough to hold a pointer, how are you going to compare a pointer to another using operators like do wish that methods of handling larger ints were specified; I mean, even the x86s have special features to handle 64-bit ints, which you just can't access using ANSI C). Actually, I'm rather fond of the idea of 24-bit chips. Chuck Moore thinks 20-bits is enough, and I really respect him, but he also thinks it's an acceptable tradeoff to use a character set where ones and lower case Ls are the same (I really recommend reading around his web site, while he might be a little over the edge, he still has a lot to teach the rest of us).

The fewer excess bits you use, the smaller and faster (not to mention cheaper) the chip can be.

"So that the code can run on 99.9999% of the machines someone may want to run it on, instead of, say, 85%, or 50%, or 1%, depending on how far you deviate from the standard and what assumptions you make?"

Nothing that depends on a 64-bit long (and very little that can benefit from it) is going to run on 99.9999% of machines (it will, in fact, be broken on many 64-bit machine compilers), which was my point.

Hey! Forth rules!

If I had to throw away all my nice dev tools and start over from popping in a byte at a time with 8 toggles and an enter key, the first thing I would do is code a Forth interpreter/compiler; even before I wrote an assembler (it's easier).

The only reason I don't use Forth now is because I've got the entire UNIX dev environment to support me, which is almost as efficient as Forth and gives you some hint of portability.

But Forth builds good programmers. You learn never to make a mistake, because mistakes eat your machine. You learn to debug your code by eyeball and brainpower, not with any machine aid. You learn to rewrite everything every time, and you learn that this can be faster than reading the docs for a library.

(BTW, none of this applies to ANS Forth, which is a bad joke from the people who made Ada; Forth is something you should rewrite for every machine you use it on, just ask Chuck)

Oh, you laugh now, but just you wait until we start writing massively parallel systems and you're begging Chuck to burn a thousand of his 250 MIPS (with a cheap fab) 10k transistor (with video processing!) processors on one chip.

Chuck sure is the greatest Computer Cowboy of them all !