Re: Programming for Electronics Engineers

From: Keith Williams (krw_at_att.bizzzz)
Date: 01/21/05 

Date: Fri, 21 Jan 2005 14:50:13 -0500

In article <goae86b5f0h9.1p69nwcabtf01.dlg@40tude.net>,
stephensyomamadigital@earthlink.net says...
> On Fri, 21 Jan 2005 12:14:50 -0500, Keith Williams wrote:
>
> > In article <1279u03gtecpr.1ghqmpe08o4gx.dlg@40tude.net>,
> > stephensyomamadigital@earthlink.net says...
> >> On Thu, 20 Jan 2005 21:37:32 -0500, keith wrote:
> >>
> >>> On Thu, 20 Jan 2005 10:12:55 -0800, John Larkin wrote:
> >>>
> >>>> On Wed, 19 Jan 2005 21:53:42 -0500, keith <krw@att.bizzzz> wrote:
> >>>>
> >>>>>> No, it would be more proper to have all math operations be declared
> >>>>>> external subroutines:
> >>>>>>
> >>>>>> Div_Int_By_Float(*var1,*var2)
> >>>>>
> >>>>>...and you like 'C' because it uses punctuation marks instead of keywords?
> >>>>><shudder>
> >>>>>>
> >>>>
> >>>> I despise C and 99% of C programs. I'd just like the language carried
> >>>> to its logical conclusion, all punctuation and no internal operations
> >>>> at all. Even the variable space and the stack should be external. So
> >>>> to do a divide, one should properly say
> >>>>
> >>>> Div_Int_By_Float(*varspace, *stack, *var1, *var2)
> >>>
> >>> That's going to make formulas real cute to read. ...besides the fact that
> >>> a divide should be a function, not proceedure (returns a single value).
> >>>
> >>> Though I do have to admit your suggestion would kill the language, and
> >>> that would be a good thing.
> >>>
> >>>
> >>>> Functions then don't have an associated type, or return a value, since
> >>>> there's nowhere in this language (C--) to return them to.
> >>>
> >>> Umm, you described a proceedure, not function. Not only that, but your
> >>> proceedure would have to assume a type for data, since it's not specified
> >>> anywhere in your API. Operators and overloads are far more elegant and
> >>> safer than passing by reference. Ick!
> >>
> >> I'll probably regret this, but since you guys are so adamant in your
> >> dislike of 'C', what would you recommend as a replacement? N.B. if you
> >> amswer Visual Basic, I'm writing you out of the will.
> >
> > Me? The last time I used BASIC was some 20 years ago when Tektronix
> > had a very nice version in their Signal Processing Systems (built-in
> > FFT, RFFT, Convolution, Correlation, etc.). As far as programming
> > languages go (thus ignoring VHDL), I much preferred PL/I and thought
> > Pascal was tolerable (other than its lack of I/O). Pretty much all the
> > programming I've done in the past 20 years has been in assembler. I'm
> > a hardware type and most of the programming I do is bit-banging on the
> > metal, thus the choice of assembler.
> >
> I agree with you in principle, but Lordy, 'C' has saved me thousands of
> hours of effort doing loops, conditionals, string manipulation etc. over
> straight assembler.

I don't see these things (with the possible exception of strings) as
being all that difficult in assembler. One tends to do things the same
way each time. When I was doing a lot of MASM I had a toolbox of
macros for strings (and other similar functions) when I had to go
there. The big difference between assembler and HLLs that I could see
was in the eye-candy and computations. I didn't see any advantage for
bit-banging. IMO, assembler is much clearer here.
>
> > I've also mentioned that I've used Excel (the only product from M$ that
> > has a reason to live) for some rather interesting things too. There's
> > more power in there than most realize.
>
> Care to elaborate?

I've used it for a lot of things, from the normal spread*** sorts of
things, to logic simulation and demonstration, to some fairly complex
functions. Someone once wanted a demonstration of ECC, so I coded up
and example (using an SDRAM interface as an example) in a few minutes.
We've done simulations of asynchronous logic with a spread***. Get
one black-box done and block-copy multiple levels. Change a bit and
see the result.

Then there are the obvious spread*** type functions. Last year I had
to capture logic verification patterns to be used as input to a circuit
simulator. To do this I had to track the entity declarations of the
circuit's black-box back through several levels of hierarchy to the
signals driving them and generate pin-lists for the capture software.
Formatting the pinlists was a freebie (do it once and copy/paste) once
the signals were traced. As another freebie I output the pinlists for
the waveform viewing tool so we could see what patterns we were
capturing. Not any great shakes here, but all the formatting was
essentially free.

There are also functions buried in there that are quite useful to an
engineer (e.g. FFT). 

-- 
  Keith