Your next supercomputer! Just $99 for 16 ARM cores on a chip. (link supplied)

[B.Person]

Posted 16 hours ago. Time to get into the ARM world; IMHO.

http://arstechnica.com/information-technology/2012/09/99-raspberry-pi-sized-supercomputer-touted-in-kickstarter-project/

[jacko]

Doesn't sound too bad. I have written some Java code for a soft implementation of a DSP core with 1KB memory. I wonder if this idea is extended with some memory exchange interconnect using a time division multiplex bus an external co-ordination processor using the memory, could calculate the TDM flux, and then build the correct software in each 1KB cell. With 1GB memory sticks common, this is 1M * 20 cycle processors as an estimate. Neural net simulation? I assume silicon density can exceed neuron density by quite a margin.

https://github.com/jackokring/jarvar/blob/master/jarvar-base/src/uk/co/peopleandroid/jarvar/internals/SoftDSP.java

Cheers Jacko

[jacko]

Sky Net is upon us...

[Jecel]

On Friday, September 28, 2012 11:16:25 AM UTC-3, B.Person wrote:
> Posted 16 hours ago. Time to get into the ARM world; IMHO.

The 16 cores are not ARM, though they do talk to an ARM processor.

-- Jecel

[Mark Wills]

On Sep 28, 6:44 pm, jacko <jackokr...@gmail.com> wrote:
> Doesn't sound too bad. I have written some Java code for a soft implementation of a DSP core with 1KB memory. I wonder if this idea is extended with some memory exchange interconnect using a time division multiplex bus an external co-ordination processor using the memory, could calculate the TDM flux, and then build the correct software in each 1KB cell. With 1GB memory sticks common, this is 1M * 20 cycle processors as an estimate. Neural net simulation? I assume silicon density can exceed neuron density by quite a margin.
>

> https://github.com/jackokring/jarvar/blob/master/jarvar-base/src/uk/c...
>
> Cheers Jacko

It's shared memory with up to 128K per node.


Complete multicore solution featuring a high performance
microprocessor ISA, Network-On-Chip, and distributed memory system
Fully-featured ANSI-C programmable GNU/Eclipse based tool chain
Scalable to 1000’s of cores and TFLOPS of performance on a single
chip
1GHz superscalar RISC processor cores
IEEE Floating Point Instruction Set
Shared memory architecture with up to 128KB memory at each
processor node
Zero startup-cost messaging passing
Vector Interrupt Controller
Distributed Multicore Multidimensional DMAs
32 GB/sec local memory bandwidth per core
8GB/sec per processor network bandwidth
72 GFLOPS/Watt energy efficiency
Processor tile size of 0.5mm^2 at 65nm, 0.128mm^2 at 28nm


From http://www.adapteva.com/products/epiphany-ip/epiphany-architecture-ip/

Awesome.

[Paul Rubin]

"B.Person" <bruce....@gmail.com> writes:
> Posted 16 hours ago. Time to get into the ARM world; IMHO.

I looked at that. It looked interesting at first, but meh.

I don't think they claimed to have ARM cores on the array chip. They
are some unidentified 32-bit risc architecture, maybe ARM, maybe not.
(There is an architecture manual but I didn't look at it). The board
does have an ARM running Linux and you might be thinking of that. The
array chip is a peripheral to the ARM chip, operating as a coprocesssor
or accelerator. Basically you are looking at a Raspberry Pi with an
external, programmable GPU.

The array chip has limited memory and i/o bandwidth, the usual
bottleneck of these things. Its total computational performance is
nowhere near that of a desktop GPU, though of course its power
consumption is much lower, making it perhaps of interest for mobile
products. And instead of SIMD, it's a bunch of semi-independent
processors sort of like the recently announced Xeon Phi. For the
16-core chip there is 0.5MB of on-chip NUMA ram, I guess 32k "owned" by
each core, with lower speed access possible from other cores.

[Rod Pemberton]

"B.Person" <bruce....@gmail.com> wrote in message
news:76fe0697-97b3-4844...@googlegroups.com...

And, another OT thread ...

> Posted 16 hours ago. Time to get into the ARM world; IMHO.
>

Why?

a) The project doesn't have any funding, yet.
b) There is no markete demand for it, yet.
c) It's not being produced by a major semiconductor company, i.e., it's got
the "kiss of death" already ...
d) It'll require some custom hardware, i.e., an additional expense.
e) There is no software for it.

> [link to proposed many core ARM]

I saw a slightly different link for it:
http://hackaday.com/2012/09/28/massively-parallel-64-core-computer-costs-99/

My thoughts when I saw that were:
"Just what advantage does this design have over the failed Transputer?"
http://en.wikipedia.org/wiki/Transputer

Not to burst anyone's bubble, but I saw nothing of any merit that would
offer this project _any_ chance at real success.

They've given themselves a year to produce the 16-core version. That
seems a bit unrealistic.


Rod Pemberton

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cmm> writes:
> a) The project doesn't have any funding, yet.

True, and they may be asking a bit much.

> b) There is no markete demand for it, yet.

Yeah, they are too hopeful and enamored of their design, it seems to me.

> c) It's not being produced by a major semiconductor company, i.e., it's got
> the "kiss of death" already ...

Meh. Is ARM a "major semiconductor company"? Is Allwinner a major
semiconductor company? What about NVidia? Heck, what about Green
Arrays? You're at a cost disadvantage by being fabless but it's
certainly possible to ship successful products using foundries.

> d) It'll require some custom hardware, i.e., an additional expense.

Just a Raspberry Pi-like PC board (plus the 64 core cpu if they do that,
I thought).

> My thoughts when I saw that were:
> "Just what advantage does this design have over the failed Transputer?"
> http://en.wikipedia.org/wiki/Transputer

I'm not sure the Transputer failed for technical reasons. Tilera has
been making a 64-core(?) cpu for a while, and Intel has announced the
Xeon Phi.

> They've given themselves a year to produce the 16-core version. That
> seems a bit unrealistic.

I thought they already had the 16-core silicon, and they were looking to
build a board and a 64-core chip. Maybe I'm mistaken about the 16-core
silicon.

[Bernd Paysan]

Paul Rubin wrote:

> "Rod Pemberton" <do_no...@notemailnotz.cmm> writes:
>> a) The project doesn't have any funding, yet.
>
> True, and they may be asking a bit much.

AFAIK they already had a first round of founding for their 16 cores
unit, with IIRC $2 million.

>> b) There is no markete demand for it, yet.
>
> Yeah, they are too hopeful and enamored of their design, it seems to
> me.

Well, whatever startup you have, if you aren't overly hopeful and
enamored, it won't go anywhere. You absolutely have to love what you
are doing.

>> c) It's not being produced by a major semiconductor company, i.e.,
>> it's got the "kiss of death" already ...
>
> Meh. Is ARM a "major semiconductor company"? Is Allwinner a major
> semiconductor company? What about NVidia? Heck, what about Green
> Arrays? You're at a cost disadvantage by being fabless but it's
> certainly possible to ship successful products using foundries.

A typical Rod Pemberton argument: Completely clueless and hopelessly
outdated... There are a few semiconductor companies left like Samsung,
TSMC, Intel, IBM, GlobalFoundries, Ti, who can produce the most recent
generation of semiconductor process. But as Moore's law has an
exponential cost in fabs, they get fewer and fewer. Therefore, fabless
is the future. Even AMD is now fabless. The years where they couldn't
fill their expensive fabs nearly killed them.

>> My thoughts when I saw that were:
>> "Just what advantage does this design have over the failed
>> Transputer?" http://en.wikipedia.org/wiki/Transputer
>
> I'm not sure the Transputer failed for technical reasons. Tilera has
> been making a 64-core(?) cpu for a while, and Intel has announced the
> Xeon Phi.

And all the desktop GPUs are essentially many-core architectures.

The transputer failed for being too early. Back then, improving the
speed of a single core was still the best way to get more performance -
up to about 10 years ago, parallelism wasn't that important. Things
have changed since then.

Note that this thing we are discussing here has a unified, but non-
uniform memory, you communicate by reading and writing remote memories.
This is pretty conventional, so people can use it.

>> They've given themselves a year to produce the 16-core version. That
>> seems a bit unrealistic.
>
> I thought they already had the 16-core silicon, and they were looking
> to build a board and a 64-core chip. Maybe I'm mistaken about the
> 16-core silicon.

It took him (as this was a one-man-show) 6 weeks to tapeout the 16-core
silicon after he got the design software - he did invest 2 years of
design time prior to that; probably using FPGA tools to evaluate his
stuff. The design is there, all they (they are now more than one man)
need to do is to retarget the physical layout to a 28nm process.

Shouldn't take too long.

The design software of today is really in a much better shape than it
used to be. AMD turned away from hand-tuned hand-layouted everything,
and their new Steamroller design looks like they are have recovered from
that; they are now as good as the pre-Bulldozer hand layout used to be.

I'm not sure if this will be a tremendous success. They aren't that
much better than a GPGPU, and the GPGPU will be included into devices
just because you need a GPU. Current desktop GPUs are already GPGPUs
(with OpenCL and alike as language), and the next generation mobile GPUs
like Mali 600 will be GPGPUs, too.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
>> True, and they may be asking a bit much.
> AFAIK they already had a first round of founding for their 16 cores
> unit, with IIRC $2 million.

Making chips is expensive. But once the chip is made, another $750k to
make a PC board with off-the-shelf parts around it? Or is it mostly for
software porting, or what?

>> Yeah, they are too hopeful and enamored of their design, it seems to me.
> Well, whatever startup you have, if you aren't overly hopeful and
> enamored, it won't go anywhere. You absolutely have to love what you
> are doing.

It also helps to have concrete evidence that what you're doing fills a
need, instead of being a solution looking for a problem. This echoes
similar things you've said in the past about the GA chip.

> It took him (as this was a one-man-show) 6 weeks to tapeout the 16-core
> silicon after he got the design software - he did invest 2 years of
> design time prior to that; probably using FPGA tools to evaluate his
> stuff.

May I ask what is involved in 2 years of something like that? I'm
imagining a process like "download a 32-bit RISC core from
opencores.org, replicate 16 times, plus add some stuff for the shared
memory blocks".

> I'm not sure if this will be a tremendous success. They aren't that
> much better than a GPGPU, and the GPGPU will be included into devices
> just because you need a GPU. Current desktop GPUs are already GPGPUs
> (with OpenCL and alike as language), and the next generation mobile GPUs
> like Mali 600 will be GPGPUs, too.

I think the chip is targeted to mobile phones with little power
available. The 16-core part's total commputational performance is lower
than today's desktop processors, and even the 64-core is not that much
ahead, especially if you count on-chip desktop GPU's.

I'd say though that gpgpu's are not so good at algorithms involving lots
of conditional branches, so these array thingies probably have uses.
The Xeon Phi looks interesting.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:2207084.u...@sunwukong.fritz.box...

> Paul Rubin wrote:
> > "Rod Pemberton" <do_no...@notemailnotz.cmm> writes:

...

> >> c) It's not being produced by a major semiconductor company, i.e.,
> >> it's got the "kiss of death" already ...
> >
> > Meh. Is ARM a "major semiconductor company"? Is Allwinner a major
> > semiconductor company? What about NVidia? Heck, what about Green
> > Arrays? You're at a cost disadvantage by being fabless but it's
> > certainly possible to ship successful products using foundries.
>
> A typical Rod Pemberton argument: Completely clueless and hopelessly
> outdated...

Except for x86 and ARM, all the other early, major microprocessor
manufacturers are dead.

Some of the early processors:

6502: dead.
Z80: dead.
TMS9900: dead.
6800: dead.
6809: dead.
etc.

Every microprocessor design with great potential and great hype is dead too.
Can you name one between 1974 and 2012 that isn't?

Some of the great hypes:

NEC V20/V30: dead.
Transputer: dead.
DEC Alpha: dead.
PA-RISC: dead.
Transmeta: dead.
PowerPC: dead.
Itanium: dead.
etc.

The microprocessor industry is a graveyard of dead processors. Three of the
companies that are still alive are very old: AMD, Intel, and ARM.

ARM very nearly died, in the 1990's. I was surprised when I learned it
hadn't. It was declared dead. It went into bankruptcy. It never had much
market share. It was a bad RISC design decades ago. It was clearly saved
by advent of mobile computing devices.

What's going to fuel the massively, multi-core ARM market? Low cost? That
might work for the $99 version, but not the $499 version.

If Zilog Z80 line of microprocessors hadn't died (converted into
microcontrollers...), Zilog might have all of ARM's market, today. They had
the lowest transistor counts of any microprocessor design at a given
performance level. I.e., they'd be cheaper and use less power.

Does NVidia produce microprocessors? No ... They produce GPU's. They're
different. It's typical for Bernd to support non-facts as facts.

There has been a resurgance of new, inexpensive _microcontroller_ designs,
not _microprocessors_. That'd make Bernd clueless about the difference
between the two. Does it matter that a modern _microcontroller_ is as
powerful as an ancient _microprocessor_? AFAIK, I don't lump and dump all
processing devices into one category as you do.

I don't know much about Green Arrays. But, if it's like Chuck Moore's
previous, older, failed, Forth microprocessor projects, it's just a design
house of his ... Basically, he's become a high-level patent troll. He
predicts a future for microprocessors, which turns out to be false. In the
process, he pushes the limits of microprocessor design. Next, he patents
what he believes will be needed in the future by other companies, like
AMD or Intel. He's correct only a small percentage of the time, but
enough to earn him some money or respect.

> There are a few semiconductor companies left like Samsung,
> TSMC, Intel, IBM, GlobalFoundries, Ti, who can produce the most recent
> generation of semiconductor process. But as Moore's law has an
> exponential cost in fabs, they get fewer and fewer. Therefore, fabless
> is the future.

Fabless is a _temporary_ solution driven by cost pressures of building a new
fab. No one wants to pay the large upfront cost anymore. However, for a
major manufacturer to profit, they must control their own means of
production and it's associated costs. That's where the profit comes from:
lower cost of manufacturing with large volumes. How do you get lower costs
when you outsource? You don't. Your supplier expects a profit above their
costs. Their costs are similar to what yours would've been, but typically,
slightly more. If you're a major player, they're not as skilled as you in
building manufacturing plants. In a vertically integrated company, their
profit would've been part of your profit. You can only get modest costs if
there is competition among suppliers, and your suppliers are _not_ using
recently built - expensive - factories. Any supplier with a new factory
can't compete on a cost basis against an old factory. A modern factory can
only compete if they are a monopoly. Why would their costs be any lower
than your costs? Or, the fabless manufacturer must have an exclusive
contract for full use of a fab. Otherwise, a competitor could pay the fab
slightly more to produce it's product, instead of producing your product.
Then, you don't have any product, or reduced volumes of it.

> Even AMD is now fabless. The years where they couldn't
> fill their expensive fabs nearly killed them.

Do they allow others to use their fabs? (No.) So, effectively the fab
becomes a subsidiary via exclusive, contractual use. In exchange for the
fab fronting the upfront build cost of the fab for their customers, their
fab is paid for over time at a higher total cost to the customer than the
upfront cost to build in-house. Your choices are: pay much now,
immediately, or pay much more, very slowly. If you've got cash flow
but no cash, then the second choice is your only option.

> >> My thoughts when I saw that were:
> >> "Just what advantage does this design have over the failed
> >> Transputer?" http://en.wikipedia.org/wiki/Transputer
> >
> > I'm not sure the Transputer failed for technical reasons. Tilera has
> > been making a 64-core(?) cpu for a while, and Intel has announced the
> > Xeon Phi.
>
> And all the desktop GPUs are essentially many-core architectures.
>

The GPU tasks are also well suited to parallel processing, unlike those
of a microprocessor.

> The transputer failed for being too early.

It failed because parallel processing was a failure back then. That was
mostly because programming languages couldn't produce good parallel
processing code. I doubt much has changed since. The languages weren't the
problem. The task given to them was. The task weren't suited to
parallelism. They still aren't. What's changed in a few decades? Nothing.

> Back then, improving the speed of a single core was still the best
> way to get more performance - up to about 10 years ago, parallelism
> wasn't that important. Things have changed since then.
>

Which modern programming languages effectively implement parallel
processing today? How are they going to program this thing?

If each core in a massively multi-core ARM microprocessor handles a distinct
task, then it's no better than the multiple co-processor design used in the
old Amiga computers.
http://en.wikipedia.org/wiki/Amiga

Since that's probably what's going to happen, i.e., distinct tasking of each
core, let's make some guesses about what each core could be used for.

1 core for single-threaded OS
1 core for sound
1 core for 2D graphics
2 cores for video

Wow, we've 11 to go ... Now what? 11 idling applications?


Rod Pemberton

[Elizabeth D. Rather]

On 9/29/12 2:30 PM, Paul Rubin wrote:
> Bernd Paysan <bernd....@gmx.de> writes:
>>> True, and they may be asking a bit much.
>> AFAIK they already had a first round of founding for their 16 cores
>> unit, with IIRC $2 million.
>
> Making chips is expensive. But once the chip is made, another $750k to
> make a PC board with off-the-shelf parts around it? Or is it mostly for
> software porting, or what?

Don't forget marketing. It's expensive, and engineers often fail to
appreciate both its expense and its necessity. Over the years I've been
involved in many more projects that were marketing failures than
technical failures.

>>> Yeah, they are too hopeful and enamored of their design, it seems to me.
>> Well, whatever startup you have, if you aren't overly hopeful and
>> enamored, it won't go anywhere. You absolutely have to love what you
>> are doing.
>
> It also helps to have concrete evidence that what you're doing fills a
> need, instead of being a solution looking for a problem. This echoes
> similar things you've said in the past about the GA chip.

Yes, that's important, and I'm afraid I also agree it's a problem with GA.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Elizabeth D. Rather]

That's a little unfair. Many of those processors had excellent careers.
It's in the nature of technology to have a finite lifetime. The
*companies* that survived are the ones that could keep up a pipeline of
new processors to replace the ones that become obsolete.

...

>> Even AMD is now fabless. The years where they couldn't
>> fill their expensive fabs nearly killed them.
>
> Do they allow others to use their fabs? (No.) So, effectively the fab
> becomes a subsidiary via exclusive, contractual use. In exchange for the
> fab fronting the upfront build cost of the fab for their customers, their
> fab is paid for over time at a higher total cost to the customer than the
> upfront cost to build in-house. Your choices are: pay much now,
> immediately, or pay much more, very slowly. If you've got cash flow
> but no cash, then the second choice is your only option.

...

It's a classic in-house vs. outsource decision. As fabs become more and
more expensive, and the technology continues to evolve faster than new
fabs can be built, the tradeoffs in that decision change. My son works
at TI, in the fab that makes DSPs. I get a lot of insights from him.

>> And all the desktop GPUs are essentially many-core architectures.
>>
>
> The GPU tasks are also well suited to parallel processing, unlike those
> of a microprocessor.

That isn't necessarily true, but it is true that the tasks for a GPU are
more well-defined than for microprocessors in general, so appropriate
design decisions can be made.

...

>
> Which modern programming languages effectively implement parallel
> processing today? How are they going to program this thing?

I don't see it as a language's responsibility to sort this out, but the
system architect's.

> If each core in a massively multi-core ARM microprocessor handles a distinct
> task, then it's no better than the multiple co-processor design used in the
> old Amiga computers.
> http://en.wikipedia.org/wiki/Amiga
>
> Since that's probably what's going to happen, i.e., distinct tasking of each
> core, let's make some guesses about what each core could be used for.
>
> 1 core for single-threaded OS
> 1 core for sound
> 1 core for 2D graphics
> 2 cores for video
>
> Wow, we've 11 to go ... Now what? 11 idling applications?

Who wants a single-threaded OS? and we've already discussed multicore
GPUs for the graphics. It's easy to see several cores involved in
streaming video. And there are numerous other I/O tasks. The list goes on.

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cmm> writes:
> Except for x86 and ARM, all the other early, major microprocessor
> manufacturers are dead.

x86 and ARM are not manufacturers. And tons of other architectures are
still doing fine, outside the general purpose 32/64-bit market.

> Every microprocessor design with great potential and great hype is dead too.
> Can you name one between 1974 and 2012 that isn't?

MSP430, doing fine. AVR (various incarnations), doing fine. MIPS, kind
of overshadowed by ARM but still doing fine (years ahead of ARM in
64-bit). PIC, doing fine. All sorts of DSP's, going like gangbusters.
Etc.

> If Zilog Z80 line of microprocessors hadn't died (converted into
> microcontrollers...), Zilog might have all of ARM's market, today.

Zilog had a 32 bit processor that wasn't very successful, iirc.

> Fabless is a _temporary_ solution ... for a major manufacturer to

> profit, they must control their own means of production and it's
> associated costs.

This is like saying that to publish a profitable magazine, you must own
your own printing facilities. No not really. You just have to get
people to pay enough per issue that you turn a profit. For expensive
magazines (technical journals, say) the printing costs don't really
figure into it.

[Anonymous]

"Elizabeth D. Rather" <era...@forth.com> wrote:

> On 9/29/12 2:30 PM, Paul Rubin wrote:
> > Bernd Paysan <bernd....@gmx.de> writes:
> >>> True, and they may be asking a bit much.
> >> AFAIK they already had a first round of founding for their 16 cores
> >> unit, with IIRC $2 million.
> >
> > Making chips is expensive. But once the chip is made, another $750k to
> > make a PC board with off-the-shelf parts around it? Or is it mostly for
> > software porting, or what?
>
> Don't forget marketing. It's expensive, and engineers often fail to
> appreciate both its expense and its necessity. Over the years I've been
> involved in many more projects that were marketing failures than
> technical failures.

If that isn't a good description of Forth I don't know what is!

[Bernd Paysan]

Rod Pemberton wrote:
> Does NVidia produce microprocessors? No ... They produce GPU's.
> They're different.

And what's the Tegra line? Never heard of it? And FYI: We are
discussion a project that is mostly competing with GPGPUs, not at all
with a typical general purpose microprocessor. It's also not using 16
ARM cores. Rod, it would be less of a waste of time if you just
followed the link the thread-starter provided. They also explain what
they want their money for. They actually have two goals, and yes, I
think their funding request is a bit high.

> It's typical for Bernd to support non-facts as facts.

It's a typical Rod to stick to his weird understanding of the world and
not let any facts intrude it. Dismissing everything outside your tiny
little box as non-fact, etc. I know why Hugh pushes his hate into clf,
but I don't know why you do. Can you get a real live? Go out for a
walk and step into some dog droppings to have a real reason for hating
the world?

> AFAIK, I don't lump and dump all processing devices into one category
> as you do.

Yes, I know, you twist words into different meanings so that you can be
"right" in a discussion by providing your twisted definition of words so
that everybody else must be wrong. You deliberately do the best you can
to misunderstand people.

>> But as Moore's law has an
>> exponential cost in fabs, they get fewer and fewer. Therefore,
>> fabless is the future.
>
> Fabless is a _temporary_ solution driven by cost pressures of building
> a new fab. No one wants to pay the large upfront cost anymore.

But fabs will become more expensive with every generation. How is that
going ot be "temporary"? Do you expect fabs to become cheap again?

>> Even AMD is now fabless. The years where they couldn't
>> fill their expensive fabs nearly killed them.
>
> Do they allow others to use their fabs? (No.)

Yes, they do. They sold it to GlobalFoundries, and it's free for
everyone.

> So, effectively the fab
> becomes a subsidiary via exclusive, contractual use. In exchange for
> the fab fronting the upfront build cost of the fab for their
> customers, their fab is paid for over time at a higher total cost to
> the customer than the upfront cost to build in-house.

If you can sell enough of your chips to fill your fab, it is worth the
cost. AMD can't - fab costs are essentially up-front costs, so you have
to utilize it fully. Even Intel now started to let others use their
fab; these projects are still tiny, and probably more about learning how
to become a fab than to utilizing the fabs completely. Intel will face
this problem in future, too. The output per fab grows faster than the
total output Intel produces, and once they only need one fab for
producing all their stuff, they will have to open up. They better start
learning now how to do that; Intel is not stupid, they won't risk their
business by doing it too late.

Back to parallel computing:

The fact that people can't write programs that utilize massive parallel
computing has only changed slightly. We now can use that for
supercomputing (number crunching) and graphics rendering. There are
still a lot of programs which don't scale well. But the tasks that do
scale well are important enough to sell massive parallel GPGPUs in high
volume. And they don't only sell into gamer PCs.

I'm *not* sceptical about the usefulness of GPGPUs. Not at all. They
sell, they are useful, they do awesome stuff, people sort-of understand
how to program them (in OpenCL and GLSL, which makes use of the vast
amount of parallelism). They have somewhat balanced memory access (the
main problem is to get the data from the host processor to the GPGPU,
the GPGPU itself is more balanced). They have enough internal memory.
They are a compromise, as they are optimized for gaming, not for
computing.

[Jecel]

On Sunday, September 30, 2012 3:38:43 AM UTC-3, Paul Rubin wrote:

> "Rod Pemberton" writes:
> > Every microprocessor design with great potential and great hype is dead too.
> > Can you name one between 1974 and 2012 that isn't?
>
> MSP430, doing fine. AVR (various incarnations), doing fine. MIPS, kind
> of overshadowed by ARM but still doing fine (years ahead of ARM in
> 64-bit). PIC, doing fine. All sorts of DSP's, going like gangbusters.
> Etc.

Exactly. And the PowerPC has 100% of the current generation videogame console market, besides still having a niche in embedded applications. A new version of the 6502 came out this year and the Z80 is also still being developed and sold. There are variations of the 68000 that also have their niche. And we shouldn't forget that though the 8051 has recently been surpassed by the ARM, it is still way more popular than the x86.

About the Transputer, I would say that though the T9000 was a major setback it was Inmos that failed and not the Transputer itself. That survived for a very long time as a ST product. And while Acorn had its share of problems, I don't remember ARM Limited having anything but success after its 1990 foundation.

-- Jecel

[gavino_himself]

On Friday, September 28, 2012 7:16:25 AM UTC-7, B.Person wrote:
> Posted 16 hours ago. Time to get into the ARM world; IMHO.
>
>
>
> http://arstechnica.com/information-technology/2012/09/99-raspberry-pi-sized-supercomputer-touted-in-kickstarter-project/

When $99 forth pc with a web browser? I will buy one.

[Rod Pemberton]

"gavino_himself" <visplo...@gmail.com> wrote in message
news:742fcec0-5ec7-4eac...@googlegroups.com...

> On Friday, September 28, 2012 7:16:25 AM UTC-7, B.Person wrote:
> > Posted 16 hours ago. Time to get into the ARM world; IMHO.
> >
>

> When $99 forth pc with a web browser? I will buy one.

You can by any x86 computer or laptop with a 486DX2 or more recent processor
that will execute a web browser. Some are likely less than $99 today. Why
does it need to be a Forth computer or laptop for you to buy it?


Rod Pemberton

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message

news:10709389....@sunwukong.fritz.box...
> Rod Pemberton wrote:
...

> And FYI: We are discussion a project that is mostly
> competing with GPGPUs, not at all
> with a typical general purpose microprocessor.

I see nothing in either of the two articles related to "GPGPUs" or GPUs.

So, where do you get that? Or, why do you think that?

> It's also not using 16 ARM cores.

True. However, that's an error by the authors of second article, at the
link I posted. The wording of the first article is not especially clear
that's the case either. It implies the RISC cores are ARM, not Adapteva's
own RISC cores. It's poorly phrased.

And, stop ignoring the point. It's irrelevant if the cores are ARM cores,
or x86 cores, or even 6502 cores.

The point is that it's going to be difficult to maximize usage of the
multiple cores for many tasks. A novice home user will never be able
accomplish it. The cores are only programmable in three languages: C, C++,
and something no one knows ... So, that limits the ability to develop for
the processor even further. The language no one knows: OpenCL, is C derived
and the only one of the three that supports parallel processing. This is
even more limiting. I.e., programming this thing requires expert
programming skills in C or C++ and use of OpenCL. Yet, the project is
supposedly developing the processor for the novices in the general public
and home hobbyists. Does that really make sense to you? This combination
is doomed.

> You deliberately do the best you can to misunderstand people.

No, I don't.

> >> But as Moore's law has an
> >> exponential cost in fabs, they get fewer and fewer. Therefore,
> >> fabless is the future.
> >
> > Fabless is a _temporary_ solution driven by cost pressures of building
> > a new fab. No one wants to pay the large upfront cost anymore.
>
> But fabs will become more expensive with every generation.

True and still irrelevant.

> How is that going ot be "temporary"?

No, I expect one or two companies will eventually realize that the entire
industry outsourced their fabs to eliminate the upfront cost of
manufacturing a fab. They'll also realize that if their competitors are
outsourcing the fab work and if they build and own their own fab, that their
competitors will be at a competitive disadvantage financially. They'll be
able to generate more profit, since they aren't outsourcing. Of course, the
nature of financial competition for profit requires a company to not be at a
competitive disadvantage financially relative to their competitors. Once
they learn that their competition is making more profit by owning their own
fab, they'll be forced to build a fab too or risk going out of business.
Over time, the industry will slowly shift from fabless to owning fabs.

If you don't understand this, you need to read about the American automotive
industry sometime. They went through the same process. The cost of
building a manufacturing plant became "astronomical". They outsourced.
They sold off old plants. Then, one or two started building plants again to
boost profits and disadvantage their competition. Now, they're all building
plants. The plants are smaller, use less labor, use lower cost labor, have
more robotics, are more efficient. In fact, the automotive industry has
gone through just about everything that has ever happened to any major
industry. I.e., what's happening to the semiconductor industry today has
all happened before, but for different industries.

> Do you expect fabs to become cheap again?

It has nothing to do with the cost of the fab. It has to do with the total
cost of the fab versus total cost outsourcing. The latter is more
expensive.

> If you can sell enough of your chips to fill your fab,
> it is worth the cost.

If they can't, they overbuilt. They should build smaller fabs next time.

> AMD can't - fab costs are essentially up-front costs, so you have
> to utilize it fully.

So, they pay more.

> Even Intel now started to let others use their
> fab; these projects are still tiny, and probably more about learning how
> to become a fab than to utilizing the fabs completely. Intel will face
> this problem in future, too. The output per fab grows faster than the
> total output Intel produces, and once they only need one fab for
> producing all their stuff, they will have to open up. They better start
> learning now how to do that; Intel is not stupid, they won't risk their
> business by doing it too late.

If they don't need the volume that a fab can produce for their own
production, they're better off selling it. They can recover more capital
that way. When opening up production to outside, the plant owner still has
to pay fixed costs and plant operating costs, and labor costs. When they
sell it, they don't.


Rod Pemberton

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cmm> writes:
> The point is that it's going to be difficult to maximize usage of the
> multiple cores for many tasks. A novice home user will never be able
> accomplish it.

I didn't get the sense this board was intended for "novice home users"
to program. It could be that some home users would buy the boards to
run programs written by hypothetical developers, or else that
programmers would buy the boards as cheap development systems to write
code for embedded targets.

> The cores are only programmable in three languages: C, C++, and
> something no one knows ...

OpenCL is a well-accepted GPU language that's a less proprietary
alternative to CUDA. Anyone who knows anything about GPU programming
knows what it is.

> It has nothing to do with the cost of the fab. It has to do with the total
> cost of the fab versus total cost outsourcing. The latter is more
> expensive.

The fab is an awfully large cost up front. The company making this chip
is roughly in the same boat as Green Arrays. They want to make this 64
core thing in 28nm. That's a very high tech, expensive process.

While they are working on getting a fab, maybe they can also get the
company cafeteria to stop buying vegetables from vendors, and instead
grow them themselves to save money. That's less crazy than what you're
suggesting.

[Bernd Paysan]

Rod Pemberton wrote:

> "Bernd Paysan" <bernd....@gmx.de> wrote in message
> news:10709389....@sunwukong.fritz.box...
>> Rod Pemberton wrote:
> ...
>
>> And FYI: We are discussion a project that is mostly
>> competing with GPGPUs, not at all
>> with a typical general purpose microprocessor.
>
> I see nothing in either of the two articles related to "GPGPUs" or
> GPUs.
>
> So, where do you get that? Or, why do you think that?

I tried to find more meat, and downloaded an adapteva_mpr.pdf paper
(from MPRonline.com). There, they compare it with other cores, both a
Coretex A9 and a Vivante GC2000. The latter compares better than the
A9, and it is a GPU.

> I.e., programming this thing requires expert
> programming skills in C or C++ and use of OpenCL. Yet, the project is
> supposedly developing the processor for the novices in the general
> public and home hobbyists. Does that really make sense to you? This
> combination is doomed.

This is exactly the same combination people use to program big
supercomputers (ok, add Fortran into that mix ;-). And if you actually
bother to read the title of the thread, you see the word "supercomputer"
in it.

The thing is: Hobbyists have been trying a number of quite weird things
in the past, if these toys are just cheap enough. They have bought
Arduino boards to figure out what this embedded 8 bit microcontroller
thingy is; they are even willing to look at Forth on an Arduino.

You misunderstand what sort of "home hobbyist" this device is targetting
now: Not the people who are in the iPhone 5 queue. It's more about
geeks who want a new toy, to learn OpenCL. Novices in parallel
computing, not novices in programming.

The student (he's no longer student, and has a job now) in our Munich
Forth group, who plays with the GA144 is clearly also a home hobbyist.
There are hobbyists who do these strange things ;-).

>> You deliberately do the best you can to misunderstand people.
>
> No, I don't.

Yes, you do. Whatever word has more than one meaning, you always pick
the wrong one. I'll attribute it to incompetence instead of maliciousy
any day, and accept that you don't even realize what you are doing.

> Once they learn that their competition is making more profit by owning
> their own fab, they'll be forced to build a fab too or risk going out
> of business. Over time, the industry will slowly shift from fabless to
> owning fabs.

Well, we have these few companies who have their own fabs, and
especially Intel has always made more profit than anybody else. The
rest just struggles, and as consequence either opens up their fab to
others, or become fabless.

It's another misunderstanding of you: You absolutely have to fill your
fab. For memory makers, it's cut-throat; they have been dying like
flies in the past years.

> I.e., what's happening to the semiconductor industry today
> has all happened before, but for different industries.

Detroit is pretty special, with its combination of American management
("outsource everything") and strong unions. The semiconductor industry
did something completely different: They separated making and designing.
This is very natural, as the semiconductor industry is a "printer"
industry. The making is litography, i.e. printing. There are some
businesses in the printing industry where you need the press in-house
(newspapers, e.g.), but usually, the design (the writing) is separated
from the replication (the printing).

Maybe there will be some disruptive technology in future that allows
fabs to become much smaller again - as was with printing, when the laser
printer allowed everybody again to have his own "printing press".

>> Do you expect fabs to become cheap again?
>
> It has nothing to do with the cost of the fab. It has to do with the
> total cost of the fab versus total cost outsourcing. The latter is
> more expensive.

You can make smaller fabs, but these are less efficient - older
processes, smaller wavers, less output. The people who have small fabs
use old equipment and have their niche where this is profitable -
discretes, small analog components.

>> If you can sell enough of your chips to fill your fab,
>> it is worth the cost.
>
> If they can't, they overbuilt. They should build smaller fabs next
> time.

With smaller wavers? The fabs are "overbuild", because there still is a
big economy of scale there, and the money for the equipment maker comes
from big companies like Intel, TSMC, and Samsung. They want really big
fabs.

>> AMD can't - fab costs are essentially up-front costs, so you have
>> to utilize it fully.
>
> So, they pay more.

Yes. They did pay considerably more than they do now. It was killing
them.

> If they don't need the volume that a fab can produce for their own
> production, they're better off selling it.

Yes, so you finally got it. That's why they went fabless. And when you
start as a relatively small design house, you will be fabless from day
one, and never consider building your own fab. That's just a completely
different business.

[rickman]

On 9/30/2012 2:38 AM, Paul Rubin wrote:
> "Rod Pemberton"<do_no...@notemailnotz.cmm> writes:

>> Every microprocessor design with great potential and great hype is dead too.
>> Can you name one between 1974 and 2012 that isn't?
>
> MSP430, doing fine. AVR (various incarnations), doing fine. MIPS, kind
> of overshadowed by ARM but still doing fine (years ahead of ARM in
> 64-bit). PIC, doing fine. All sorts of DSP's, going like gangbusters.
> Etc.

Really, MIPS has been around almost as long as I have been. They are
far from dead, but not growing much from what I hear, while ARM is going
like gang busters.

>> If Zilog Z80 line of microprocessors hadn't died (converted into
>> microcontrollers...), Zilog might have all of ARM's market, today.
>
> Zilog had a 32 bit processor that wasn't very successful, iirc.

I think it came at a time when nearly all of the makers were going the 8
to 16 to 32 bit route and some who didn't even have CPUs were coming out
with one, like National. Too much competition and in the end it came
down to firstest with the mostest, Motorola and Intel.

>> Fabless is a _temporary_ solution ... for a major manufacturer to
>> profit, they must control their own means of production and it's
>> associated costs.
>
> This is like saying that to publish a profitable magazine, you must own
> your own printing facilities. No not really. You just have to get
> people to pay enough per issue that you turn a profit. For expensive
> magazines (technical journals, say) the printing costs don't really
> figure into it.

I don't think there is much comparison between the publishing industry
and semiconductors. Magazines can be printed by nearly anyone. In
semiconductors there is a very important link between having a great fab
process and having a profitable product line. This is paramount when
you are pumping huge volumes of chips out with low profit margins like
SDRAM and Flash. When you are making high profit margin devices like
desktop and laptop CPUs you can tolerate the lost margin of a middleman
if it gets you a leading edge process.

That is the ONLY way AMD can hope to survive in Intel's market. AMD is
only around at this point because they got well over a billion dollars
from Intel a couple of years ago. Since then they have steadily gone
down hill from what I have seen. I don't expect them to be around in
five years. They will end up being sold off, likely in pieces and Intel
will have to worry about the FTC.

Other companies don't necessarily need their own fabs. Fabless seems to
be doing well for Xilinx. Have they built any fabs yet? Isn't Altera
also fabless these days? I'm not a close observer of semicoductor
companies these days, but I don't think the FPGA industry spends a lot
of time worrying about building their own fabs. They just find a fab
house with good processes and work with them to get what they need.

Rick

[Ed]

Which - a technical or marketing failure? :)

Paul's observation applies equally to Forth:

"It also helps to have concrete evidence that what you're doing
fills a need, instead of being a solution looking for a problem."

Marketing generates initial interest. For it to be sustainable there
must be ongoing need. How many programming languages does
the world need to sustain in any given era? Not that many.

[Bernd Paysan]

rickman wrote:
> That is the ONLY way AMD can hope to survive in Intel's market. AMD
> is only around at this point because they got well over a billion
> dollars from Intel a couple of years ago.

It's the other way round. Intel's unfair practises did cost AMD a
fortune (in the early Athlon64 days, AMD had the better processor, the
better price, the better ISA, the better everything - and yet, Intel
managed to keep their market share), and the one billion dollar
compensation was "next to nothing".

> Since then they have steadily gone
> down hill from what I have seen. I don't expect them to be around in
> five years. They will end up being sold off, likely in pieces and
> Intel will have to worry about the FTC.

They already have sold parts - they have sold their fab. And they had
to bite the bullet and buy ATI, which was also quite expensive, but
absolutely necessary (Intel shows how difficult it is to make a good
GPGPU architecture - they can't do it. They will probably have to buy
Nvidia to be competitive). At the moment, AMD is doing better than
before, they almost make a profit.

> Other companies don't necessarily need their own fabs. Fabless seems
> to
> be doing well for Xilinx. Have they built any fabs yet? Isn't Altera
> also fabless these days? I'm not a close observer of semicoductor
> companies these days, but I don't think the FPGA industry spends a lot
> of time worrying about building their own fabs. They just find a fab
> house with good processes and work with them to get what they need.

All of them are fabless.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message

news:2175391.u...@sunwukong.fritz.box...

> Rod Pemberton wrote:
> > "Bernd Paysan" <bernd....@gmx.de> wrote in message
> > news:10709389....@sunwukong.fritz.box...
> >> Rod Pemberton wrote:
...

> > I.e., programming this thing requires expert
> > programming skills in C or C++ and use of OpenCL. Yet, the project is
> > supposedly developing the processor for the novices in the general
> > public and home hobbyists. Does that really make sense to you? This
> > combination is doomed.
>
> This is exactly the same combination people use to program big
> supercomputers (ok, add Fortran into that mix ;-). And if you actually
> bother to read the title of the thread, you see the word "supercomputer"
> in it.
>

If you had bothered to read the title of the thread, you'd see it also says
"your", as in me or you or anyone else. So, the point remains valid. It
says "next" too, as if everyone reading or posting here already has a
supercomputer crushing the concrete in their basement ... ;-)

> You misunderstand what sort of "home hobbyist" this device is targetting
> now: Not the people who are in the iPhone 5 queue. It's more about
> geeks who want a new toy, to learn OpenCL. Novices in parallel
> computing, not novices in programming.

I see no such "restriction".

Why did you both introduce "home hobbyist" and define what it means?

If you had read the article at the first link, you'd see that Adapteva
doesn't define who uses it as "home hobbyist" either. It lists
"enthusiasts", "hobbyists", and "developers". If you've got $99 and buy one
for yourself, you're one of the three. Your choice.

> >> You deliberately do the best you can to misunderstand people.
> >
> > No, I don't.
>
> Yes, you do. Whatever word has more than one meaning, you
> always pick the wrong one.

I'm a native speaker of English. I have a large vocabulary. I can speak
and write at an advanced level. So, how can you legitimately say that? In
a group like this, I prefer to write at a level similar to what would be
spoken, but a bit more fluently, precisely, accurately.

I don't translate to English through an intermediate language. I don't
mentally process concepts in a non-English language. Many of your
statements remind me of a few students I once worked with who spoke Chinese
and were learning English. They had a few pronunciation problems and
problems with pronouns. You have a few spelling problems and a few
comprehension issues. I've mentioned one of your misspellings more than a
few times. They understood the literal meanings of words, but had problems
grasping the concept of the words together, such as a phrase, sentence, or
paragraph. You do the same, but at a higher, more functional level. I.e.,
it's less noticeable, but still present. They mentally translated from
English to Chinese, processed the idea, translated from Chinese back to
English. Something becomes lost when that's done. The nuances of English
meaning are glossed over or ignored. They needed to learn to think in
English.

Actually, talking to you sometimes is a bit like talking to two people: one
who is fairly adept at English, and one who learned English as a second
language. Do you have someone helping you?

> It's another misunderstanding of you: You absolutely have to
> fill your fab. For memory makers, it's cut-throat; they have
> been dying like flies in the past years.

What's wrong with making a smaller fab? It's one way to fill your fab.

> > I.e., what's happening to the semiconductor industry today
> > has all happened before, but for different industries.
>
> Detroit is pretty special, with its combination of American management
> ("outsource everything") and strong unions. The semiconductor industry
> did something completely different: They separated making and designing.

So did the automotive industry, circa the early 1990's. Many of them moved
design from Detroit to California, Italy, Taiwan, Korea, China, etc.

> This is very natural, as the semiconductor industry is a "printer"
> industry. The making is litography, i.e. printing.

You mean lithography, not "litography". Specifically, it's
photolithography.

> There are some businesses in the printing industry where you need
> the press in-house (newspapers, e.g.), but usually, the design
> (the writing) is separated from the replication (the printing).
>

There you go again with the "lump and dump" - conflating lithography with
photolithography.

Photolithography is too highly specialized to compare it to the printing of
book and newspapers. Basically, you're conflating a simple process of
placing ink on paper with a complex process such as chemical etching and
vapor deposition of elements, like silicon, gallium, or arsenic, and also
re-classifying the work numerous Electrical Engineers as that of mere
wordsmiths.

> >> Do you expect fabs to become cheap again?
> >
> > It has nothing to do with the cost of the fab. It has to do with the
> > total cost of the fab versus total cost outsourcing. The latter is
> > more expensive.
>
> You can make smaller fabs, but these are less efficient - older
> processes, smaller wavers, less output. The people who have small fabs
> use old equipment and have their niche where this is profitable -
> discretes, small analog components.
>

Small doesn't mean less output. It depends on your rate of production.
Fast machines and three shifts a day can produce as much as a single shift
plant with large, slow machines. Most large factories use increased scale
as a replacement for speed, i.e., large, slow machines instead of fewer
smaller, faster machines.

Do you know what a related-rate problem is?

> >> If you can sell enough of your chips to fill your fab,
> >> it is worth the cost.
> >
> > If they can't, they overbuilt. They should build smaller fabs next
> > time.
>
> With smaller wavers? The fabs are "overbuild", because there still is a
> big economy of scale there, and the money for the equipment maker comes
> from big companies like Intel, TSMC, and Samsung. They want really big
> fabs.
>

These machines are all custom. There is nothing requiring them to be
constructed for large capacities. A bread baking machine in bread factory
or a sheet glass machine in a glass factory are sometimes over thousands of
feet long and hundreds of feet wide. But, nothing requires that they be
made that large. The can be made for whatever size is required. The
process and machine size are not linked. It's just a matter of planning,
design, and money.

> > If they don't need the volume that a fab can produce for their own
> > production, they're better off selling it.
>
> Yes, so you finally got it. That's why they went fabless.

That just indicates they overbuilt. There is still a financial advantage to
owning your own fab. They can make them smaller or more efficient, if they
want.


Rod Pemberton

[Bernd Paysan]

Rod Pemberton wrote:
> I don't translate to English through an intermediate language. I
> don't mentally process concepts in a non-English language.

I don't say so. You just want to misunderstand people and therefore
choose the most inapropriate meaning of an ambiguous term in the next
round.

> You have a few spelling problems and a few
> comprehension issues. I've mentioned one of your misspellings more
> than a few times.

And you even needed to correct your own spelling... anal-retentive
stuff. Nobody else bothers here about the occasional mis-spelling. I
occasionally misspell in my own language, too, we all do, we respond to
that by doing best effort to try to understand what was written. This
is not a problem, apart for anal-retentive spelling Nazis, as we call
them in Germany. Why do you do it? It contributes *nothing* to the
discussion.

> They understood the literal meanings of words, but had
> problems grasping the concept of the words together, such as a phrase,
> sentence, or
> paragraph. You do the same, but at a higher, more functional level.
> I.e.,
> it's less noticeable, but still present.

I don't translate English into something else, particularly not into
Chinese. When I speak Chinese (my fourth language), I try not to
translate, either, it's a rather futile thing to do (Chinese words are
about as ambiguous as English words, but the different meanings they
cover is completely orthogonal - one English word translates to 5
Chinese words, and one of these Chinese words translate to 5 different
English words, which clearly aren't synonyms). I try to think in
Chinese. It's one of the things I would encourage every language
student: Try to think in the target language, don't try to translate.

However, I think you don't follow Postel's advice for communication: If
you speak to someone else, try to understand, not try to misunderstand.
If there's an interpretation that fits your understanding of things,
it's probably that you and I are in agreement. There's no need to find
the interpretation where we disagree.

Maybe you are not aware of the ambiguousities, because you don't know
any other language. Particularly Chinese is an eye-opener for that,
because you suddenly realize how context-sensitive the words in your own
language are, and how much you need to know the context to understand
Chinese, because the words there simply don't map to our words. Words
have a meaning only in context.

> Actually, talking to you sometimes is a bit like talking to two
> people: one who is fairly adept at English, and one who learned
> English as a second language. Do you have someone helping you?

No. I have definitely learned English as a second language, and don't
have someone helping me. It's just sometimes you don't understand me;
and I don't think in these cases it is my fault.

>> It's another misunderstanding of you: You absolutely have to
>> fill your fab. For memory makers, it's cut-throat; they have
>> been dying like flies in the past years.
>
> What's wrong with making a smaller fab? It's one way to fill your
> fab.

It's less efficient, i.e. the price per die will be higher. They don't
build bigger fabs for the fun of it, but because they want to be cheaper
than the competition. Furthermore, there aren't many companies who make
equipment; for leading edge processes, you essentially have to buy from
one company in the Netherlands (ASML); they have a sort-of (natural)
monopoly on the most important component - the stepper. That however
means that the equipment is designed for those who are willing to pay
the price - and those are the big manufacturers who want big fabs.

>> The semiconductor
>> industry did something completely different: They separated making
>> and designing.
>
> So did the automotive industry, circa the early 1990's. Many of them
> moved design from Detroit to California, Italy, Taiwan, Korea, China,
> etc.

Stop saying "automotive industry" when you want to say "Detroit". I
applied Postel's principle, and I clearly figure out that you use the
words "automotive industry" as synonym for "Detroit", and you ignore the
rest of the world, which also has their automotive industries.

Only Detroit destroyed itself by outsourcing everything to some other
place. Furthermore, when you say something like "moved design to
Italy", it sounds as if Italians haven't made cars before. FIAT is 9
years older than GM (the old GM, the one founded in 1908 which went
bankrupt 100 years later). You probably wouldn't say GM "moved design
to Germany", because, yes, they do (Opel), but that would make you sound
silly. Outsource it to the country where the car was invented? Maybe a
good idea (but Opels are rather lousy cars for German standards, though
they are clearly better than GM cars in America).

>> This is very natural, as the semiconductor industry is a "printer"
>> industry. The making is litography, i.e. printing.
>
> You mean lithography, not "litography". Specifically, it's
> photolithography.

See, you are doing it again. You perfectly understood me, but you think
it's worth to show off that your English is better than mine. What's
the point? It's supposed to pronounce "lit^{h}ography", but you
probably pronounce it with a fricative "th" (as in modern greek and
English, but this is supposed to be pronounced as ancient greek, where
theta was a plosive).

>> There are some businesses in the printing industry where you need
>> the press in-house (newspapers, e.g.), but usually, the design
>> (the writing) is separated from the replication (the printing).
>>
>
> There you go again with the "lump and dump" - conflating lithography
> with photolithography.

You apparently have an abstraction/analogies problem, you see the
differences but miss the similarities. The essence of lithography and
photolithography is that both make cheap replications possible -
replications of drawings, of books, of integrated circuits, and that the
replication process is independent of the creation process.

> Photolithography is too highly specialized to compare it to the
> printing of
> book and newspapers. Basically, you're conflating a simple process of
> placing ink on paper with a complex process such as chemical etching
> and vapor deposition of elements, like silicon, gallium, or arsenic,
> and also re-classifying the work numerous Electrical Engineers as that
> of mere wordsmiths.

Uh-oh. A writer or a painter who creates an *original*, which later is
replicated by printing, is an artist, his profession is not to do the
replication, but to create the original. As is the EE's task, who
creates a circuit, which is then "printed" in the fab. Both professions
require skills, quite different skills, but good writers are even rarer
than good EEs.

The fab however is not doing EE. They are doing lithography and
chemistry, their expertise is to control the process and keep the yield
high - they essentially operate really, really high-tech printers. It's
a well more advanced way of doing it than printing a newspaper, but the
essence is doing many, many cheap replications.

I've designed chips from top to botton, including (one time) device
engineering, which means creating a new type of transistor that wasn't
available in the design kit before.

However, I never was directly involved in *any* sort of actual
processing of the silicon in the fab, even during the years at Zetex,
which had their own fab (used e.g. for the low-scale integration analog
compagnion of the digital audio amplifier I developed there). Fab
people are not EEs. You confuse a printer with a writer. We visited
fabs to see how they do it and of course we talked to the fab people, so
we need some understanding of what they do. As in writing, between the
EE and the fab, there is a layouter - named the same way as the layouter
who does the typesetting of the words the writer has written down.

>> You can make smaller fabs, but these are less efficient - older
>> processes, smaller wavers, less output. The people who have small
>> fabs use old equipment and have their niche where this is profitable
>> - discretes, small analog components.
>>
>
> Small doesn't mean less output. It depends on your rate of
> production. Fast machines and three shifts a day can produce as much
> as a single shift plant with large, slow machines.

Rest assured that all high-end fabs around the world have the fastest
machines available, and are operated 24/7.

> Most large factories use increased
> scale as a replacement for speed, i.e., large, slow machines instead
> of fewer smaller, faster machines.

Have you ever been inside a fab? The machines are not particularly
large, they are room-height, the steppers are 2-3x5-10m or such, the
rest of the equipment is slightly smaller. In the free space, they have
robots to carry wafer trays from one machine to the next (the robots
don't look like R2D2, they are just a cross between cranes and small
railroads).

> Do you know what a related-rate problem is?

Yes. But this is completely irrelevant here.

> These machines are all custom.

Actually not. They are mass produced. For a not that big amount of
"mass", but they are definitely not built to order. Just look up
asml.com, they have nice photos, where you also can look inside the
machines. The steppers are the most essential machines for a fab, there
are other machines for etching and CVD, which however look similar from
the outside (they are all sealed to keep the dust out). The stepper is
doing the actual copying: mask to wafer. They can expose >100 wafers
per hour, so they aren't really slow. The rest of the equipment, the
CVD and etching, have comparable throughput rates, but you should
understand that each individual wafer stays for hours in any such
machine. The size of each of these things is similar to a stepper, see
for example this one, which set a record of 120wph:

http://www.novellus.com/products/product_lines/altus/

> There is nothing requiring them to be
> constructed for large capacities. A bread baking machine in bread
> factory or a sheet glass machine in a glass factory are sometimes over
> thousands of
> feet long and hundreds of feet wide. But, nothing requires that they
> be
> made that large. The can be made for whatever size is required. The
> process and machine size are not linked. It's just a matter of
> planning, design, and money.

Well, the semiconductor industry buys standard off-the-shelf products.
Lego bricks to build your fab, so to speak. The bricks get bigger and
bigger, though. When I visited the .35µm fab of AMS 10 years ago, the
stuff was a lot smaller than it is now for 32nm and below.

>> > If they don't need the volume that a fab can produce for their own
>> > production, they're better off selling it.
>>
>> Yes, so you finally got it. That's why they went fabless.
>
> That just indicates they overbuilt.

They have to buy and install new equipment every two years, so many
chances to correct that mistake. I don't think they overbuilt.

Let's look at the data: TSMC's 28nm fab has now 24k wafer starts per
month (and that's actually rather small, this is still in learning and
growing mode; GlobalFoundries combined 32/28nm fab has 50k wafer starts
per month and wants to grow to 80k, because now they have the customers,
not just AMD). ASML's twinscan XL, which is the appropriate stepper for
that fab, has 150wph, or 108k per month. It takes around 40 masks to
process a complete wafer (20 of them are metals and vias), so TSMC needs
only 10 of these steppers, if they are 100% utilized.

There isn't much room for less. Several process steps like the tungsten
contacts (done with the Altus linked above) are only done once per wafer
(contacts and local interconnects), and you want to utilize the entire
fab 100%. The single Altus with its 120wph is good for more than 80k
wafers per month. They won't sell that many of them; low two-digits, I
guess. I hope this illustrates the problem: The machines are quite
small and fast, but really, really expensive.

> There is still a financial advantage to
> owning your own fab. They can make them smaller or more efficient, if
> they want.

It's a fairly trivial calculation: Suppose your external fab has a cost
disadvantage of 30% per wafer - that's the profit they want to make.
Because they fab for everybody, they can fill their big, big fab, and
make it very efficient, by having 100% utilization for everything, and a
good yield. If they succeed to be 30% more efficient than your small
fab, the deal is done: Go fabless.

There was a time where you did need your own fab, that was during the
GHz race. Fabs like TSMC didn't offer the special processes you needed
for high-end processors; their processes were tuned for general purpose
ASICs, which didn't need that speed.

This has changed since. TSMC still has slower transistors, but Samsung,
GlobalFoundries, and IBM can provide you with the right processes to
build your supercomputer. And they are all open to the public, only
Intel's one half step ahead process isn't. And that lead is in danger:
ASML has troubles to make the EUV steppers production ready, and now all
the big fab companies and Intel did a joint investment into ASML, and
the result will be that everybody will get the new steppers at the same
time - Intel always paid a premium to get them first.

IMHO, apart from Intel and the memory makers, nobody today benefits from
having their own fab. The memory makers benefit, because they have
special needs (separate steps for the capacitors, which nobody else
makes, and still only two metal layers), and cut-throat competition.
Maybe with RRAM, that will go away - apparently it is possible to make
resistive RAMs with standard processes, i.e. without any special
equipment, and you also benefit from the many metal layers.

[Paul Rubin]

"Rod Pemberton" <do_no...@notemailnotz.cmm> writes:
> Photolithography is too highly specialized to compare it to the printing of
> book and newspapers. Basically, you're conflating a simple process of
> placing ink on paper with a complex process such as chemical etching and
> vapor deposition of elements

"Printing" is a term I've heard for chip manufacture several times in
the past few years, from people in the industry. I thought it was a
one-off simplification the first time I heard it, but then I heard other
people say it too. I think it may be a fairly recent idiom.

[Fritz Wuehler]

"Ed" <inv...@nospam.com> wrote:

> Anonymous wrote:
> > "Elizabeth D. Rather" <era...@forth.com> wrote:
> >
> > > On 9/29/12 2:30 PM, Paul Rubin wrote:
> > > > Bernd Paysan <bernd....@gmx.de> writes:
> > > >>> True, and they may be asking a bit much.

> > > Don't forget marketing. It's expensive, and engineers often fail to
> > > appreciate both its expense and its necessity. Over the years I've been
> > > involved in many more projects that were marketing failures than
> > > technical failures.
> >
> > If that isn't a good description of Forth I don't know what is!
>
> Which - a technical or marketing failure? :)

Forth seems to be a good example of a marketing failure that isn't a
technical failure. It's a simple, flexible tool that just doesn't get any
respect!

> Paul's observation applies equally to Forth:
>
> "It also helps to have concrete evidence that what you're doing
> fills a need, instead of being a solution looking for a problem."

Aside from talking about it, which is what this newsgroup is and should be
about, there are people using Forth or Elizabeth and Stephen probably
couldn't afford their internet connections and websites. Without any
additional context from your quote, I don't see Forth as a solution looking
for a problem. There are many niche tools and domain specific languages that
are not popular or widely known, yet they serve a purpose and are in active
use.

Really, the statement you quoted is troubling not from a Forth point of
view, but consider all the graphical crap and web programming that probably
make up 99% of all code written today...if that junk isn't a solution
looking for a problem I don't know what is. We got business done with text
interfaces for many years and I don't see any benefit except for teenagers
and H1Bs in reducing programming to flash webpages. Doesn't anybody write
code that actually *does* something anymore?

>
> Marketing generates initial interest. For it to be sustainable there
> must be ongoing need. How many programming languages does
> the world need to sustain in any given era? Not that many.

In theory that seems reasonable. In practice there seems to be no limit to
the number of programming languages in use and no end in sight when it comes
to creating new ones.

[Elizabeth D. Rather]

On 10/3/12 7:10 AM, Fritz Wuehler wrote:
> "Ed" <inv...@nospam.com> wrote:
>
>> Anonymous wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> wrote:

...

>>>> Don't forget marketing. It's expensive, and engineers often fail to
>>>> appreciate both its expense and its necessity. Over the years I've been
>>>> involved in many more projects that were marketing failures than
>>>> technical failures.
>>>
>>> If that isn't a good description of Forth I don't know what is!
>>
>> Which - a technical or marketing failure? :)
>
> Forth seems to be a good example of a marketing failure that isn't a
> technical failure. It's a simple, flexible tool that just doesn't get any
> respect!

I agree with that.

>> Paul's observation applies equally to Forth:
>>
>> "It also helps to have concrete evidence that what you're doing
>> fills a need, instead of being a solution looking for a problem."
>
> Aside from talking about it, which is what this newsgroup is and should be
> about, there are people using Forth or Elizabeth and Stephen probably
> couldn't afford their internet connections and websites. Without any
> additional context from your quote, I don't see Forth as a solution looking
> for a problem. There are many niche tools and domain specific languages that
> are not popular or widely known, yet they serve a purpose and are in active
> use.

Yes, Forth was designed from the ground up to address a particular
real-world problem: the need for flexible programming for
resource-constrained systems. The fact that it is still in use today,
mostly in embedded systems, is a testimony to the fact that it is
successful for that purpose, and that the need still exists. In the
world of embedded processors, unit costs count a lot, and your ability
to do more with whatever resources you have translates to success with
your product.

The remarkable thing is that Forth has also been successful in
environments that are not resource-constrained (e.g. PCs) because of its
flexibility and ease of use.

[van...@vsta.org]

> Forth seems to be a good example of a marketing failure that isn't a
> technical failure. It's a simple, flexible tool that just doesn't get any
> respect!

It's a powerful macro assembler for a stack based machine language.
The problem is that it can take your $0.23 problem and do it for $0.17--
a 25% savings! But everybody has pockets stuffed full of $20 bills,
so nobody cares. I think Chuck Moore was smart to head towards where
the pennies still matter.

--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[Bernd Paysan]

van...@vsta.org wrote:

>> Forth seems to be a good example of a marketing failure that isn't a
>> technical failure. It's a simple, flexible tool that just doesn't get
>> any respect!
>
> It's a powerful macro assembler for a stack based machine language.

This is the low-level view of Forth. Systems like my b16 cross compiler
could fit into that description. You miss the interactive part, and you
miss the extensibility part - yes, maybe it's hidden in the word
"powerful", but usually, I would describe other macro assemblers as
"powerful", too, even though they are neither interactive nor allow me
to extend them.

> The problem is that it can take your $0.23 problem and do it for
> $0.17--
> a 25% savings! But everybody has pockets stuffed full of $20 bills,
> so nobody cares.

The perception I have of my 512MB 800MHz single core phone is that of a
very resource constrained environment - when I run normal Dalvik
programs. Of course it isn't a resource constrained environment for a
Forth system, it is like heaven - there is plenty of RAM, there is a
fast CPU and GPU, etc. But apparently, people programming in Java can
make this overengineered thing very slow ang sluggish. I *do* care.

I've heard that with 2GB and a 1.6GHz quadcore, Android will feel a lot
better. m(

[Ed]

Fritz Wuehler wrote:
> "Ed" <inv...@nospam.com> wrote:
>
> > Anonymous wrote:

> > > ...

> > > If that isn't a good description of Forth I don't know what is!
> >
> > Which - a technical or marketing failure? :)
>
> Forth seems to be a good example of a marketing failure that isn't a
> technical failure. It's a simple, flexible tool that just doesn't get any
> respect!
>
> > Paul's observation applies equally to Forth:
> >
> > "It also helps to have concrete evidence that what you're doing
> > fills a need, instead of being a solution looking for a problem."
>
> Aside from talking about it, which is what this newsgroup is and should be
> about, there are people using Forth or Elizabeth and Stephen probably
> couldn't afford their internet connections and websites. Without any
> additional context from your quote, I don't see Forth as a solution looking
> for a problem. There are many niche tools and domain specific languages that
> are not popular or widely known, yet they serve a purpose and are in active
> use.

Yes but who can make a living from them? For each success claimed by a
niche language, there will be hundreds written using mainstream languages
and tools. If one wants to make a living from programming one must go to
where the work is.

[Elizabeth D. Rather]

On 10/3/12 5:40 PM, Ed wrote:
...

>> Aside from talking about it, which is what this newsgroup is and should be
>> about, there are people using Forth or Elizabeth and Stephen probably
>> couldn't afford their internet connections and websites. Without any
>> additional context from your quote, I don't see Forth as a solution looking
>> for a problem. There are many niche tools and domain specific languages that
>> are not popular or widely known, yet they serve a purpose and are in active
>> use.
>
> Yes but who can make a living from them? For each success claimed by a
> niche language, there will be hundreds written using mainstream languages
> and tools. If one wants to make a living from programming one must go to
> where the work is.

Well, I made a living from Forth for over 30 years (I'm mostly retired
now). There has always been work, and continues to be for Leon Wagner
and his colleagues at FORTH, Inc. It's not about the numbers... yes,
there are still more projects in C and more recent languages, but there
is still a need for Forth in the companies that want to really get the
most out of their products.

[Anonymous]

"Ed" <inv...@nospam.com> wrote:

> Yes but who can make a living from them? For each success claimed by a
> niche language, there will be hundreds written using mainstream languages
> and tools. If one wants to make a living from programming one must go to
> where the work is.

Who's holding a gun to your head and saying you must use Forth? The work is
where you find it. Obviously by definition there are magnitudes more people
using "mainstream" languages and tools. That doesn't mean the DSLs or
specifically Forth aren't good choices in their niche.

[rickman]

On 10/3/2012 2:06 PM, van...@vsta.org wrote:
>> Forth seems to be a good example of a marketing failure that isn't a
>> technical failure. It's a simple, flexible tool that just doesn't get any
>> respect!
>
> It's a powerful macro assembler for a stack based machine language.
> The problem is that it can take your $0.23 problem and do it for $0.17--
> a 25% savings! But everybody has pockets stuffed full of $20 bills,
> so nobody cares. I think Chuck Moore was smart to head towards where
> the pennies still matter.

And exactly where would that be?

Rick

[Albert van der Horst]

In article <742fcec0-5ec7-4eac...@googlegroups.com>,

Yesterday I helped Leon Konings out with installing a 35 euro Raspberry.
He has a high definition TV, cables laying around, an old wall wart
for a cell phone, an unused SMD card, an USB keyboard from an old Apple.
Bottom line he didn't have any extra costs for a linux computer with
a web browser (and a couple of Forths, even chforth, running in a DOS box.)

Groetjes Albert

--

[Elizabeth D. Rather]

In embedded devices that will be used in enormous volumes, such that
tiny savings in unit costs are multiplied by volume to the extent that
it's worth extra development costs to achieve them, and in applications
where good power management can vastly extend the usefulness (and value)
of a device.

[rickman]

On 10/4/2012 1:51 PM, Elizabeth D. Rather wrote:
> On 10/4/12 2:39 AM, rickman wrote:
>> On 10/3/2012 2:06 PM, van...@vsta.org wrote:
>>>> Forth seems to be a good example of a marketing failure that isn't a
>>>> technical failure. It's a simple, flexible tool that just doesn't get
>>>> any
>>>> respect!
>>>
>>> It's a powerful macro assembler for a stack based machine language.
>>> The problem is that it can take your $0.23 problem and do it for $0.17--
>>> a 25% savings! But everybody has pockets stuffed full of $20 bills,
>>> so nobody cares. I think Chuck Moore was smart to head towards where
>>> the pennies still matter.
>>
>> And exactly where would that be?
>
> In embedded devices that will be used in enormous volumes, such that
> tiny savings in unit costs are multiplied by volume to the extent that
> it's worth extra development costs to achieve them, and in applications
> where good power management can vastly extend the usefulness (and value)
> of a device.

I asked the question not because I don't understand the concept, but
because I don't see how a $15 CPU chip which requires some $10+ of
supporting chips is a viable contender in the "$0.23" arena. I realize
that number is just a rhetorical figure, but with the current selling
price of the GA144, I don't see it being suited to high volume markets
except perhaps an extremely small niche. I still am asking the question,

Exactly where would that be?

Rick

[Elizabeth D. Rather]

GA's price is high because their volumes right now are low. Every new
chip has this problem until they get enough design wins, unless the mfr
is so large they can subsidize the early market stages.

[Rod Pemberton]

"Fritz Wuehler" <fr...@spamexpire-201210.rodent.frell.theremailer.net> wrote
in message
news:923e0c628f2cd64d...@msgid.frell.theremailer.net...
> "Ed" <inv...@nospam.com> wrote:
...

> There are many niche tools and domain specific languages that

> are not popular [n]or widely known, yet they serve a purpose

> and are in active use.

Sigh ... Who cares?

If they're not popular nor widely known, they'll be extinct.

> Really, the statement you quoted is troubling not from a Forth point of
> view, but consider all the graphical crap and web programming that
> probably make up 99% of all code written today...if that junk isn't a
> solution looking for a problem I don't know what is. We got business
> done with text interfaces for many years and I don't see any benefit
> except for teenagers and H1Bs in reducing programming to flash
> webpages. Doesn't anybody write code that actually *does*
> something anymore?

"We got business done with text interfaces for many years ..."

Are you a retired COBOL programmer? It fits.

> In theory that seems reasonable. In practice there seems to be no limit to
> the number of programming languages in use and no end in sight when it
> comes to creating new ones.

Except, they all have C backends, or had them.

So, why bother with them? Why not learn C?


Rod Pemberton

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message

news:8596609.k...@sunwukong.fritz.box...
> Rod Pemberton wrote:
...

> And you even needed to correct your own spelling...

Once I'm aware a word is misspelled, I attempt to spell the word correctly
the next time and thereafter. I know I misspell when I haven't had
sufficient sleep. I know I have problems with certain words. I know I edit
and rewrite my posts and so end up with incorrect words or phrases
sometimes.

> Nobody else bothers here about the occasional mis-spelling.

Yours isn't occasional. For some words, it's permanent.

> Why do you do it? It contributes *nothing* to the discussion.

You responded to my post, but with an included insult. Why do you
insult people? "A typical RP argument ..." To use your words, "It

contributes *nothing* to the discussion."

Should I take it that you don't like valid criticism?

Should I take it that you don't like your faults exposed?

> However, I think you don't follow Postel's advice for communication: If
> you speak to someone else, try to understand, not try to misunderstand.

That's something you ignore in it's entirety.

The fact that you posted it to me is ironic.

> Words have a meaning only in context.

I agree. Can you please attempt to comprehend the context?

I ate a green apple in the morning, and I ate a green apple in the evening.
I salted the apple I ate in the evening. Which apple is the unripe red
apple? It could be either or neither or both, but it's more likely one is
green in color and the other is unripe. Salted or unsalted?

> It's just sometimes you don't understand me;
> and I don't think in these cases it is my fault.

Are you serious?

> >> It's another misunderstanding of you: You absolutely have to
> >> fill your fab. For memory makers, it's cut-throat; they have
> >> been dying like flies in the past years.
> >
> > What's wrong with making a smaller fab? It's one way to fill your
> > fab.
>
> It's less efficient, i.e. the price per die will be higher. They don't
> build bigger fabs for the fun of it, but because they want to be cheaper
> than the competition.

You're attempting to claim that the higher price per die over the operating
lifetime of a smaller fab will be substantially more than the upfront cost
of a much larger fab distributed on a per die basis? Doubtful.

> Furthermore, there aren't many companies who make
> equipment; for leading edge processes, you essentially have to buy from
> one company in the Netherlands (ASML); they have a sort-of (natural)
> monopoly on the most important component - the stepper. That however
> means that the equipment is designed for those who are willing to pay
> the price - and those are the big manufacturers who want big fabs.

Equipment manufacturers have to go where the money is too. If their
customers no longer want large equipment, they'll design smaller equipment.
They'll take custom orders too. They're designing very specialized
machines. If no one buys them, they're out of business.

> >> The semiconductor industry did something completely different:
> >> They separated making and designing.
> >
> > So did the automotive industry, circa the early 1990's. Many of them
> > moved design from Detroit to California, Italy, Taiwan, Korea, China,
> > etc.
>
> Stop saying "automotive industry" when you want to say "Detroit".

No, I don't mean Detroit. I mean the major automotive companies. At one
time, that meant the Detroit based Big-3. Today, I'd define it as General
Motors, Ford, Toyota, Daimler-Chrysler. Even Toyota designs in Michigan
and California.

> I applied Postel's principle, and I clearly figure out that you use the
> words "automotive industry" as synonym for "Detroit", and you ignore the
> rest of the world, which also has their automotive industries.

Clearly, it was a waste of your time to use "Postel's principle".

> Only Detroit destroyed itself by outsourcing everything to some other
> place. Furthermore, when you say something like "moved design to
> Italy", it sounds as if Italians haven't made cars before.

That's the way it sounds to you. That's not what was said.

> FIAT is 9 years older than GM (the old GM, the one founded in 1908
> which went bankrupt 100 years later).

The "new" GM is the "old" GM without the unused assets
and financial liabilities.

> You probably wouldn't say GM "moved design to Germany", because,
> yes, they do (Opel), but that would make you sound silly.

No, it would be inaccurate. AFAIK, nothing was moved there.

> >> This is very natural, as the semiconductor industry is a "printer"
> >> industry. The making is litography, i.e. printing.
> >
> > You mean lithography, not "litography". Specifically, it's
> > photolithography.
>
> See, you are doing it again. You perfectly understood me, but you think
> it's worth to show off that your English is better than mine. What's
> the point?

I just thought you misspelled it because you don't know how to spell it in
English, or you used a non-English spelling.

Just typing a few letters: "litog" into Google or Yahoo finds the correct
spelling. That takes you what, two seconds? Two seconds to not have
someone point it out. Is that worth it? Even simpler, enable your
spelling checker.

> It's supposed to pronounce "lit^{h}ography", but you
> probably pronounce it with a fricative "th" (as in modern greek and
> English, but this is supposed to be pronounced as ancient greek,
> where theta was a plosive).

In English, it's pronounced with a 'th':
http://www.merriam-webster.com/dictionary/lithography
http://dictionary.reference.com/browse/lithography?s=t
http://www.thefreedictionary.com/lithography

> >> There are some businesses in the printing industry where you need
> >> the press in-house (newspapers, e.g.), but usually, the design
> >> (the writing) is separated from the replication (the printing).
> >>
> >
> > There you go again with the "lump and dump" - conflating lithography
> > with photolithography.
>
> You apparently have an abstraction/analogies problem, you see the
> differences but miss the similarities. The essence of lithography and
> photolithography is that both make cheap replications possible -
> replications of drawings, of books, of integrated circuits, and that the
> replication process is independent of the creation process.

Mass production, injection molding, electronic component insertion, CAD/CAM,
lost foam casting, etc also make cheap replications possible. Do you intend
to classify all of them, and numerous other technologies and business
processes, as "'printer' industry" also?

> > Photolithography is too highly specialized to compare it to the
> > printing of book and newspapers. Basically, you're conflating a
> > simple process of placing ink on paper with a complex process
> > such as chemical etching and vapor deposition of elements, like
> > silicon, gallium, or arsenic, and also re-classifying the work
> > numerous Electrical Engineers as that of mere wordsmiths.
>
> Uh-oh. A writer or a painter who creates an *original*, which later
> is replicated by printing, is an artist, his profession is not to do the
> replication, but to create the original.

I should apologize to the artists for lumping them in with writers.

> As is the EE's task, who creates a circuit, which is then "printed"
> in the fab. Both professions require skills, quite different skills,

[...]

So?

> [...] but good writers are even rarer than good EEs.

Opinion. Many EEs come from degree "mills".

> The fab however is not doing EE. They are doing lithography and
> chemistry, their expertise is to control the process and keep the yield
> high - they essentially operate really, really high-tech printers. It's
> a well more advanced way of doing it than printing a newspaper, but the
> essence is doing many, many cheap replications.

True.

> > Do you know what a related-rate problem is?
>
> Yes. But this is completely irrelevant here.

Why? You seem to not understand that a process can operate at different
speeds and volumes.

> Actually not. They are mass produced. For a not that big amount of
> "mass", but they are definitely not built to order. Just look up
> asml.com, they have nice photos, where you also can look inside the
> machines.

Just because a machine is part of a company's product line doesn't mean it's
not custom. Highly specialized machines are custom.

> Well, the semiconductor industry buys standard off-the-shelf products.

That is true, but only to a certain extent. At some point, they need
equipment modified to their needs, or to fit the plant, etc.

> They have to buy and install new equipment every two years, so many
> chances to correct that mistake. I don't think they overbuilt.

...

> Let's look at the data: TSMC's 28nm fab has now 24k wafer starts per
> month (and that's actually rather small, this is still in learning and
> growing mode; GlobalFoundries combined 32/28nm fab has 50k wafer starts
> per month and wants to grow to 80k, because now they have the customers,
> not just AMD). ASML's twinscan XL, which is the appropriate stepper for
> that fab, has 150wph, or 108k per month. It takes around 40 masks to
> process a complete wafer (20 of them are metals and vias), so TSMC needs
> only 10 of these steppers, if they are 100% utilized.
>
> There isn't much room for less. Several process steps like the tungsten
> contacts (done with the Altus linked above) are only done once per wafer
> (contacts and local interconnects), and you want to utilize the entire
> fab 100%. The single Altus with its 120wph is good for more than 80k
> wafers per month. They won't sell that many of them; low two-digits, I
> guess. I hope this illustrates the problem: The machines are quite
> small and fast, but really, really expensive.
>

You say they want to utilize their entire fab. However, you cite examples
where they aren't, and you still claim they didn't overbuild. How does your
reasoning make sense to you? If they have any spare capacity for growth,
didn't they overbuild? Of course, they did. Any spare capacity indicates
they overbuilt. It's irrelevant that they intended for that capacity to be
used for growth. There is no guaranty they'll ever see any of the expected
growth. This is the same logic that caused the automotive industry to
design massive plants that eventually operated at only 30% of capacity for
decades.

"The expected growth didn't materialize."
"The market is in a downturn."
...

> > There is still a financial advantage to owning your own fab. They
> > can make them smaller or more efficient, if they want.
>
> It's a fairly trivial calculation: Suppose your external fab has a cost
> disadvantage of 30% per wafer - that's the profit they want to make.
> Because they fab for everybody, they can fill their big, big fab, and
> make it very efficient, by having 100% utilization for everything, and a
> good yield. If they succeed to be 30% more efficient than your small
> fab, the deal is done: Go fabless.

If they don't operate at or above a certain capacity levels, they're
operating at a loss until bankruptcy, or operating at break-even essentially
forever. If the capacity level is larger than break-even, they make a
profit.

The argument that semiconductor companies couldn't keep their fabs full,
i.e., lack of demand, was your prior argument for the industry selling their
fabs in the first place. Why do you expect outsourced fabs to be able to
fill their fab? Why do you expect that there is sufficient demand for that?

Consumed capacity is a function of supply and demand. There was
insufficient market demand in the first place to fill the fab for the fab's
original owner. So, they sold it. Why do you think there will be more than
enough demand for the fab's second owner if there wasn't for the first?


Rod Pemberton

[Bernd Paysan]

Rod Pemberton wrote:
>> It's just sometimes you don't understand me;
>> and I don't think in these cases it is my fault.
>
> Are you serious?

Yes, of course.

>> It's less efficient, i.e. the price per die will be higher. They
>> don't build bigger fabs for the fun of it, but because they want to
>> be cheaper than the competition.
>
> You're attempting to claim that the higher price per die over the
> operating lifetime of a smaller fab will be substantially more than
> the upfront cost
> of a much larger fab distributed on a per die basis? Doubtful.

I've been working in that industry and I'm trying to explain it to you,
but it is futile.

> Equipment manufacturers have to go where the money is too. If their
> customers no longer want large equipment, they'll design smaller
> equipment.
> They'll take custom orders too. They're designing very specialized
> machines. If no one buys them, they're out of business.

And that's why they make the big ones. The big semiconductor
manufacturer drive the others out of the market, because being big is an
advantage, they buy first, they buy most of the equipment. The most
cut-throat business there is memories, and there aren't many left.

>> Stop saying "automotive industry" when you want to say "Detroit".
>
> No, I don't mean Detroit. I mean the major automotive companies.
> At one
> time, that meant the Detroit based Big-3. Today, I'd define it as
> General
> Motors, Ford, Toyota, Daimler-Chrysler. Even Toyota designs in
> Michigan and California.

Daimler removed the Chrysler from its name several years ago. It's most
popular brand is by far Mercedes, not Chrysler. And Volkswagen is one
of the biggest automotive companies in the world, though it didn't buy
into Detroit. If Daimler wouldn't have bought Chrysler or Toyota
wouldn't have bought remainders of Detroit, you wouldn't even know about
them. m(

You don't mean "major automotive companies". You mean "Detroit". I
feel like Alice talking to Humpty Dumpty.

> Clearly, it was a waste of your time to use "Postel's principle".

Ok, I stop now, delete the rest and put you back on my killfile.
Unfortunately, it's by default a nice killfile and lets people pop up
again after some time. Just one more thing:

> The argument that semiconductor companies couldn't keep their fabs
> full, i.e., lack of demand, was your prior argument for the industry
> selling their fabs in the first place. Why do you expect outsourced
> fabs to be able to fill their fab? Why do you expect that there is
> sufficient demand for that?

I've already told you that, several times. Such a spinned off fab is
open for everyone. GlobalFoundry has several other design houses as
customers. GlobalFoundries is a consolidation of a fab (UMC) and a
processor maker (AMD), and together, they can fill this fab. This
consolidation means that there are now less fabs than before (at least
for the more advanced processes).

[rickman]

Ok, then let's talk about a $5 chip that uses $10 worth of support chips
to do anything meaningful. The fact remains that this is not an
inexpensive chip. I has some unique capabilities, but it also was
designed without a plan on how to use those capabilities and without a
market to sell into and without consideration of how it might be used in
a real world design.

I'm really not trying to bash it, I would still like to use it in a
design. But I can only think of one application area for it, a
multi-channel/multi-mode, hand held, software defined digital receiver.
Even then I'm not familiar enough with the market space to know how
usable it would be there.

What other apps are there for this device?

Rick

[van...@vsta.org]

rickman <gnu...@gmail.com> wrote:
> ... with the current selling

> price of the GA144, I don't see it being suited to high volume markets
> except perhaps an extremely small niche.

I'm certainly not arguing the case for the current chip. But the tiny dab of
silicon implied by their architecture would be almost in the noise for any
current production CPU chip; their technology is clearly compatible with low
cost and low power. The real question seems to be whether its new software
model can gain traction in any actual product.

[rickman]

On 10/4/2012 8:41 PM, van...@vsta.org wrote:
> rickman<gnu...@gmail.com> wrote:
>> ... with the current selling
>> price of the GA144, I don't see it being suited to high volume markets
>> except perhaps an extremely small niche.
>
> I'm certainly not arguing the case for the current chip. But the tiny dab of
> silicon implied by their architecture would be almost in the noise for any
> current production CPU chip; their technology is clearly compatible with low
> cost and low power. The real question seems to be whether its new software
> model can gain traction in any actual product.

If you think their chip is suitable for low cost applications, you have
not looked at what it takes to build a board using this device. There
are any number of MCUs and FPGAs available that have looked at the full
system which they would be used in and incorporated as many components
internally as possible. The GA144 seems to have been designed thinking
that the system should be adapted to making the GA144 as simple as
possible. As I said in my other posts, this part requires some $10 or
more of supporting components for a real design. Compare that to a MCU
under $4 that has nearly everything needed on one chip.

The irony is that it would be so easy to add capability that would make
this a much better device. I don't know why they don't think it is
useful or needed.

The software issues are on top of the hardware issues and don't really
help things much.

Rick

[Albert van der Horst]

In article <k4bcs9$cik$1...@speranza.aioe.org>,
Rod Pemberton <do_no...@notemailnotz.cmm> wrote:
>"gavino_himself" <visplo...@gmail.com> wrote in message
>news:742fcec0-5ec7-4eac...@googlegroups.com...

>> On Friday, September 28, 2012 7:16:25 AM UTC-7, B.Person wrote:
>> > Posted 16 hours ago. Time to get into the ARM world; IMHO.
>> >
>>

>> When $99 forth pc with a web browser? I will buy one.
>

>You can by any x86 computer or laptop with a 486DX2 or more recent processor
>that will execute a web browser. Some are likely less than $99 today. Why
>does it need to be a Forth computer or laptop for you to buy it?

A raspberry pi will serve as a tv setup box to browse the net.(35 euros).
It is not a Forth computer, but it will run gforth just fine.
(It even runs mina in a Dosbox, and even my "full screen" editor works
that patches characters at 0xB000 ).

>
>
>Rod Pemberton
>
>

Groetjes Albert

[van...@vsta.org]

rickman <gnu...@gmail.com> wrote:
> If you think their chip is suitable for low cost applications, you have
> not looked at what it takes to build a board using this device.

That isn't what I said. Let me quote my first sentence again:

>> I'm certainly not arguing the case for the current chip.

You continue:

> The irony is that it would be so easy to add capability that would make
> this a much better device. I don't know why they don't think it is
> useful or needed.

I understand that you're frustrated because what they have and what you want
are so far apart.

[gavino_himself]

I love truth!!

intel are bastards

viva amd

bernd when will your cpu be running a pc like machine and run firefox? for cheap? I will buy one!

[Alex Wegel]

gavino_himself <visplo...@gmail.com> wrote:

> When $99 forth pc with a web browser? I will buy one.

Sounds pretty much like the description of a used powermac ;-)

[Bernd Paysan]

gavino_himself wrote:
> bernd when will your cpu be running a pc like machine and run firefox?
> for cheap? I will buy one!

When you will understand the difference between a deeply embedded
microcontroller and a PC CPU, then you will be able to buy b16 for
cheap.

Either that or you will understand why it doesn't run Firefox.

[Rod Pemberton]

"Bernd Paysan" <bernd....@gmx.de> wrote in message

news:1874283.R...@sunwukong.fritz.box...
> Rod Pemberton wrote:
...

> >> It's less efficient, i.e. the price per die will be higher. They
> >> don't build bigger fabs for the fun of it, but because they want to
> >> be cheaper than the competition.
> >
> > You're attempting to claim that the higher price per die over the
> > operating lifetime of a smaller fab will be substantially more than
> > the upfront cost
> > of a much larger fab distributed on a per die basis? Doubtful.
>
> I've been working in that industry and I'm trying to explain it to you,
> but it is futile.

It's futile because you're going around and around in circles. You're not
accepting the truth as such. You state one thing with an illogical
conclusion. I bring up the illogical conclusion. You state another with an
illogical conclusion. Eventually, you restate the your original premise.
I.e., circle. You seem to think that repeating circle makes it true.

> > Equipment manufacturers have to go where the money is too. If their
> > customers no longer want large equipment, they'll design smaller
> > equipment. They'll take custom orders too. They're designing very
> > specialized machines. If no one buys them, they're out of business.
>
> And that's why they make the big ones. The big semiconductor
> manufacturer drive the others out of the market, because being big is an
> advantage, they buy first, they buy most of the equipment. The most
> cut-throat business there is memories, and there aren't many left.

This makes no sense. I know you don't understand why. The key word is
"today". What you said is true only when semiconductor factories build
their own fabs. That's not the market of "today". As you've noted, they've
all sold their fabs. I.e., there are no big semiconductor manufacturers
buying equipment for fabs. It's only new fabs buying equipment. If the new
fabs choose to buy small, then the equipment manufacturers have to follow
the market.

> >> Stop saying "automotive industry" when you want to say "Detroit".
> >
> > No, I don't mean Detroit. I mean the major automotive companies.
> > At one time, that meant the Detroit based Big-3. Today, I'd define it
> > as General Motors, Ford, Toyota, Daimler-Chrysler. Even Toyota designs
> > in Michigan and California.
>
> Daimler removed the Chrysler from its name several years ago.

True, but I figured you wouldn't know who I was talking about.

> It's most
> popular brand is by far Mercedes, not Chrysler. And Volkswagen is one
> of the biggest automotive companies in the world, though it didn't buy
> into Detroit. If Daimler wouldn't have bought Chrysler or Toyota
> wouldn't have bought remainders of Detroit, you wouldn't even know
> about them. m(
>

I know about many of them. I very likely even know of companies
you've probably never heard of.

> You don't mean "major automotive companies". You mean "Detroit". I
> feel like Alice talking to Humpty Dumpty.

No, I didn't. It's still not Big-3. Toyota replacing one of the Detroit
three, doesn't change the validity of what I said.

> > The argument that semiconductor companies couldn't keep their fabs
> > full, i.e., lack of demand, was your prior argument for the industry
> > selling their fabs in the first place. Why do you expect outsourced
> > fabs to be able to fill their fab? Why do you expect that there is
> > sufficient demand for that?
>
> I've already told you that, several times.

You still don't comprehend that your description violates
economics, history, and logic.

> Such a spinned off fab is
> open for everyone. GlobalFoundry has several other design houses as
> customers. GlobalFoundries is a consolidation of a fab (UMC) and a
> processor maker (AMD), and together, they can fill this fab. This
> consolidation means that there are now less fabs than before (at least
> for the more advanced processes).
>

Selling off a fab doesn't change market demand. As you noted, the original
fab owner could've opened their fab to outsiders, and as you noted, some
did. Yet, the original fab owners still sold because of lack of demand.
So, where's the extra demand? Did it just appear out of nowhere?


Rod Pemberton

[rickman]

On 10/5/2012 5:14 PM, van...@vsta.org wrote:
> rickman<gnu...@gmail.com> wrote:
>> If you think their chip is suitable for low cost applications, you have
>> not looked at what it takes to build a board using this device.
>
> That isn't what I said. Let me quote my first sentence again:
>
>>> I'm certainly not arguing the case for the current chip.
>
> You continue:
>
>> The irony is that it would be so easy to add capability that would make
>> this a much better device. I don't know why they don't think it is
>> useful or needed.
>
> I understand that you're frustrated because what they have and what you want
> are so far apart.

I am frustrated because they don't want to support my method of working
with their chip which is to understand the timing to the same level of
detail that is supported with FPGAs.

As to my reply to your post, I am responding to the statement, "their
technology is clearly compatible with low cost and low power". The die
size only determines the cost of their silicon. This is not the same as
their total product cost and is not at all related to the cost of using
the device in a product.

Like I said before, there may be some areas where the chip is useful and
competitive. But the general, low cost application area is not where
this chip can compete. It is not low cost unless you are comparing it
to the higher end devices which it otherwise does not compete against.
In other words, it is not a "system" device. It is a processing unit
which requires much supporting circuitry. That does not result in a low
cost design.

As to the claim of low power, I can't say how well this device can
compete on power. The only power the matters is the system power of the
end design. Until we seem some system designs we won't know if the
GA144 will result in a low power system.

I may return to exploring the oscilloscope design. Some potential work
fell through and I still have time on my hands.

Rick

[Mark Wills]

On Sep 28, 3:16 pm, "B.Person" <bruce.per...@gmail.com> wrote:
> Posted 16 hours ago.  Time to get into the ARM world; IMHO.
>

> http://arstechnica.com/information-technology/2012/09/99-raspberry-pi...

More on this. An article on The Register today:

"The Epiphany core has a mere 35 instructions – yup, that is RISC
alright – and the current Epiphany-IV has a dual-issue core with 64
registers and delivers 50 gigaflops per watt. It has one arithmetic
logic unit (ALU) and one floating point unit and a 32KB static RAM on
the other side of those registers."

"Each core also has a router that has four ports that can be extended
out to a 64x64 array of cores for a total of 4,096 cores. The
currently shipping Epiphany-III chip is implemented in 65 nanometer
processors and sports 16 cores, and the Epiphany-IV is implemented in
28 nanometer processes and offers 64 cores."

"The secret sauce in the Epiphany design is the memory architecture,
which allows any core to access the SRAM of any other core on the die.
This SRAM is mapped as a single address space across the cores,
greatly simplifying memory management. Each core has a direct memory
access (DMA) unit that can prefetch data from external flash memory."

Oh. That is seriously nice.

See here: http://www.theregister.co.uk/2012/10/07/adapteva_epiphany_parallel_computing_kickstarter/

[Chris Hinsley]

On 2012-10-08 08:38:34 +0000, Mark Wills said:

> "The secret sauce in the Epiphany design is the memory architecture,
> which allows any core to access the SRAM of any other core on the die.
> This SRAM is mapped as a single address space across the cores,
> greatly simplifying memory management. Each core has a direct memory
> access (DMA) unit that can prefetch data from external flash memory."
>
> Oh. That is seriously nice.
>
> See here:
> http://www.theregister.co.uk/2012/10/07/adapteva_epiphany_parallel_computing_kickstarter/
>

The hardware and SDK refernce manuals are avaiable for download now
BTW. Check the kickstarter announcement, it has the links to download.

Wish it had a bit more local memory, but yep, it looks quite nice.

Chris

[Chris Hinsley]

Actually the memory architecture is very nice, you can even run
instructions from the memory of external cores. Esentially the memory
address top 6 bits are an core (x,y) address, the lower bits the dram
address. The scoreboarding of registers in the dependancy logic can
cope fine with instructions and register reads/writes from/to external
core addresses. Each hop of a core adds 1 cycle to the stall if you try
to use a register prior to the data being available. You can think of
the mesh network as 3 seperate 2D token rings, a core can fill in an
empty slot as it goes by etc (arbitration logic round robbins the slots
between CPU, DMA and the neibouring cores).

2 DMA channels per core that can read/write 2D memory regions, plus
chained DMA descriptors so you can do nice Amiga style DMA blit lists
etc. Plus I belive the DMA can do remote read/writes, so you can get a
cores DMA engine to do transfers from a remote core to another remote
core…

The 32KB SRAM is organised as 4 8KB banks, each can be accsessed every
cycle by various bits of the hardware, instruction read, DMA, etc etc.
You need to keep instructions, data in, data out, buffers in seperate
banks to hit maximum speed.

Probably best for compute kernels ATM till more local memory is
available, but there is room in the memory map for more per core !
Bring on the version with 64 cores and 1MB SRAM per core and things
will get very interesting !

Chris

[rickman]

On 10/8/2012 3:43 PM, Chris Hinsley wrote:
>
> Wish it had a bit more local memory, but yep, it looks quite nice.
>
> Chris
>

WTF?!!! This thing has more memory on each processor than the GA144 has
in total!

Rick

[Chris Hinsley]

:)

Well I do like the idea of having a system like 64 super T800 trams on
a single chip… call me old fationed but I liked the 1MB tram cards...

Chris

[rickman]

I don't remember the name of the company, but someone was supposed to be
working on a combined processor/memory which was more like a memory chip
with an embedded processor than a processor with memory. Once they do
that, there is no reason why it couldn't be an array of processors.

Personally I never quite got the hang of Transputers. I did work with
them for a while though. Not sure if the system ever got built. It was
for a spook agency. Massively parallel. The software people felt the
need to implement a full blown networking scheme on the links. I'm not
sure how well that worked.

Rick

[Chris Hinsley]

Loved Transputers, the more the better. Very simple to wire up and use.
Taos ran very well on them, was nice having a PC with 30 T800s in my
bedroom to play with ! Ah, thoses we're the days… didn't need extra
heating in that room on chilly nights… :)

Chris

[Mark Wills]

> Chris- Hide quoted text -
>
> - Show quoted text -

Taos... Sigh... Loved that OS...

[Albert van der Horst]

In article <2012100821052179545-chrishinsley@gmailcom>,

In my twin prime counting (100+ transputers) I discovered that those
with 8 Mbyte did about 8 times the work of those with 1 Mbyte...

>
>Chris
>

Groetjes Albert

[Ed]

Anonymous wrote:
> "Ed" <inv...@nospam.com> wrote:
>
> > Yes but who can make a living from them? For each success claimed by a
> > niche language, there will be hundreds written using mainstream languages
> > and tools. If one wants to make a living from programming one must go to
> > where the work is.
>
> Who's holding a gun to your head and saying you must use Forth?

Those who claim only Forth can get the most out of your product :)

> The work is
> where you find it. Obviously by definition there are magnitudes more people
> using "mainstream" languages and tools. That doesn't mean the DSLs or
> specifically Forth aren't good choices in their niche.

Employers generally allow one choice - "take it or leave it"

[Bernd Paysan]

Ed wrote:
> Employers generally allow one choice - "take it or leave it"

I haven't encountered such an employer yet. Even the ones I chose to
leave allowed me to use Forth.

[Chris Hinsley]

Thank you. Glad it touched a few people. :) It was great fun doing
Taos. You'll have me blubbing about the old days in a while...

I did post a few press article scans up publicly on Wikipedia under the
Virtual_Processor page.

http://en.wikipedia.org/wiki/Virtual_Processor

Chris

[Chris Hinsley]

My budget didn't extend to 8MB Trams. :(

Chris

[rickman]

On 10/9/2012 10:42 AM, Bernd Paysan wrote:
> Ed wrote:
>> Employers generally allow one choice - "take it or leave it"
>
> I haven't encountered such an employer yet. Even the ones I chose to
> leave allowed me to use Forth.

I have yet to find an employer who is ok with using Forth. Typically
they have a modus operandi and aren't interested in exploring new
ground. They especially fear dealing with a unique language that the
bulk of the staff knows nothing about.

This may or may not be justifiable, but it is there. In 35+ years
working as an engineer, I have never once been able to use a commercial
Forth in my work. It is only since I've been working for myself I've
been able to justify using Win32Forth for text fixtures.

I did come close to using MPE forth in a project this fall, but the job
didn't land. The company decided they didn't have the resources to
proceed with the product.

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> I haven't encountered such an employer yet. Even the ones I chose to
>> leave allowed me to use Forth.
> I have yet to find an employer who is ok with using Forth.

We're shaking out a new piece of hardware where I work. If the hardware
guys happened to be Forthers and wanted to use Forth as a benchtop
debugging tool to poke at registers during development, it would
probably be fine. There's no way the software guys (e.g. me) would ever
be allowed to put Forth into the actual end product.

Outside of small embedded devices that have no long-term code base
(develop, test, finished--hopefully no updates ever), since programmers
come and go, any code inside a product has to expect to be maintained by
more than one person. That means a decision to let one person use Forth
is also a decision to require other people to maintain that Forth, which
in turn creates the need to find or train more Forthers. Avoiding that
headache is a perfectly sound decision unless you're already running a
Forth shop (there are of course a few of these that are doing ok).

It's less a matter of imposing conditions on the would-be Forth user,
than avoiding imposing on the non-Forth-users who are going to have to
deal with the code later.

[Elizabeth D. Rather]

A considerable number of our clients have been using Forth for years,
some for decades. They report that it's relatively easy to teach a
capable programmer who understands the application domain Forth. Far
easier, in fact, than training a Forth programmer who doesn't
understanding the engineering and other application domain issues!

Most of these companies do in-house training by giving the programmer
some books (e.g. Forth Application Techniques) plus documentation on the
existing code base and providing some mentoring. In a few cases, when
they have a number of new hires or new people assigned to the project,
they bring in an instructor such as me for a formal course.

A typical way in which Forth gets in to such a shop goes like this: an
engineer starts work on a new widget (remember, FORTH, Inc. is mainly
working in embedded systems). He has used Forth in a previous company.
He writes the initial code for the widget in Forth, and gets it working
much quicker (or more efficiently, or whatever) than the tools other
folks in the shop have used. So, management is impressed and lets the
other engineers learn Forth, take a course, or whatever.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[rickman]

On 10/9/2012 2:43 PM, Paul Rubin wrote:
> rickman<gnu...@gmail.com> writes:
>>> I haven't encountered such an employer yet. Even the ones I chose to
>>> leave allowed me to use Forth.
>> I have yet to find an employer who is ok with using Forth.
>
> We're shaking out a new piece of hardware where I work. If the hardware
> guys happened to be Forthers and wanted to use Forth as a benchtop
> debugging tool to poke at registers during development, it would
> probably be fine. There's no way the software guys (e.g. me) would ever
> be allowed to put Forth into the actual end product.

The last time I tried to use Forth at work was exactly that, to test
hardware designs (since I'm a hardware person). I got it into the
initial budget, but when it came time to spend it, the program manager
refused. You can make all the arguments in the world, but the PMs
consider it to be their money. I got to pound sand.

> Outside of small embedded devices that have no long-term code base
> (develop, test, finished--hopefully no updates ever), since programmers
> come and go, any code inside a product has to expect to be maintained by
> more than one person. That means a decision to let one person use Forth
> is also a decision to require other people to maintain that Forth, which
> in turn creates the need to find or train more Forthers. Avoiding that
> headache is a perfectly sound decision unless you're already running a
> Forth shop (there are of course a few of these that are doing ok).
>
> It's less a matter of imposing conditions on the would-be Forth user,
> than avoiding imposing on the non-Forth-users who are going to have to
> deal with the code later.

Trust me, I understand all of this completely. Heck, I've worked places
before where I couldn't even talk anyone into letting me have newsgroup
access. That was when I started using Google Groups, when it was clean
and simple even if it had all sorts of other problems.

The problem is that Forth is not mainstream and that means managers
don't want to hear about it. I can make all the productivity arguments
I want and they won't cut loose the money.

Rick

[rickman]

How does the engineer get the code working when money has to be spent on
a commercial Forth package? If I didn't need to spend money, I would
have had Forth on my lab bench many times over.

That's not the problem now, I work for myself. Now I just need work
where I do programming. Most of my work is hardware design and I'm
happy with the open source Forths for test from a PC. I may be using
the WikiReader in the future.

Rick

[Bernd Paysan]

Paul Rubin wrote:
> Outside of small embedded devices that have no long-term code base
> (develop, test, finished--hopefully no updates ever), since
> programmers come and go, any code inside a product has to expect to be
> maintained by
> more than one person. That means a decision to let one person use
> Forth is also a decision to require other people to maintain that
> Forth, which
> in turn creates the need to find or train more Forthers. Avoiding
> that headache is a perfectly sound decision unless you're already
> running a Forth shop (there are of course a few of these that are
> doing ok).

IMHO this is nonsense. The last company I left (because they weren't
actually innovative and had many "replacement" concerns, and led slip
some "We don't know what we can do with you in the long run" pretty
early) needed a replacement for me quickly, when I left. The engineer
that had to take over my work didn't take that long to learn b16 Forth -
he managed to ask all his questions before I actually left. Well, it's
only a small subset of Forth, but it still *is* Forth.

If you assume that your programmers can't learn another language
quickly, you should question that assumption. In the job I had at that
company, I was confronted with Verilog (as part of the digital design),
Lua (a measurement equipment used that as embedded language), Tcl (as
scripting language in most Cadence products), Skill (scripting language
in the integrated analog/mixed signal design system from Cadence),
LabView, and maybe some I forgot. If you can only do one language, you
can do nothing. One part of the project - a GUI to operate the
prototype, was done by the intern, who had one week to a) learn Forth,
and b) complete the task. He had some similar LabView experience (for
which he had two months), and concluded that Forth+MINOS was much easier
to use than LabView.

My boss told me I rather should have written the program in C so that he
could understand it. My boss didn't have any software coding
experience, he didn't even understand the textual description of the
algorithm, any formula was "too confusing" and all the diagrams as well.
This was a 500 lines program... What he wanted was an employee that
didn't challenge his position. Some elbonian pigs might barely qualify
for *that part* of the job description, though he was bald, fat, and
could only grunt.

[Elizabeth D. Rather]

On 10/9/12 9:34 AM, rickman wrote:
> On 10/9/2012 3:02 PM, Elizabeth D. Rather wrote:

...

>> A typical way in which Forth gets in to such a shop goes like this: an
>> engineer starts work on a new widget (remember, FORTH, Inc. is mainly
>> working in embedded systems). He has used Forth in a previous company.
>> He writes the initial code for the widget in Forth, and gets it working
>> much quicker (or more efficiently, or whatever) than the tools other
>> folks in the shop have used. So, management is impressed and lets the
>> other engineers learn Forth, take a course, or whatever.
>>
>> Cheers,
>> Elizabeth
>
> How does the engineer get the code working when money has to be spent on
> a commercial Forth package? If I didn't need to spend money, I would
> have had Forth on my lab bench many times over.
>
> That's not the problem now, I work for myself. Now I just need work
> where I do programming. Most of my work is hardware design and I'm
> happy with the open source Forths for test from a PC. I may be using
> the WikiReader in the future.

Either by using an evaluation version of the product as a proof of
concept, or simply by requesting it. Most companies are accustomed to
purchasing development software, and the commercial Forths aren't
significantly more expensive (often less) than comparable products.

An engineer with prior experience with Forth can assert that a
demonstrable prototype can be developed faster/smaller/whatever than
with the tools currently in use, and then demonstrate it. The margin of
difference is usually so large that management has no problem approving
a purchase once the claim is validated.

[rickman]

We had this conversation some time back when I was trying to "assert"
the advantages of Forth where I worked. I can "assert" all day long,
but it doesn't get believed by hardware managers (or anyone in the
software domain). I also noticed that you used the qualifier, and
engineer "with prior experience". That would leave me out wouldn't it?

How much functionality is in the eval copies of Forth Inc embedded
Forths? Would I be able to develop a product with it? I haven't dug
into that lately, but I don't recall that it was practical to do any
development work with the eval version.

As to cost, Forth may be similar in cost to other code development
tools, but in this context it is a superfluous expense since the other
tools already exist in the company. At least that is how managers view it.

Rick

[marko]

So much of this is due to using modern vlsi tools?

Sure the Forth based okcad got the GA144 chip into production at low cost
making it possible. But I wonder if this would have been the result in a
conventional design and layout operation.

[rickman]

I shouldn't speak for the chip designers, but from what they have
written, they could ONLY design this chip using their own tools. They
even talk about how SPICE is broken and should not be used for anything
because it did not accurately model their designs.

The size of the memory is not a result of any limitation of tools or
anything else. They picked 64 words of RAM as the optimum size for
their system design.

Go figure.

Rick

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
>> If the hardware guys happened to be Forthers and wanted to use Forth
>> as a benchtop debugging tool to poke at registers during development,

>> it would probably be fine. ...

> The last time I tried to use Forth at work was exactly that, to test
> hardware designs (since I'm a hardware person). I got it into the
> initial budget, but when it came time to spend it, the program manager
> refused.

Maybe I should have said explicitly: I couldn't imagine my management
approving spending even 1 cent for purchasing Forth software. I just
meant they probably wouldn't have interfered if the hardware guys had
downloaded a free Forth from someplace and used it in the lab for
one-off debugging.

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> The engineer that had to take over my work didn't take that long to

> learn b16 Forth ... Well, it's only a small subset of Forth, but it
> still *is* Forth.

I'd consider it to be a slightly weird machine language, like the F18's.
As such, someone who's programmed other devices in assembler can
probably deal with it, by treating the Forth as assembly code. Of
course there's a big productivity hit compared to writing in a HLL.

> If you assume that your programmers can't learn another language
> quickly, you should question that assumption.

It's not just languages but the body of tools and techniques that the
languages come with. Assembly language is conceptually very simple, but
writing big assembly programs without creating a nest of bugs requires
careful technique that takes a while to develop. It's much easier with
HLL's.

> In the job I had at that company, I was confronted with Verilog (as
> part of the digital design), Lua (a measurement equipment used that as
> embedded language), Tcl (as scripting language in most Cadence
> products), Skill (scripting language in the integrated analog/mixed
> signal design system from Cadence), LabView, and maybe some I forgot.

Tcl is pretty trivial and Lua is straightforward to someone who's
Lisp/Python/Javascript/etc. I don't know about Skill or Labview. I've
been interested in Verilog for a while, and maybe I'm overestimating its
difficulty or maybe I'm just not all that bright, but I currently think
of learning it (to the point of being able to implement nontrivial
circuits that aren't full of bugs or bad performance mistakes) to be a
fairly major undertaking. Forth as a HLL is something like that too,
from what I can tell.

> My boss told me I rather should have written the program in C ...

> This was a 500 lines program...

C is itself a clunky legacy language, still useful for some things, but
often not really what you're competing against. If you're writing a GUI
to externally control some lab gizmo, you should compare the effort of
writing your 500 lines of Forth to implementing in (e.g.) Python, or as
a HTML web app running on a PC.

[Bernd Paysan]

rickman wrote:
> I shouldn't speak for the chip designers, but from what they have
> written, they could ONLY design this chip using their own tools. They
> even talk about how SPICE is broken and should not be used for
> anything because it did not accurately model their designs.

Yes, I've heard that, too. I've done simulations with the same process
(180nm TSMC logic process), and Spice/Spectre was perfectly right and
accurate. TSMC's models have a rather good reputation, most of the time
accurate to the point (though some model parameters like resistor tempco
are only available under typical conditions). I don't know what Chuck
did wrong, but I think he did something wrong. I had tutored a few
beginners, and you can indeed make quite a number of mistakes with these
tools.

Chuck doesn't like these complex and horribly expensive tools, but if
you negotiate, these tools are far less expensive than wasting years
with full-custom hand-layout, they do get a lot of work done for you.
As this is mostly a digital chip, I wouldn't even consider using Spice,
the digital models are accurate enough. Chucks horror storries about
conventional tools go pretty far back in time, at least back to ShBoom.
That's more than 20 years. Yes, the tools were really bad back then.

The tools have gotten better over time. I had been pretty annoyed by
the tools nearly 15 years ago, when I started. They often didn't do
what I wanted them to do, or at least were suboptimal. But they
improved. For small designs, they are almost perfect now. A coworker
asked me about a particular Verilog construct in the b16 ALU, and I
explained him how I build an ALU out of a full adder and two multiplexer
per bit. He said "the synthesis tool is never going to do that for
you", and I checked: It did. Both the current synthesis tool from
Cadence and Synopsys did what I wanted them to do.

[Bernd Paysan]

rickman wrote:
> How does the engineer get the code working when money has to be spent
> on a commercial Forth package? If I didn't need to spend money, I
> would have had Forth on my lab bench many times over.

There are two reasons to use a commercial Forth over a free one:

* You want to produce a binary for customers and not hand it out in a
GPL compatible way

* You need support, which is typically the business model of Forth
vendors, and support for a free system highly depends on how nicely you
ask the developers.

If you are just doing lab tests (which are "inhouse use", and therefore
don't result in any problems with the GPL), and you feel comfortable
enough with the system so that you don't need much support, there's no
reason not to go with a free Forth like Gforth.

The people in our Forth group in Munich had no problem to use Forth in
quite a number of locations. Even free Forth systems. One time, they
ported Gforth to a smart card at G&D, a highly secretive and paranoid
company, and they even were allowed to take their modifications to
Gforth out (as required by the GPL)! That never happened at G&D before
or after - but sometimes, even these things are possible.

Ob-Gavino: What they implemented on the smard card was a tiny web
server, including SSL, as secure way to access a smard card from a
browser. G&D decided to implement that in Java for a commercial product
instead, but for years they had nothing to show but the Forth demo, and
finally, they stopped the Java project. Java is fine on a big machine,
but on a small smartcard, it's not possible to do a web server in Java.
It is possible in Forth.

[Bernd Paysan]

Paul Rubin wrote:

> Bernd Paysan <bernd....@gmx.de> writes:
>> The engineer that had to take over my work didn't take that long to
>> learn b16 Forth ... Well, it's only a small subset of Forth, but it
>> still *is* Forth.
>
> I'd consider it to be a slightly weird machine language, like the
> F18's. As such, someone who's programmed other devices in assembler
> can
> probably deal with it, by treating the Forth as assembly code. Of
> course there's a big productivity hit compared to writing in a HLL.

I've had other cowoerkers who went through learning b16 Forth earlier,
i.e. where I could get feedback. They went through that "Forth is an
assembler" stage, but after they got a bit more fluent in Forth, they
didn't see it as such anymore. It may not feel as comfortable as Python
or something like that to them, but it is way beyond the typical weird
assembler language (think e.g. of 8051) you see in these small embedded
processors.

Most of these tasks can only be done reasonably in assembly language,
because these deep embedded stuff is done in >9 digits units, and
whatever pain it takes the programmer to make the program fit into 1mm²
less memory is absolutely worth it.

I've written a demo program for Forth Gesellschaft's pick&place robot in
about a week for the last LinuxTag. It included some tricky
trigonometic. Apart from the fact that b16 can't do an acos() function
(so use a table), it wasn't particularly tricky. We showed the program
to various bypassers on our booth, and one considered the code as
"fairly readable" - not the mostly trivial higher level parts, but even
the trigonometry stuff in the middle of the program.

>> If you assume that your programmers can't learn another language
>> quickly, you should question that assumption.
>
> It's not just languages but the body of tools and techniques that the
> languages come with. Assembly language is conceptually very simple,
> but writing big assembly programs without creating a nest of bugs
> requires
> careful technique that takes a while to develop. It's much easier
> with HLL's.

You don't write big programs, there is no space for big programs on a
small embedded processor. You write small programs. It's impossible to
write small programs in HLLs (including their run-time).

> Tcl is pretty trivial and Lua is straightforward to someone who's
> Lisp/Python/Javascript/etc. I don't know about Skill or Labview.

Labview is painting programs with little icons and arrows, similar to
Matlab/Simulink (another language you often see in these environments).
Skill is another Lisp-like language.

> I've been interested in Verilog for a while, and maybe I'm
> overestimating its difficulty or maybe I'm just not all that bright,
> but I currently think of learning it (to the point of being able to
> implement nontrivial circuits that aren't full of bugs or bad
> performance mistakes) to be a
> fairly major undertaking. Forth as a HLL is something like that too,
> from what I can tell.

You probably have to unlearn a lot. Too much particular knowledge is in
the way when you do Forth. Don't try to be clever. The unfactored Doug
Hoffman FizzBuzzZoom is a good example.

>> My boss told me I rather should have written the program in C ...
>> This was a 500 lines program...
>
> C is itself a clunky legacy language, still useful for some things,
> but
> often not really what you're competing against. If you're writing a
> GUI to externally control some lab gizmo, you should compare the
> effort of writing your 500 lines of Forth to implementing in (e.g.)
> Python, or as a HTML web app running on a PC.

The 500 lines were the Forth program on the deeply embedded b16. Some
parts of the management were considering buying an ARM core and use C on
that, though we had evaluated that comparison earlier, and the ARM core
simply was way too expensive both in terms of die size and license
costs. The thinking is about "when we buy an ARM core, our costs for
the chip increase by several million dollars, but we don't have to be
nice to an expensive expert, but can be mean to a cheap programmer".
That's definitely worth it ;-).

The MINOS GUI could probably compared to a Python implementation using
Qt as library, but a web app would be completely impossible (talk
through an FTDI USB device in SPI mode with a web app?).

The company bought me (including team), because they had no internal
knowledge about battery monitoring, and I found out why (they don't want
people with knowledge, because these threaten the position of the
bosses, who have no knowledge at all, including no knowledge in
management).

This was about the most dilbertesque and grotesque employer I had, but
they did still allow me to use Forth, even though they apparently were
scared by me for whatever I did. Even taking a direct international
flight was considered offensive (the typical plan was to have a stop-
over in London, which is IMHO completely crazy).

[rickman]

On 10/9/2012 7:11 PM, Bernd Paysan wrote:
> For small designs, they are almost perfect now. A coworker
> asked me about a particular Verilog construct in the b16 ALU, and I
> explained him how I build an ALU out of a full adder and two multiplexer
> per bit. He said "the synthesis tool is never going to do that for
> you", and I checked: It did. Both the current synthesis tool from
> Cadence and Synopsys did what I wanted them to do.

What was the construct he said you couldn't get from synthesis, a mux on
each input bit? Why would that be hard to synthesize? Also, what did
this buy you?

In my CPU design I wanted the address sequencer to be as fast as
possible and I found I could use the incrementer/adder as a mux as well.
So that logic all fit in one 4-input LUT. I think I had the
instruction fetch loop down to the decode logic plus two levels of LUTs
and the memory setup and hold time. Turned out it was the stack address
units that slowed the design the most, the error flags actually. Good
reason to toss the flags I suppose.

Rick

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> You don't write big programs, there is no space for big programs on a
> small embedded processor. You write small programs. It's impossible to
> write small programs in HLLs (including their run-time).

Fair enough. On such small processors, the advantages of HLL's are less
pronounced anyway.

> The 500 lines were the Forth program on the deeply embedded b16.

Oh I see.

> The MINOS GUI could probably compared to a Python implementation using
> Qt as library, but a web app would be completely impossible (talk
> through an FTDI USB device in SPI mode with a web app?).

Sure--by web app I just mean a PC program speaking HTTP to a socket, not
something running on a hosted server or anything like that. It would
have the same USB stuff as the Qt program. The Python stdlib has an
embeddable web server module, or you could write the program as a CGI
behind a separate server. Using either of these is less work than
programming Qt if you don't mind the limitations of a web gui, and has
the advantages that multiple people can use it from their desks using
browsers. I do this all the time for my own stuff where I just want
simple functionality and don't care about it looking slick.

> This was about the most dilbertesque and grotesque employer I had,

Condolences--there is a lot of that anywhere you go.

[Elizabeth D. Rather]

On 10/9/12 10:06 AM, rickman wrote:
> On 10/9/2012 3:53 PM, Elizabeth D. Rather wrote:
>> On 10/9/12 9:34 AM, rickman wrote:

...

>>> How does the engineer get the code working when money has to be spent on
>>> a commercial Forth package? If I didn't need to spend money, I would
>>> have had Forth on my lab bench many times over.
>>>
>>> That's not the problem now, I work for myself. Now I just need work
>>> where I do programming. Most of my work is hardware design and I'm
>>> happy with the open source Forths for test from a PC. I may be using
>>> the WikiReader in the future.
>>
>> Either by using an evaluation version of the product as a proof of
>> concept, or simply by requesting it. Most companies are accustomed to
>> purchasing development software, and the commercial Forths aren't
>> significantly more expensive (often less) than comparable products.
>>
>> An engineer with prior experience with Forth can assert that a
>> demonstrable prototype can be developed faster/smaller/whatever than
>> with the tools currently in use, and then demonstrate it. The margin of
>> difference is usually so large that management has no problem approving
>> a purchase once the claim is validated.
>>
>> Cheers,
>> Elizabeth
>
> We had this conversation some time back when I was trying to "assert"
> the advantages of Forth where I worked. I can "assert" all day long,
> but it doesn't get believed by hardware managers (or anyone in the
> software domain). I also noticed that you used the qualifier, and
> engineer "with prior experience". That would leave me out wouldn't it?

The advantage of the prior experience is that the "assertion" carries a
lot more weight since it will reference actual projects and experience
of this particular individual. Plus, it removes the issue of learning
curve, which scares a lot of managers.

The two most common paths by which FORTH, Inc. has gotten Forth into
other companies are:

1. Migration of a previous user into a new company (as above), and

2. A new project, wherein FORTH, Inc. bids the job in weeks instead of
the months that competitors using other languages are quoting. Once
we've done the project, they're convinced and want to train their own staff.

Without actual project experience, you'd be at a disadvantage
politically, though less so in practice.

> How much functionality is in the eval copies of Forth Inc embedded
> Forths? Would I be able to develop a product with it? I haven't dug
> into that lately, but I don't recall that it was practical to do any
> development work with the eval version.

Target programs are limited in size. Functionality is at the level of
the "pro" version (all capabilities). All source is provided for the
target kernel and library functions, along with at least one complete
example program. Try one!

> As to cost, Forth may be similar in cost to other code development
> tools, but in this context it is a superfluous expense since the other
> tools already exist in the company. At least that is how managers view it.

So, the next opportunity would be when you're addressing a new target
for which you don't have a compiler :-)

[Bernd Paysan]

rickman wrote:

> On 10/9/2012 7:11 PM, Bernd Paysan wrote:
>> For small designs, they are almost perfect now. A coworker
>> asked me about a particular Verilog construct in the b16 ALU, and I
>> explained him how I build an ALU out of a full adder and two
>> multiplexer
>> per bit. He said "the synthesis tool is never going to do that for
>> you", and I checked: It did. Both the current synthesis tool from
>> Cadence and Synopsys did what I wanted them to do.
>
> What was the construct he said you couldn't get from synthesis, a mux
> on each input bit? Why would that be hard to synthesize? Also, what
> did this buy you?

I think he was more sceptical about the full adder. This is very
compact and buys space. The guy also argued that space isn't an issue
at all at 180nm, and therefore could be wasted, and my reply was "that's
why your part is huge and mine is small".

> In my CPU design I wanted the address sequencer to be as fast as
> possible and I found I could use the incrementer/adder as a mux as
> well.
> So that logic all fit in one 4-input LUT. I think I had the
> instruction fetch loop down to the decode logic plus two levels of
> LUTs
> and the memory setup and hold time. Turned out it was the stack
> address
> units that slowed the design the most, the error flags actually. Good
> reason to toss the flags I suppose.

According to my ex-coworker, you should not try to optimize the design
for speed or area, but rather for readability by idiots. Because as
they are mean to you, you will quit, and then these idiots will have to
maintain your code. Any sort of cleverness is strictly prohibited.

[rickman]

On 10/9/2012 11:00 PM, Elizabeth D. Rather wrote:
> On 10/9/12 10:06 AM, rickman wrote:
>> On 10/9/2012 3:53 PM, Elizabeth D. Rather wrote:
>>> On 10/9/12 9:34 AM, rickman wrote:

> ....

I think you are explaining something to me I already know and am
reporting to you.

>> How much functionality is in the eval copies of Forth Inc embedded
>> Forths? Would I be able to develop a product with it? I haven't dug
>> into that lately, but I don't recall that it was practical to do any
>> development work with the eval version.
>
> Target programs are limited in size. Functionality is at the level of
> the "pro" version (all capabilities). All source is provided for the
> target kernel and library functions, along with at least one complete
> example program. Try one!

What is the size limit?

>> As to cost, Forth may be similar in cost to other code development
>> tools, but in this context it is a superfluous expense since the other
>> tools already exist in the company. At least that is how managers view
>> it.
>
> So, the next opportunity would be when you're addressing a new target
> for which you don't have a compiler :-)

I don't work for one of these large companies anymore. The next
opportunity is the next time I get paying work. In the mean time I will
take a look at the eval copies. I seem to recall the target eval
systems are somewhat limited the last time I looked, but that has been a
while so I'll do a refresh.

Rick

[Elizabeth D. Rather]

On 10/10/12 2:54 PM, rickman wrote:
> On 10/9/2012 11:00 PM, Elizabeth D. Rather wrote:
>> On 10/9/12 10:06 AM, rickman wrote:

...

>>> How much functionality is in the eval copies of Forth Inc embedded
>>> Forths? Would I be able to develop a product with it? I haven't dug
>>> into that lately, but I don't recall that it was practical to do any
>>> development work with the eval version.
>>
>> Target programs are limited in size. Functionality is at the level of
>> the "pro" version (all capabilities). All source is provided for the
>> target kernel and library functions, along with at least one complete
>> example program. Try one!
>
> What is the size limit?

It depends on the target. Basically, enough for a "typical" kernel
(kernels are entirely configurable) plus a demo application provided
with the system. However, you can't save an object image.

What you *can* do is write a small application and test it.

>>> As to cost, Forth may be similar in cost to other code development
>>> tools, but in this context it is a superfluous expense since the other
>>> tools already exist in the company. At least that is how managers view
>>> it.
>>
>> So, the next opportunity would be when you're addressing a new target
>> for which you don't have a compiler :-)
>
> I don't work for one of these large companies anymore. The next
> opportunity is the next time I get paying work. In the mean time I will
> take a look at the eval copies. I seem to recall the target eval
> systems are somewhat limited the last time I looked, but that has been a
> while so I'll do a refresh.

There's a feature comparison chart here:
http://www.forth.com/embedded/swiftx-embedded-systems-13.html

[gavino_himself]

On Friday, September 28, 2012 7:16:25 AM UTC-7, B.Person wrote:
> Posted 16 hours ago. Time to get into the ARM world; IMHO.
>
>
>
> http://arstechnica.com/information-technology/2012/09/99-raspberry-pi-sized-supercomputer-touted-in-kickstarter-project/

http://www.bigtits.com/videos/watch/barbie-bennett-and-sara-maclaughlin-having-a-nice-time-with-their-hot-friend-on-the-tub/34547

whats total mhz? how much ram?

[gavino_himself]

mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd?

[rickman]

On 10/12/2012 1:26 AM, Elizabeth D. Rather wrote:
> On 10/10/12 2:54 PM, rickman wrote:
>> On 10/9/2012 11:00 PM, Elizabeth D. Rather wrote:
>>> On 10/9/12 10:06 AM, rickman wrote:
> ...

>>>> As to cost, Forth may be similar in cost to other code development
>>>> tools, but in this context it is a superfluous expense since the other
>>>> tools already exist in the company. At least that is how managers view
>>>> it.
>>>
>>> So, the next opportunity would be when you're addressing a new target
>>> for which you don't have a compiler :-)
>>
>> I don't work for one of these large companies anymore. The next
>> opportunity is the next time I get paying work. In the mean time I will
>> take a look at the eval copies. I seem to recall the target eval
>> systems are somewhat limited the last time I looked, but that has been a
>> while so I'll do a refresh.
>
> There's a feature comparison chart here:
> http://www.forth.com/embedded/swiftx-embedded-systems-13.html

I have looked at this before, but perhaps it has been updated. The
problem is I don't understand what the list describes. I am offline
now, but I'll look into this when I am back online. (Now is when I am
writing this, not when it is sent...).

Rick

[rickman]

On 10/12/2012 4:35 PM, gavino_himself wrote:
> On Wednesday, October 10, 2012 5:48:20 AM UTC-7, Bernd Paysan wrote:
>> According to my ex-coworker, you should not try to optimize the design
>> for speed or area, but rather for readability by idiots. Because as
>> they are mean to you, you will quit, and then these idiots will have to
>> maintain your code. Any sort of cleverness is strictly prohibited.
>>

>> Bernd Paysan

>
> mr paysan where is your chip? where is the personal computer pwoered by paysan cpu? that runs firefox and is liek 10x faster than amd?

Rod seems to think we should be embracing these sorts of requests, but I
find them occasionally entertaining, but most of the time idiotic. I
don't see value in them at any time.

Forth can be run on any CPU. The chips that are designed to implement a
MISC type, stack based processor are not anything like CPUs used to make
PCs. They run nowhere near as fast and address no where near enough
memory to handle the tasks a PC needs to handle.

The persistent questions of Forth chip based PCs that run on batteries
for a month and make current PCs obsolete get old after a while.

If you want to the computer you are asking for, check out any of the
many Andriod based tablets available. They are the next wave of
computing and the PC as we know it will be something like obsolete in
another five years (meaning they will be selling far less than half the
units as the Android type devices). These devices will run Forth just
fine, but they won't be written in Forth. Get used to it!

Rick

[Elizabeth D. Rather]

The various features are described in the pages linked in the right-hand
panel.

[rickman]

Actually the feature list is pretty clear, it just isn't complete. It
doesn't mention any of the limitations in the eval version that you told
me about. Also, just so you know, the link you gave is to a page where
the box on the right has few working links. If I go to the hardware
page it has the same box and the links work ok.

I assume that when you say I can't save the object, you mean I have to
download to the target every time I want to test the code, so it has to
fit in the RAM. That means I can't burn it to Flash?

These sorts of limitations may seem necessary to a company, but it can
make it hard to evaluate a product. I often don't have time to spend
just evaluating a tool that doesn't contribute directly to a project.
At this time that's not true, so maybe I'll take a few days and look at
this.

Is there any aspect of these tools that require an Internet connection
during use? I've seen tools that only provide help via the Internet for
example. I don't have an Internet connection full time.

Rick

[Rod Pemberton]

"rickman" <gnu...@gmail.com> wrote in message
news:k5c919$otl$2...@dont-email.me...

> On 10/12/2012 4:35 PM, gavino_himself wrote:

...

> > mr paysan where is your chip? where is the personal computer
> > pwoered by paysan cpu? that runs firefox and is liek 10x faster than
> amd?
>

> Rod seems to think we should be embracing these sorts of requests, [...]

What? I've repeatedly stated that Gavino should stop asking such things.

What you're thinking of is where I recently said that Forth, for it to be
more popular in the future, needs to be able to do the things Gavino asks to
have coded in Forth, like operating systems, webbrowsers, websites, IRC,
NNTP, databases, and forums, etc. Forth being able to actually do something
is not the same as embracing Gavino's strange questions.

For some posts of Gavino's, I've also replied in a way that was designed to
get him to think about his questions in the non-Forth programming context he
understands, when the answer is the exactly the same as for Forth.

Bernd discussing his chip is entirely off-topic too. So, how is that you
asking Bernd questions about his chip is any different from someone
engaging Gavino?


Rod Pemberton

[rickman]

On 10/13/2012 8:51 PM, Rod Pemberton wrote:
> "rickman"<gnu...@gmail.com> wrote in message
> news:k5c919$otl$2...@dont-email.me...
>> On 10/12/2012 4:35 PM, gavino_himself wrote:

> ....

>
>>> mr paysan where is your chip? where is the personal computer
>>> pwoered by paysan cpu? that runs firefox and is liek 10x faster than
>> amd?
>>
>> Rod seems to think we should be embracing these sorts of requests, [...]
>
> What? I've repeatedly stated that Gavino should stop asking such things.
>
> What you're thinking of is where I recently said that Forth, for it to be
> more popular in the future, needs to be able to do the things Gavino asks to
> have coded in Forth, like operating systems, webbrowsers, websites, IRC,
> NNTP, databases, and forums, etc. Forth being able to actually do something
> is not the same as embracing Gavino's strange questions.
>
> For some posts of Gavino's, I've also replied in a way that was designed to
> get him to think about his questions in the non-Forth programming context he
> understands, when the answer is the exactly the same as for Forth.
>
> Bernd discussing his chip is entirely off-topic too. So, how is that you
> asking Bernd questions about his chip is any different from someone
> engaging Gavino?
>
>
> Rod Pemberton
>
>

At least I know you are reading my posts... ;-)

[B.Person]

~24 hours remaining, and $44,000 left to raise.

If your interested in getting a board, now is the time to pledge your support.


http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone

[B.Person]

They passed the $750,000 pledge goal.

Now the wait to get the board.