Joined: Fri Aug 30, 2002 1:09 am Posts: 8545 Location: Southern California
|
kernelthread wrote: GARTHWILSON wrote: A problem I see with the microcontrollers however is that the student will not learn about many things like address decoding, buses, and timings. Too often the curriculum that goes with microcontrollers will also use a high-level language, not assembly, let alone starting with hand assembly so the student learns the lowest levels and then builds up from there, knowledge upon knowledge. Well, microcontrollers are now designed so you don't need any assembler code whatsoever. If you look at the ARM Cortex-M or AVR, you can write absolutely everything in C. Even hardware design (at least for digital circuits) is done in a "high-level" language now, like Verilog. Do you need to know how to implement an adder in logic gates? You can just specify an addition in the Verilog and it incorporates a pre-written library function. OK, so somebody has to know how to write the library functions but most don't need to. Our daughter-in-law graduated at the top of her class at the university in computer science. This was not computer engineering, and she knows virtually nothing about circuits, interrupts, etc., but rather html, CSS, SQL, database, Java, Javascript, C, C#, C++, Python, and a lot of other things I know virtually nothing about, and she still works for the school in maintaining their website, things like online classes, class scheduling, student enrollment, records, payroll, etc..
As Ed said, there are various stopping-off points. We need the people like our daughter-in-law above; but we will always also need the ones who know the low-level stuff, unlike her. To focus on the one at the exclusion of the other is a big mistake. I recently met a new graduate in computer engineering though, who had taken all the classes in processor design, and I wanted to pick his brain about the design of MMUs, caches, deep pipelines, branch prediction, etc.. He wasn't able to answer any of my questions! It sure doesn't speak well for what's going on in the schools today. Maybe all he was taught was how to do drag-and-drop on chip-design software.
There are organizations that supposedly do computer education from grade school through high school, like code.org. One thing that really stands out to me on code.org is, in the analogy of Formula or CART auto racing, that they expect and promise all the kids that they will be the fast race-car driver. They seem to ignore the fact that the driver isn't going anywhere unless there are engineers and technicians behind him who are interested in fuel systems, ignition systems, valve timing, aerodynamics, etc., who probably never drive the fast car themselves or even have any interest in actually doing so. Code.org shows everyone doing the flashy graphics and drag-and-drop. What goes on under the hood is indispensable, not something to be put in a glass box in a museum; but code.org gives it no attention, at least on the pages and videos I saw there. They also seem to ignore embedded-control computers that don't use any graphics at all, and may not even have any human I/O.Quote: GARTHWILSON wrote: I have to ask again where tomorrow's engineers will come from. Other countries, presumably. Sadly, that may be the reality. I would like to help keep it from being that way though.Quote: GARTHWILSON wrote: I would add that the performance is irrelevant in the first semesters of such education where they're just blinking an LED, feeding an intelligent character LCD, reading a temperature, interfacing to I²C devices, monitoring optical sensors, scanning a keypad, etc.; so a 500MHz 32-bit microcontroller has no advantage over the 6502. Performance is relevant if you want to be able to do everything in a high-level language - especially an interpreted language where things can take orders of magnitude longer than the same functionality in assembler. I do that stuff in Forth on a 5MHz 65c02. When I need more performance, it's very easy to mix a little assembly language in. Assembly language is a lot easier on the 65's than it is on the higher-scale processors.
The bloat and inefficiency of the code that goes into modern high-en processors is indeed staggering though. In this 9½-minute video posted July 25, 2022, "Programmers Aren't Productive Anymore," apparently an excerpt from a seminar, Jonathan Blow says that all these modern high-level languages (HLLs) are making programmers less productive now, and that the HLLs are failing to deliver the promised benefits. He says that as we go up the ladder of HLLs, "somewhere through this chain, it becomes wrong." He does say we don't want to go all the way back to assembly language, because of the lack of abstraction; but I address that criticism in my article on doing program flow-control structures in assembly language through macros, and in other places on my site. There can be lots of abstraction, with, in most cases, no penalty at all in either in code size or run speed.
Here's another (short) Jonathan Blow video from 2017, about modern bloatware eating up all the benefits we might have gotten from hardware advances: https://www.youtube.com/watch?v=4ka549NNdDk&t=290s It's cued up to what I think is the most important part which is less than three minutes long. He's saying that with increased clock speeds, increased memory speeds, larger caches (which should mean fewer cache misses), and more cores, we should be seeing much better performance, yet taking Photoshop as an example, which should be 192 times as fast as it was a couple decades earlier, the reality is that there's been virtually no speed-up.
[Edit, 1/4/24: I just found out this is called "Wirth's law. The Wikipedia article starts with, "Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. The adage is named after Niklaus Wirth, a computer scientist who discussed it in his 1995 article 'A Plea for Lean Software'."]
This is something I noticed even in the late 1980's when a new technology was introduced that improved memory prices and speed a lot in one step, and immediately Microsoft was saying, "This is great because now we don't have to be as careful and we can get new software out faster," and what happened is that the user never got the benefit. Boot-up took just as long, the "disc full" or "insufficient memory" messages came up just as often, and there were just as many bugs. Processors also got faster, but bloatware nullified the speed advance.
asveikau, who had been a developer at Microsoft said, "From a certain vantage point, in these languages, if you aren't seeing assembly from time to time, you're not seeing reality."
I'm constantly straining to make software more efficient, powerful, maintainable, etc., and to demonstrate what can be done with simpler hardware; and this is what I would like to se emphasized in early computer education and kits.
_________________ http://WilsonMinesCo.com/ lots of 6502 resources The "second front page" is http://wilsonminesco.com/links.html . What's an additional VIA among friends, anyhow?
|
|