Re: ping john Larkin Raspberry Pi Pico gets BASIC interpreter

It's a great example because it requires an entirely different mindset; much like OOPS vs. procedural coding.

And, if you've been working in resource starved environments (e.g., deeply embedded systems with hardware of that era), the least of which problems is getting used to the inefficiency of such representations!

But, there are tools/technologies that let you express problems with full parallelism. Granted, as you work on each subproblem you think serially. But, the tool/technology lets those individual subproblems come together *correctly* -- if you've embedded the right dependencies in the expression!

Dunning-Kruger. He's obviously only looked at toy applications... likely written in simple languages (e.g., BASIC). And, thinks you solve performance problems by buying faster hardware.

Ditto the simulations. And, likely heavily relied upon in the design of the silicon/discretes that's used! I can recall doing full customs and having to model the effects of temperature, supply and process variations in all my performance models. Won't work to design something that runs ONLY at "STP"!

I'd be happy for a power supply that didn't s*it the bed. I watch countless devices headed to the tip simply because their designers couldn't/wouldn't design a supply that "ran forever" (isn't my software expected to do so??)

And most employers neither want to hire qualified people nor take their EXPERT ADVICE on how to tackle particular jobs.

I've had employers/clients treat projects as "time-limited": "So, what SUBSET of the product do you want to implement?" (clearly, if you only have X manhours to throw at a project that requires Y > X, something just isn't going to get done. would you like to make that decision now? Or, live with whatever the outcome happens to be? Or, get smart and no-bid the job??!)

Ask a coder how long a particular piece of code takes to execute. (particularly amusing for folks who *claim* their application is HRT; "what guarantees do you have as to meeting your deadline(s)?")

Or, to guesstimate *percentage* of time in each portion of the code. (do you know how the compiler is likely going to render your code? do you know what the hardware will do with it? If you *measure* it, how sure are you that it will perform similarly in all possible cases?)

Or, how deep the stack penetration. (how can you know how much space to allocate for the stack if you don't know what worst-case penetration will be? what do you mean, you're relying on libraries to which you don't have sources??? how have their needs been quantified?)

Our "CS" department was a subset of the EE curriculum. So, you learned how to design a CPU as well as WHY you wanted it to have a particular set of features.

On the CS side, you understood why call-by-value and call-by-reference semantics differed -- and the advantages/consequences of each. And, how to convert one to another (imagine how to implement by-value syntax for an argument that was many KB -- to avoid the downside of by-reference semantics!) What can you do *in* the processor to make these things possible? What are the costs? Liabilities?

And what excuse for power supplies that fail?

Why do you derate components instead of using them at their rated limits? Ans: because experience has TAUGHT you to do so.

The same sorts of practices exist in software engineering -- for folks who are aware of them. And, they provide the same sorts of reliability (robustness).

I built a bar-code reader into a product many decades ago. As cost was ALWAYS an issue, it was little more than an optical (reflective) sensor conditioned by a comparator that noticed black/white levels and AGC'd the signal into a single digital "level".

That directly fed an interrupt.

That ran continuously (because it would be a crappy UI if the user had to push a button to say "I want to scan a barcode, now!"

The design targeted a maximum scan rate of 100 ips. Bar transitions could occur at (worst case) ~7 microsecond intervals. (40 year old processors!)

And, nothing to prevent a malicious user from rubbing a label across the detector -- back and forth -- as fast as humanly possible (just to piss off the software and/or "prove" it to be defective: "If it doesn't handle 300ips, how do we know it is correctly handling 100ips?"

Yup. You could consume 100% of real-time by doing so. But, the processor wouldn't crash. Data wouldn't be corrupted. And, when your arm eventually got tired, you'd look up to see the correct barcode value displayed!

Because the system was *designed* to handle overload *gracefully*.

Ever see a PC handle a hung disk?

Most often, these are "people failures". Someone failed to perform a step in a procedure that was indicated/mandated.

How many technicians design custom silicon?

We had a guy who was perpetually *RE*bugging the floating point libraries in our products (we treated software modules as components -- with specific part numbers catalogued and entered into "inventory". Why reinvent the wheel for every project?) It got to the point that we would track the "most recent KNOWN GOOD release and always avoid the "latest".

And, no *followup*!

Conversely, writing a piece of code that can stand for years/decades and be understood by those that follow is a *skill*. When your product life is measure d in a few years, you're never really "out of development".

All the computers that I know of execute instructions sequentially, so their compilers assume procedural programming.

Are there any parallel-execution computer languages, like Verilog? That would execute very inefficiently on any "computer" architecture.

FPGA programs have far fewer bugs than computer code. The "state" of a procedural program is the number in the program counter(s) which is mostly an uncontrolled mess. A state machine with 2^192 states, for example, is hard to map on a whiteboard.

Because I define the states and the tools implement them correctly. The tools do optimize my logic equations for speed and to fit the actual architecture but they always do that right.

Sometimes we have to force the tools to *not* optimize logic expressions, especially if we want some delays to not be removed. Those cases are obvious and there are simple tricks. But that just works without the scores of latent bugs common to software.

We know the worst-case timing path in FPGAs. uP programmers can't usually guess execution time of an interrupt within 10:1. In my experience, they tend to be very pessimistic, and I have to force them to measure it.

You can look at my web site. All that stuff works, and people buy it, and that's the bottom line.

We usually shift "performance problems" into FPGAs and let uPs do the grunt work like web pages and displays and pushbuttons. We sell electronic instruments and this is S.E.D.

Because it routinely does.

The Actel FPGAs were interesting. One-time programmable, soldered to the board, with no simulation tools. We got some hairy digital delay generators, with exotic PLLs, to work first time.

This rings a bell; a fine stereo component on my AV shelf has needed my diagnostic attention three times, once for bad power-component solder joints, once for a failed filter capacitor, and once for a high-voltage switch element. All three faults (and it has DSP, DVD, remote controls, and extensive audio and digital circuitry to support that) were in power supplies.

PCs used to be well-designed, a power supply failure meant you just unplugged the silver box and bought a replacement. Now, though, motherboard POL supplies are the big failure mode I see Unidentifiable crispy things, not repair-friendly..

Is there something revolutionarily advanced about the design of power supplies? You'd think after all these years, it would be an "established science"! :>

I rescued a NAS with a power supply problem. Turns out to be an intermittent cable connection. In a *sealed* unit (so, how did the connector fail with no one dicking with it??)

Software is "easy" to fix (download an update) yet hardware failures prove to be the thing that obsoletes devices. Seems like attention is focused in the wrong place! :> We need better HARDWARE quality!

No big line frequency transformers and, recently, megahertz GaN switchers.

snip

There have been a number of them developed at universities. Few have seen mainstream acceptance. OCCAM is a programming language based on Hoar's Communicating Sequential Processes (CSP) - a delightful read with an abundance of logic and mathematical proofs. The target machine was the transputer (INMOS) - which when I had to learn (and subsequently do tutorials on it) was a weird beast when compared to the PDP11's, MC68xxx and 8086 platforms of the day. OCCAM lives on as OCCAM3 and OCCAM -pi but I have no clue where it usage is at this point.

If one is citing Verilog, and event-driven /hardware description language, VHDL can be included.

I'm just an electronics designer. I want bare-metal c programs and the proof is that it works.

My guys prefer VHDL, but sometimes inherit some Verilog from somewhere and do mixed projects. That seems to work.