No, the rules are well defined. It was me that was speaking loosely, don't blame the language! I was just making the point that it may not be worth the effort to micro-optimise in this way. Write the program "naturally", using "int" for (integer) numbers and "char" for characters. Only if you start to run out of RAM or code space, *then* you can start seeing what can be done. But it probably wont make all that much difference.
-- John Devereux
Academics seldom want to teach stuff that's actually in use in industry to engineering students. They claim that the examples they choose are more elegant and that they are just using a specific example for pedagogical reasons, but I suspect a bit of snobbery in that they want to exclusively teach fundamentals and theory and not vocational arts.
Best regards, Spehro Pefhany
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
No, I think he means that there may be several ways to code a particular task -- all of which adhear to the standards. On some processors one way may be an order of magnitude more efficient than the others. On other processors it might not matter. For example, on a 68HC11 project a few years back, one needed to know that indexing through an array generally took about 50% more code and 100% more clock cycles than incrementing a pointer through an array. Both methods were
100% standards compliant, and the code was both correct an portable no matter which way you did it. But one way sucked as far as performance and resource usage.Unfortunately, "The Standards" don't write programs for you nor do they specify only a single way to write a program.
--
Grant Edwards grante Yow! Yow! Are we laid
at back yet?
visi.com
That hasn't affected portability in the least. It is an indication that you are using compilers whose optimization phase (if any) sucks green eggs. And yes, I do agree that when using such beasts you have to cater to them. Something like wives. Ignore their foibles at your peril.
-- "The power of the Executive to cast a man into prison without formulating any charge known to the law, and particularly to deny him the judgement of his peers, is in the highest degree odious and is the foundation of all totalitarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
When I were a lad, we had to wind our Turing machine tapes by hand...
Seriously, I think you started a little earlier than me (I'd guess you are a bit older?). The first computer I ever saw was a Commodore Pet, when I was about 7, and it had a keyboard. That's when I decided I wanted to be a programmer when I grew up.
The natural size for an 8 bit machine is 8 bits. so you should use the 8 bit integer types of signed and unsigned char. Plain char is used fro characters.
The reason is that on 8 bit machines a 16 bit int requires 2 fetches etc. so not only does it take up more space but it slows down the machine.
It is true that integer promotion rules will often convert to int but not always. Also if the items being operated on are 8 bit integer types (ie signed/unsigned char) and the result is to be stored in an 8 bit type only the intermediate value is an int. Most 8 bit compilers can be instructed to turn off the integer promotion.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I still remember the front panels fondly and wish they existed for the
80x86 PCs. It would be wonderful to have access to all the registers, MSRs, MTRRs, re-order buffer, etc., via a front panel!It was a transition for me to go from a MITS Altair 8800 front panel with metal bat-handle switches (which gave you callouses, after a time) to the IMSAI's flat plastic switches (which I still have a box of, for both colors, and don't think are even made anymore, today.) Keyboards weren't all that readily accessible to hobbyists, at the time. I remember saving them as spares from larger equipment and adapting them with custom logic to my needs. I would not infrequently wind up entering ASCII via a front panel.
I would have been in my 20's when the PET came out. It was way too expensive for me to consider owning, at the time.
Jon
Yup. The 68HC11 compiler I mentioned above never even used the second index register. The code generator was apparently written for a 6800 variety with only a single index register. Still, it sucked less than the other compilers that were available at that time. And they were all damned expensive.
If only the 6811/6812 support had been in gcc back then...
No comment.
--
Grant Edwards grante Yow! I'm in a twist
at contest!! I'm in a
visi.com bathtub! It's on Mars!! I'm
in tip-top condition!
IAR?
-- John Devereux
The one we were using was from Introl. This was about 17 years ago (damn, that makes me feel old). Somebody I worked with had done a pretty comprehensive comparison of the available cross-compilers -- I don't remember if IAR was around then or not. Introl sucked the least, but it still sucked. There were improvements that could have been made by something as simple as a three-instruction peephole optimizer.
About two years ago, I built a gcc cross-compiler targeted for the 68HC11/12 and looked at the code it was generating. The code was _way_ better than any of the commercial compilers that I had seen (admittedly many years prior).
--
Grant Edwards grante Yow! Should I get
at locked in the PRINCICAL'S
visi.com OFFICE today -- or have
a VASECTOMY??
I grew up with what could be called mid-size mainframes and often miss the banks of register/switches with which various things could be monitored/altered. The hardware stop and single-stepping of instructions had its uses.
I never had the pleasure of entering programs via toggle switches but I did go through the joys of audio tapes for the Apple II.
I had my eye on the PDP8i and thinking that if the price ever got below $10K, I might buy one. MITS and the others came along in time to preclude my doing that.
There are much better reasons for them to stick to 'academic' examples: academic teaching *is*not*supposed* to be the end of learning for an engineer. It's the beginning, and its most important goal is to teach people what they need to know so they can efficiently learn all the modern stuff themselves, as the need arises.
The goal is not to produce graduates fit in exactly the currently hyped industry buzzword technologies. It can't be, for several reasons. For starters, industry hypes come and go too fast. Even if a university really went to the expensive trouble of turning the current hype into course material suitable for complete beginners, every year, almost none of it would still be relevant when those studends graduate. So they have to teach stuff that at least stands a solid chance of still being correct, hopefully even relevant, when their graduates hit the street.
University education is not supposed to be a recipe collection --- it should provide the framework needed to give structure to the flood of details you'll have to integrate later.
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
Very well put.
I don't expect a new grad to know the development tools or programming language or CPU core or other technology details that will be used on the first job. I expect the new grad to know enough of the underlying principles that she'll be able to learn those things without a problem.
And I expect new grads to be able to write a comprehensible paragraph or three.
Unfortunately the latter is a problem more often than the former.
Sometimes I think it would be easier to teach electronics and programming skills to an English major than writing skills to an Engineering major. Anybody who really understands how to choose between objective and subjective pronouns isn't going to have any problem learning a programming language.
1/2 :)
--
Grant Edwards grante Yow! Wait... is this a FUN
at THING or the END of LIFE in
visi.com Petticoat Junction??
But I'd expect a new engineer to be aware that the CPU core or the compiler might be broken, and to have some clue as to how to isolate and work around the bugs. I'd expect them to understand that requirements and timescales can shift dramatically under you.
Fortunately we had to deal with enough of this as we did a lot of work on a homebrew vector-graphics system (a bit like a DEC GT-40) with notably buggy firmware in the first year of our degree ;)
(Our only team software engineering course was famous for having a 'requirements change'. You knew it came in the 7th week, because it did every year, and you knew that it'd always involve making the scope of the system you were building more generic, because it always did. The wise designed around it ;P)
I'd also expect them to be able to estimate in their heads - "how many piano tuners are there in Birmingham?", "how much does a gasometer weigh?" etc.
Grin. But that's just syntax, not semantics ;) Anyone who's been exposed to relativism and postmodernism at an early age is probably beyond salvation when it comes to the very grounded world of embedded systems. (It's probably a positive advantage for IT systems, mind...)
pete
-- pete@fenelon.com "there's no room for enigmas in built-up areas" - HMHB.
A reasonable expectation, but orthogonal to the complaint that "Universities are teaching language X instead of language Y when language Y is more popular in industry than language X."
I had never even seen C code until after I graduated. We mostly did projects in Pascal. Even for microprocessor stuff.
But, since I already understood the difference between a variable's scope and a variable's lifetime, it only took a few days to pick it up.
That happens to you too? ;)
I'd have thought that dadaism would be a good background for the random-string-of-meaningless-buzzwords that is IT.
--
Grant Edwards grante Yow! NANCY!! Why is
at everything RED?!
visi.com
had
Of course, I had that pleasure, too. As well as tapes for the IBM PC. Radioshack had a tape player with the right controls for starting and stopping under software control and it worked okay, and cheaper. I used paper tape a lot, earlier than this, and had purchased a simple reader head (no motor) where I could simply pull the tape through. It could observe the tinier sprocket holes, so I could time the reading of the other holes in my software driver (which I wrote and toggled in through the front panel.)
Since you bring up the 8i, I also used DECTape, back then. Still have spools of it in a box, somewhere. I worked on PDP-8's (e, I think) and PDP-11's (those with front panels, like the /45) and would have very much drooled at the idea of having either for my own. But you must have been richer than I, to have even considered the idea of owning one at a price like that. It was a struggle and a half for me to actually buy the unassembled parts for the Altair 8800, without a power supply or anything else to go with it. Even the 256 bytes of static RAM it came with couldn't be upgraded on my budget, despite the fact that there were three unfilled sockets just sitting there waiting for three more 256 byte chips. It took me almost a year to pull together enough cash to buy two 4k dynamic RAM cards, after that.
My salary at the time was about $525/mo. and I was paying my own way on everything. When I got an increase to $552/mo, midway through the year, it made a huge difference to me, too.
Jon
Grant Edwards posted on Thu, 09 Feb 2006 15:36:40 -0000:
"I always thought that Modula-2/3 would have been ideal languages for embedded systems: much safer than C."
I am surprised that James Granville has not already replied by directing you towards
" Actually Ada has it's problems, but I've always wanted to give it a try as well."
Which is the core failing of academia because as a rule they have little or no experience of such matters.
Ian
Oh, but I do . The problem is users do not understand the rules and the rules vary with compilers (especially in 8 bit systems).
And my point is that is precisely why programs 'tend' to do things. People don't know the rules, make erroneous assumptions but the code still works so they think nothing is wrong - until the particular set of circumstances occurs in the field that causes the app. to crash.
Ian
>
Probably as much as two decades between us which in computer terms is a lot of progress ;-) (I was born in 1950)
Ian
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.