Best bang-for-buck uC

Two choices: either the toy language is C, or it can't be reasonably be done in C :)

There are too many poorly understood nooks and crannies in C; we need better.

Simple example: if we flip to C++, ahem, even the language /designers/ didn't understand what they were creating. They refused to believe the complexity of the template language made it Turing complete - until someone forcibly rubbed their noses in it. He wrote a short legal C++ program that never finished compiling - because the compiler was emitting the sequence of prime numbers during compilation[1].

Now if even the language designers don't understand basic principles of their language, what chance have mere mortals.

That's a Big Clue that the tool is part of the problem. I prefer tools that are part of the solution.

But I've been using C for 35 years, and I imagine I'll continue to use it.

Caches are a red herring. If you get rid of them (hello xCORE!) then you still have global memory coherence to screw you up.

IMNSHO you /don't/ want global memory coherence in a highly multicore system, because the penalties for achieving that are unacceptable.

Ditto global clocks. Ditto global time.

(Read Leslie Lamport for the latter!)

Your point being? ;)

In his case, the toy language is Erlang.

There's a latin tag, "Abusus non tollit usus", i.e. the abuse doesn't abolish the use.

As a chemist friend of mine says, "If you aren't part of the solution, you're part of the precipitate."

Why on earth not? Just pissing off CS academics is reason enough, not to mention that it gets the job done. ;)

Cheers

Phil Hobbs

(Who has had enough of "pure science" types to last him a lifetime even in physics and math. CS types pulling the same crap is just silly.)

SMPs are a lot more generally useful than less-symmetric systems. The more you relax the coherence guarantees the more you restrict the range of problems you can address efficiently.

A dozen years or so ago, I wrote a clusterized 3D FDTD electromagnetic solver with advanced optimization capability to support my work in optical antennas, and I still use it. Even though it's almost in the embarrassingly-parallelizable category, it runs better on a big SMP than on a cluster of smaller ones on account of cache coherence.

Cheers

Phil Hobbs

Yup; that's the dilemma - and there is little (if any) sign of it being resolved.

The other side is, of course, that SMP restricts the /scale/ of problems that can be computed in a reasonable time.

I'm sure it does. There are sweet spots for most technologies.

I've seen, assessed (and avoided) a telco system that runs on SMPs and makes full use of their features. The assessment concluded that there was a hard unbreakable limit in the scale of the system that could be implemented. The PHBs decreed it would be implemented, and guess what happened.

That was 18 months of someone's life down the drain; he wasn't happy, since he had predicted it.

Polynomials was used on many DEC systems. The PDP-11 FORTRAN IV+ used forth order for single and 8th degree for double. On VAX/VMS, the arc was divided into more sectors and single precision was 3rd order and double 7th order. The VAX had the POLY instruction, essentially multiple MAC (Multiple adds), so after you had split the argument to correct sector with correct coefficients for each sector, a single POLY instruction was needed for sin, log, square roots etc. calculations.

With a large number of identical processors, fast DSP algorithms could be implemented by splitting a complex algorithm into a pipeline, each processor handling only one stage of the algorithm.

Also some PLC (Programmable Logic Controller) type operations can easily be implemented.

I agree that trying to convert any random Windows application for a large number of processors, is a big challenge.

it should suit net browsers well though, and those are the biggest cpu hog on a lot of desktop systems.

NT

I wrote a preemptive multitasking RTOS for the 6800. In longhand. In Juneau Alaska. I mailed a few sheets a day back to New Orleans, where people punched cards for assembly. It had one bug.

It was a nuisance. A NOP took two microseconds. There wasn't an instruction to push the index register onto the stack, and it wouldn't multiply, among other things.

That also taught me the reason why semaphores are necessary; my university project supervisor was pleasantly surprised when I knew about them before the course had been started :)

My final year project was a 4TTY -> computer multiplexer, both hardware and 6800 asm software.

I wrote an exceptionally simple "executive" that did little more than save/restore each task's PC and SP. It was only a few instructions.

That was used infrequently in "user code", unlike loading the index register from a location defined by the index register. I used that very frequently to chain along linked lists. When I tried to do that in the Z80 with its IX and IY registers, it was seriously painful; so painful that it was better to use plain old 8080 instructions with the HL register.

My theory is that the Z80 won because of a better hardware interface and the beguiling possibility of doing a print statement in a single instruction. Beguiling to hardware engineers that is, until they tried to do it in a real system, and found all its inadequacies.

That was rare then, but surprisingly doing it in software was little slower than having an external hardware multiplier chip.

Next Sunday I expect to see the world's oldest operating computer, based on Dekatrons, plus a working example of the first computer I used in anger, complete with 39bit words and magnetic film peripheral complete with sprocket holes. At the last two visits the attendant whipped out the circuit diagrams and we poured over them together :) That's my kind of museum :)

Plus the clunk of ASR33s is always /extremely/ evocative.

Elliott 803 / 503?

Elliott 803 :)

Folks, how about snipping a little here? 230 lines of quotation for a smiley? What is this, AOL?

Dan