Programming for Electronics Engineers

[Keith Williams]

On Tue, 18 Jan 2005 02:45:25 GMT, "Kryten"

[...]
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.

Ok, you can say that about any HLL construct then. The abstraction
reduces errors.

 

[Keith Williams]

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.

Sure, it depends on the needs. In my case the FPGA configurations were
in flash (well, one was) and downloaded from disk.

 

[John Larkin]

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

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

The original design of C was too timid. Insteading of minimizing
keywords, K&R should have been bold and eliminated them entirely,
creating a language based entirely on punctuation marks. And the math
operations should have been external subroutines like everything else.

John

 

[John Larkin]

Ok, you can say that about any HLL construct then. The abstraction
reduces errors.

Up to a point. The FBI just dumped a database project after spending
$170 million. The UK public health service is having a similar
experience, I think. Windows has had thousands of security holes and
tens of thousands of bugs. My best customer is a maker of megabuck
analytical instruments, with a heavily C++ loaded processing
component. They issue a weekly bug list averaging 5-10 new bugs; I
read it to find the ones related to my equipment (they always blame me
first, and they've been wrong every time so far.) One of their senior
researchers describes their software as "spinning out of control."

We live in the dark ages of programming.

John

 

[Ken Smith]

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

No, its "Use a PIC"

Also a language for engineers should also implement run time checking
without a lot of extra work. 'C' doesn't do this at all.

No-one has mensioned IDL, so I will.

 

[Thaas]

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


What is the circuit symbol for an inductor?

|
C|
C|
C|
|
(created by AACircuit v1.28.4 beta 13/12/04 www.tech-chat.de)

See?

 

[Ken Smith]

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[/QUOTE]

Do you mean that it isn't obvious from the source code that it works right
for all non-zero results. If the answer would be zero, it fails on a
divide by zero. If not it gives the right answer.

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.

'p' or 'q' can be zero but not both. If both are zero, the answer should
be zero but the code fails. For zero inputs, I can work out the answer in
my head so this limitation of the routine is not an issue unless we are
turning it into a function to be called.

Really we should have made a function to ask for the values since we do it
more than once.

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

Yes that and debating over silly issues while ignoring the real problem
that no-one has really written a good language for engineers. All the
existing ones have major short comings.

 

[Ken Smith]

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.

Well, isn't obvious that it is always the case that the user did something
wrong. They either entered bad values or they ran a program that crashes,
both of which are their fault.


All seriousness aside:
I was more interested in showing the style and flavour of Pascal than the
details of a program. I used a useful program as an example because it is
often easier to grasp things with real examples.

 

[Ken Smith]

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.

A good argument can be made for making the CALL instruction conditional.


Some DSP and RISC machines have a conditional skip the next instruction,
but if you combine it with a call, you still get one following instruction
before the call happens.

 

[John Woodgate]

I read in sci.electronics.design that John Larkin <jjSNIPlarkin@highTHIS
landPLEASEtechnology.XXX> wrote (in <upequ0lksp28fvijfiu83d98g77vrtaq5p@
4ax.com>) about 'Programming for Electronics Engineers', on Tue, 18 Jan
2005:

We live in the dark ages of programming.

Can we find a Venerable Bede, then?

 

[Ken Smith]

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

Pascal has a GOTO.

Borland added CONTINUE and BREAK.

 

[Ken Smith]

He also harps about GOTO. But he hasn't broken me of that... I just
use labels ;-)

Just make a JimThompson.h:

#define Do
#define what
#define it goto
#define says
#define at

 

[Spehro Pefhany]

Up to a point. The FBI just dumped a database project after spending
$170 million. The UK public health service is having a similar
experience, I think. Windows has had thousands of security holes and
tens of thousands of bugs. My best customer is a maker of megabuck
analytical instruments, with a heavily C++ loaded processing
component. They issue a weekly bug list averaging 5-10 new bugs; I
read it to find the ones related to my equipment (they always blame me
first, and they've been wrong every time so far.) One of their senior
researchers describes their software as "spinning out of control."

We live in the dark ages of programming.

John

Ah, don't be such a gloomy Gus.

It's amazing what is possible to cob together using other peoples'
work these days. Like that fellow here who made up (and gave away) a
gerber->pdf converter and only had to write something like 1,000 lines
of code (my estimate). But I imagine most of the work is understanding
and wrestling with APIs rather than the actual work itself.

But for mission-critical stuff, I like to see the bare metal, or at
most one layer above (such as C).


Best regards,
Spehro Pefhany

 

[John Larkin]

A good argument can be made for making the CALL instruction conditional.

The only CPU I ever designed had this. It had a total of four
instructions, as I recall. It was all MSI TTL with a hardware stack
and a 20 khz 4-phase clock. The follies of youth!

Some DSP and RISC machines have a conditional skip the next instruction,
but if you combine it with a call, you still get one following instruction
before the call happens.

The PDP-8 had a conditional skip. I suppose it was a RISC machine,
since it wasn't microcoded and did everything in one clock. I think
the low-end PICs are really PDP-8's.

The microcode for the PDP11/05 had ops thet were, essentially,
"conditional OR to the program counter." Imagine programming that!

John

 

[Keith Williams]

Up to a point. The FBI just dumped a database project after spending
$170 million. The UK public health service is having a similar
experience, I think.

FWIG, these problems had nothing to do with programming bugs, rather
management incompetence.

Windows has had thousands of security holes and
tens of thousands of bugs.

You can't blame M$'s "issues" on construct abstraction. It may be
possible to blame some of it on the lack of any runtime checking in
C(++), but I dont' see how you're going to pin these problems on any
language abstraction... Piss-poor programming, yes. Poor language
choice, perhaps.

My best customer is a maker of megabuck
analytical instruments, with a heavily C++ loaded processing
component. They issue a weekly bug list averaging 5-10 new bugs; I
read it to find the ones related to my equipment (they always blame me
first, and they've been wrong every time so far.) One of their senior
researchers describes their software as "spinning out of control."

*They* likely are out of control. It doesn't have to be this way, even
with 'C', though it seems that 'C' encourrages sloppy work.

We live in the dark ages of programming.

We live in the dark ages of management.

 

[Ken Smith]

The PDP-8 had a conditional skip. I suppose it was a RISC machine,

That was the only type of conditional it had.

since it wasn't microcoded and did everything in one clock.

This is not true. The master clock was divided down to make a sequence of
timing pulses. The PDP-8S (I think it was) took something like 24 clock
cycles per instruction becasue some of its workings were serial in nature.

I think
the low-end PICs are really PDP-8's.

Not really because the PIC is 8 not 12 bits.

The microcode for the PDP11/05 had ops thet were, essentially,
"conditional OR to the program counter." Imagine programming that!

The PDP 12 was much nicer. You could switch its instruction set from LINK
to PDP-8 and back. This made for some interesting coding since the two
machines were very different.

 

[Keith Williams]

No, its "Use a PIC"

;-) ...and program it in 'C'? The truth is that a microcontroller is
often the best tool in the box.

Also a language for engineers should also implement run time checking
without a lot of extra work. 'C' doesn't do this at all.

I tend to agree, though many think it's a waste of time (see: M$).
This is one of the reasons I prefer VHDL over Verilog.

No-one has mensioned IDL, so I will.

Pointer?

 

[Keith Williams]

The original design of C was too timid. Insteading of minimizing
keywords, K&R should have been bold and eliminated them entirely,
creating a language based entirely on punctuation marks.

I *hate* the punctuation marks C uses now! I much prefer begin/end to
{}. It's easier for my eyes to find words.

And the math operations should have been external subroutines like
everything else.

That would make overloading the functions easier, but do you really
want M$ to overload '/' like Intel did? ;-)

 

[John Larkin]

That was the only type of conditional it had.


This is not true. The master clock was divided down to make a sequence of
timing pulses. The PDP-8S (I think it was) took something like 24 clock
cycles per instruction becasue some of its workings were serial in nature.

Well, that was the serial version, which was pretty rare. The PDP-8I,
the first TTL version (previous iron was discrete transistor modules)
used a single clock for most ops, and used a bunch of delay lines to
give some staged clock edges per instruction... is that still RISC?
This was the glory days of asynchronous logic. The first PDP-11 was
all MSI (something like 550 cans, I counted) and still not microcoded,
and was full of RC delays and stuff... buggy as hell. There was a
papertape circulating, maybe a foot long, that would lock up the CPU
if loaded; only a power cycle would unlock it.

John

 

[Keith Williams]

That was the only type of conditional it had.


This is not true. The master clock was divided down to make a sequence of
timing pulses. The PDP-8S (I think it was) took something like 24 clock
cycles per instruction becasue some of its workings were serial in nature.

IIRC the PDP-8E had a serial ALU, so single-cycle ops would be a rather
rather difficult design point.