Programming for Electronics Engineers

[Rich Grise]

This is still no good because Q and be above 10000 and still work.

I picked that out of the air for my example because I have no idea what
his actual range is

You've also added a whole bunch of lines to the program. Is this effort
really worth it?

It depends. It tells you to input two values. You input two values, and
one of them is out of range, and it tells you, "Illegal value(s)". This is
kind of worse than useless. As you said, it gives no indication what the
values should be - I just took that one step further and validated them
individually.

How many times will you use the program before you edit
it into being a function some larger program calls.

Oh, well, that, yeah, of course. But we're showing example code here.

Thanks,
Rich

 

[Rich Grise]

[...]
write('Q = '); readln(q); { Read in the values }
write('P = '); readln(p);

p := abs(p); { The sign doesn't matter }
q := abs(q);

if (p=0) and (q=0) then halt; { Don't use silly values }

That's BAD user interface!

repeat
flag := true;
write('Q = '); readln(q); { Read in the values }
write('P = '); readln(p);
if (p=0) and (q=0) then { Don't use silly values }
begin
writeln('Illegal value(s)');
writeln;
flag := false
end
until flag { = true } ;

That's worse because it doesn't giver the user an escape if he doesn't
happen to know some good values. In this case it is not much of an issue
but if the restrictions were tighter, this would be a very bad idea.

repeat
flag := true;
write('Q = '); readln(q);
if (q=0) or (q > 10000) then
begin
writeln('Q must be between 0 and 10000');
writeln;
flag := false
end
until flag;

repeat
flag := true;
write('P = '); readln(p);
if (p=0) or (p > 10000) then
begin
writeln('P must be between 0 and 10000');
writeln;
flag := false
end
until flag;


Cheers!
Rich

--

That's a lot of trouble to avoid a coupe of GOTOs. I never understood
the anti-GOTO religion.

I just didn't remember if Pascal had gotos or not. If I'd been allowed to
use "C", I'd just continue;.

Cheers!
Rich

 

[Rich Grise]

Someone said that GOTOs were a bad thing and everyone believed him.

You can take any program that uses GOTOs and rewrite it as one that is
harder to understand without GOTOs. It is so easy that a program to do
the conversion can be written.

It could be simply an overreaction to some of the nightmare spaghetti code
that got written before people learned how to break out of loops. Heck, in
one of the first languages I learned, "For-Train", one very prominent
feature was the "Computed GOTO". That's like, the whole raison d'etre of
stored-program automatic calculating machines. ;-)

Cheers!
Rich

 

[Rich Grise]

On Tue, 18 Jan 2005 02:24:24 +0000 (UTC), the renowned


Specifically, Edsger Dijkstra's 1968 paper "Go To Statement Considered
Harmful":

http://www.acm.org/classics/oct95/

Like all good things, it can be taken too far.

"...our intellectual powers are rather geared to master static relations
and that our powers to visualize processes evolving in time are relatively
poorly developed."

Hey, speak for yourself, Dijkstra!

What he apparently means is that GOTOs should be avoided by the
feeble-minded. ;-p

Cheers!
Rich

 

[Jim Thompson]

On Mon, 17 Jan 2005 23:11:23 -0500, Spehro Pefhany

[snip]

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.


Best regards,
Spehro Pefhany

You can READ 9 pt ?

...Jim Thompson

 

[John Larkin]

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.

300 pages is, what, 15k lines? That's a lot of assembly.

I still like to print them on fanfold, put them in a listing binder,
and take it to bed and read it over very carefully. I can make notes
in the margin, add post-its to flag things, stuff like that. I hate to
debug in the lab, so I try to get everything right the first time.
After a couple of passes like this, things get pretty good and, in
fact, I spend very little time debugging... maybe 10% or less of the
coding time. I like to make things largely table-driven, as opposed to
tons of branchy code, and that helps keep the bugs down.

Most of my embedded stuff seems to run around 4K lines, often less
(except for that 16-bit sine routine that was, um, 128 kbytes long. I
..nlisted that part.) Somewhere around 10K lines or so, flat assembly
programs (and their paper listings) start to get unweildy.

Lately most of our assembly progs have one or more Xilinx fpga config
tables built into the rom image, so the uP can boot the fpga's. We
wrote a rom builder program, sort of a primitive linker, to build
images out of S28 code and .RBT fpga config files. Dumb but works.

So, off to bed, with a listing.

John

 

[Rich Grise]

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.

Well, if you're pouring very expensive cognac, it might be a good idea to
have a high-value doily like a listing. ;-)

Remember the launch pad gag?

When I was about 12, the family would have neighbor families over from
time to time, so the adults could drink and the kids could watch TV or
whatever. Well, I was very fortunate, in that my folks used to let the
kids watch the adults drink.

One time, during the "tell a better joke than the other guy" phase of the
drunk-fest, my Dad (bless his soul) came up with:

"Well, there's been some space shots, and they're very expensive. And one
of the most expensive parts is the launch pad [while giving this patter,
he's taking a cocktail napkin and rolling it into a cylinder] - so, does
anybody have, say, a $20 bill we can lay here, to represent the launch
pad? Great! [he says as someone proffers a 20]. So, this is the missile
[he puts the loosely rolled-up cocktail napkin, maybe 1" cylinder, upright
on the 20]. And they have this countdown, before they fire off the
engines. We're going to represent this by lighting it [ he lights the top
of the cylindrical napkin, as one would light a candle, but it's paper
napkin burning] Ten! Nine! Eight! [and so on - the napkin continues to
burn, from top down, producing well-defined, but very fine, ash] Two! One!"
And the ash and remnant of smouldering paper gets entrained in the
convection, and rises from the "launch pad", as if by magic. EVERYONE
watches the rising napkin ash, and when it finally becomes soot, everyone
looks back at Dad and the $20.00 launch pad, and the $20.00 is gone.

"I don't know what happened to it! Maybe it got burned up!"

Of course, the gag is simple misdirection.

I'm gonna have to try this sometime. %-)

Cheers!
Rich



Cheers! Rich

 

[Guy Macon]

Yeah, but where do you get the 300-key keyboard?

Y&ou can use two of these:

http://www.monu-cad.com/keyboard.htm

Or 1/10 of one of these:

http://www.honco.net/japanese/05/caption/caption-1-03.html

 

[Bjarne Bäckström]

This is still no good because Q and be above 10000 and still work.

You've also added a whole bunch of lines to the program. Is this effort
really worth it? How many times will you use the program before you
edit it into being a function some larger program calls.

Sorry, I've missed the earlier replies because I've limited the
number of posts in one download to the latest 50 in each group.

My comment was a bit 'tongue in cheek,' but I really think one should
under no circumstances let a program quit, without letting the user know
whether the program crashed or he/she did something wrong.

 

[Frithiof Andreas Jensen]

43 years later, in my opinion, for what it's worth, the salient attribute of
so-called professional computer programmers is the ability to make vast
amounts of money under false pretences.

.... And this is a Bad Thing?

 

[Frithiof Andreas Jensen]

You have to realize that guys like Jim and I are fulltime circuit
designers. .........
grapher program. Some of the stuff I do is very compute intensive, so
a pig like Visual Basic would be unusable. So what we need is a
simple, quick, easy to learn and easy to use language that runs fast.
And, at least for me, can do hardware i/o without requiring me to
write device drivers.

Python with the 'Numeric' and 'Scientific Python' (numpy & scipy) packages
should do you then!

Python have all the OO constructs, classes and whatnot too - AND you do not
have to use any of it either, if you do not want too!

I *like* Python ;-)

 

[Keith Williams]

Yeah, but where do you get the 300-key keyboard?

No need. I used APL on a PC (pre PS/2) keyboard. Before that, 2741s
(essentially ruggedized communicating Selectric typewriters) with APL
keyboards and type-balls. If you can put the character set on a golf-
ball it's not going to take 300 keys.

 

[Spehro Pefhany]

On Mon, 17 Jan 2005 23:11:23 -0500, Spehro Pefhany

[snip]

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.


Best regards,
Spehro Pefhany

You can READ 9 pt ?

...Jim Thompson

I'm myopic. I can just take my glasses off and move closer to focus.
;-) It's gotten a bit too close for dangerous stuff or confined
spaces, though. 8-(


Best regards,
Spehro Pefhany

 

[Keith Williams]

A great engineering language is one that the occasional user can
remember, and that allows one to revisit old programs and understand
and modify them easily.

Dunno about the last issue. If it's easier to write the function
again... As for the occasional user, I was an occasional APL user some
20 years ago. It was great. I'd argue that a great engineering
language should include matrix operations, where APL excels.

If that is your criteria for a "GEL", then I'd propose that Excel is a
GEL. It's amazingly powerful, easy for the occasional user, and easy
to understand and modify. I've even done logic
simulations/demonstrations with it.

That doesn't sound much like APL. Or C, for that matter.

Come on, John! Everyone knows that no matter what the question, the
answer is 'C'.

 

[Keith Williams]

[...]
That's a lot of trouble to avoid a couple of GOTOs. I never understood
the anti-GOTO religion.

Someone said that GOTOs were a bad thing and everyone believed him.

I feel that GOTO can be valid in a certain circumstances.

Such as GOTO <special exit point>.

However people will abuse anything they are offered, so
GOTO <valid local jump>
gets used a
GOTO <any place I damn well please anywhere in the entire program>

Given the scope for appalling abuse, it might be wise to recommend very
sparing usage.

I heard of a guy who's immediate boss (the company boss's son) thought all
code should use GOTO almost entirely, and tried to force everyone else to do
so.

I prefer very flat programs controlled by conditional GOTOs (or JMPs,
in assembly) that operate as state machines. After all, not many
computers have curly brackets in their native instruction sets. What
language you use, and how you use it, just depends on how you think.

I prefer to use CASE like statements to implement state machines. The
PL/I Select/when fit me like a glove here. VHDL's CASE is not quite as
powerful, but makes very readable state machines. If it's done right
the implementation of the state machine can be determined at
compile/synthesis time, rather than during design.

 

[Keith Williams]

300 pages is, what, 15k lines? That's a lot of assembly.

I still like to print them on fanfold, put them in a listing binder,
and take it to bed and read it over very carefully. I can make notes
in the margin, add post-its to flag things, stuff like that. I hate to
debug in the lab, so I try to get everything right the first time.
After a couple of passes like this, things get pretty good and, in
fact, I spend very little time debugging... maybe 10% or less of the
coding time. I like to make things largely table-driven, as opposed to
tons of branchy code, and that helps keep the bugs down.

Another advantage of table-driven code is hardware revision control.
On project I had needed to operate on several different versions of
hardware (several processors that had to inter-operate differently
depending on who they're talking to). I had a table for each supported
set of hardware. The entries in the tables were addresses of the
supported functions for that revision. On power-on each set of
hardware called out its revision and each processor set its table
pointer accordingly.

Each function was branchy because every test had an error handler
(which turned out to be 90% of the work).

Most of my embedded stuff seems to run around 4K lines, often less
(except for that 16-bit sine routine that was, um, 128 kbytes long. I
.nlisted that part.) Somewhere around 10K lines or so, flat assembly
programs (and their paper listings) start to get unweildy.

I don't like functions longer than a few pages (perhaps five 9pt.
pages). ...and often one of those is header material describing the
function, it's inputs and outputs, assumptions, and errors handled.

Lately most of our assembly progs have one or more Xilinx fpga config
tables built into the rom image, so the uP can boot the fpga's. We
wrote a rom builder program, sort of a primitive linker, to build
images out of S28 code and .RBT fpga config files. Dumb but works.

I put them in separate ROMs on my last project. It made things easier
and cost was no object.

So, off to bed, with a listing.

Don't get any paper cuts.

 

[John Woodgate]

I read in sci.electronics.design that Keith Williams <[email protected]>

Everyone knows that no matter what the question, the
answer is 'C'.

What is the circuit symbol for an inductor?

 

[John Larkin]

[...]
That's a lot of trouble to avoid a couple of GOTOs. I never understood
the anti-GOTO religion.

Someone said that GOTOs were a bad thing and everyone believed him.

I feel that GOTO can be valid in a certain circumstances.

Such as GOTO <special exit point>.

However people will abuse anything they are offered, so
GOTO <valid local jump>
gets used a
GOTO <any place I damn well please anywhere in the entire program>

Given the scope for appalling abuse, it might be wise to recommend very
sparing usage.

I heard of a guy who's immediate boss (the company boss's son) thought all
code should use GOTO almost entirely, and tried to force everyone else to do
so.

I prefer very flat programs controlled by conditional GOTOs (or JMPs,
in assembly) that operate as state machines. After all, not many
computers have curly brackets in their native instruction sets. What
language you use, and how you use it, just depends on how you think.

I prefer to use CASE like statements to implement state machines. The
PL/I Select/when fit me like a glove here. VHDL's CASE is not quite as
powerful, but makes very readable state machines. If it's done right
the implementation of the state machine can be determined at
compile/synthesis time, rather than during design.

Sure. CASE is just a list of GOTOs.

John

 

[Keith Williams]

I read in sci.electronics.design that Keith Williams <[email protected]>


What is the circuit symbol for an inductor?

What's the problem? indu-C-tor ;-)

If it can't be done in 'C', it's not worth doing. ;-)

 

[John Larkin]

I put them in separate ROMs on my last project. It made things easier
and cost was no object.

We like being able to send a customer a single plugin eprom chip that
upgrades the firmware and all the fpga's on the board at once.
Configuration control is easier, too, when the firmware and fpga
configs are bound in a single release... it's impossible for them to
ever get mismatched.


John