Programming for Electronics Engineers

[Winfield Hill]

James Meyer wrote...

Winfield Hill wrote:

Did you manually change my "cow-orkers" to "co-workers"? Or did your
mail-reader do it for you? If you could see the nimnals I have to work
with, you'd know why they're cow-orkers instead of co-workers.

Guilty as charged... I thought it was a mis-type. I have a compulsion
to fix spelling errors - if I see them that is; I have some difficulty
seeing fine fonts on my 1600x1200 LCD display. Having lots of pixels
is nice, but they sure are small. Plus, using a digital video cable
means the font lines are no longer slightly spread out, but now occupy
exactly one tiny pixel. Sheesh, one step forward, two steps back.

 

[Ken Smith]

In what way does FORTH "outperfrom" C/C++? Time to market or processing
speed? Both are obviously important, but I can't imagine FORTH winning
the latter.

FORTH should be about as fast a C++ if you use polymorphic objects. The
virtual method dispatching in object oriented code is about the same as a
"compiled" FORTH's routine jumps.

"Compiled" FORTH isn't as "compiled" as compiled C++. The FORTH version
is a bunch of calls to routines that would normally be part of the FORTH
engine. As a result, for straight line code that doesn't use any objects,
C++ should do better. Whether it does depends a lot on the programmers
involved and a little on the compilers.

 

[John Larkin]

I never use graphics.

Oh. I love graphics; it gives me a feel for the dynamics of a
situation. Active graphics, things that move and fade, are especially
fun.

Right now I'm simulating the formation of an arbitrary waveform by
adding a train of Gaussian impulses spaced 250 ps apart, with the
amplitude of each glitch programmable with a dac. It's an interesting
approach to curve-fitting, and has some remarkable sensitivities to
imperfect glitch spacing and widths, stuff you have to *see* to get a
good feel for. Next step is to close a servo loop on the glitch
amplitudes and see how close they can be made to match a target
waveform.

John

 

[Guy Macon]

"Compiled" FORTH isn't as "compiled" as compiled C++. The FORTH version
is a bunch of calls to routines that would normally be part of the FORTH
engine. As a result, for straight line code that doesn't use any objects,
C++ should do better. Whether it does depends a lot on the programmers
involved and a little on the compilers.

There are significant variations in Forth implementations that make
it so that the above is usually but not always true. That being said,
if processing speed is important and you are using a Windows PC,
PowerBASIC generally outspeeds C/C++. On small microcontrollers,
C/C++ typically requires more resources than Forth.

There is, however, a much larger factor to be considered; as we all
know, picking a different algorithm has a much larger effect than
picking a different programming language. Different languages tend
to lead you into using different algorithms. C/C++ is especially
suited for (to pick an example) writing an operating system. Forth
is epecially suited for very small embedded systems.

As far as time to market goes, an experienced PowerBASIC or Forth
programmer will typically finish a PC application in a fraction of
the time that a C/C++ programmer can, but there are many apps where
the opposite is true.

But I digress; we aren't talking about an experienced programmer
but rather an Electronics Engineer, and *for an EE*, my advice
remains the same:

For the EE who also wishes to be a Linux guru, GCC/ANSI C++

For the EE who wishes to program small/cheap 8-bit chips, Assemby.

For the EE who wishes to program small/cheap 8-bit chips and wishes
to be able to outperform coworkers who are using assembly, Forth.

For the EE who uses Windows and just wants to be able to write
fast, bug-free programs to do calculations and access the PC
hardware for data aquisition, etc, PowerBASIC Console Compiler.

Same as above but DOS user, PowerBASIC for DOS.

 

[James Meyer]

In what way does FORTH "outperfrom" C/C++? Time to market or processing
speed? Both are obviously important, but I can't imagine FORTH winning
the latter.

If you want speed in a C++ program for certain procedures or functions,
you often need to drop back to a hand optimized assembler routine. FORTH not
only allows that but even makes it easy. FORTH is interpreted when it can be,
usually during development, but after things are working, FORTH is usually
compiled into code that is often smaller and faster than assembly language.

Jim

 

[Joel Kolstad]

If you want speed in a C++ program for certain procedures or functions,
you often need to drop back to a hand optimized assembler routine.

An 'intermediate' approach with GCC (and I'd assume some other fancy C
compiler, but I don't know) is where you use 'virtual' registers in the
assembly code, and this allows the compiler and optimizer to still perform
register allocation and hence avoid the traditional performance problem
where any hand-written assembly code meant for C interfacing starts off
PUSHing all the registers it's intending to use onto the stack.

I think Microsoft did a lot of things the 'right way' with their COM
(component object model) architecture: Anything written to the specification
can be used by any old program regardless of what languages the COM object
and the application program happen to be running it; it's very common to
have Visual BASIC programs using COM objects written in C/C++, and is
trivial to implement vs. the old 'DLL' method.

Heck, even the Linux people like COM!

---Joel Kolstad

 

[Guy Macon]

Heck, even the Linux people like COM!

That would only be fair, because Microsoft sure does seem to like Linux!
See [ http://www.aaxnet.com/editor/edit033.html ]

 

[Paul Burke]

Aha, two Forth fans!

Forth has been around for over 25 years now, and as one who was very
keen on it in the early days- I saw it as a sort of MSI language, a bit
like the more complex TTL as aginst simple gates- I think its day has
long passed. In fact Forth any_good if people_using_it more then. It's
just too easy to crash when you have to do your own stack shunting. I
don't think C is perfect, but it's widely available, and it does the
job, even for 2k/128 byte targets, and it's got the low level dangerous
things that allows people who know what they are doing to get on with it.

Paul Burke

 

[Keith Wootten]

Three.

Plus Jerry Avins, who (unfortunately) only posts
here occasionally.

Five, then.

Cheers

 

[Keith Wootten]

Forth has been around for over 25 years now, and as one who was very
keen on it in the early days- I saw it as a sort of MSI language, a bit
like the more complex TTL as aginst simple gates- I think its day has
long passed. In fact Forth any_good if people_using_it more then. It's
just too easy to crash when you have to do your own stack shunting.

For embedded work, that's a good thing. Get all the bugs out before
release. In practice, stack balancing becomes second nature.

Forth on a stack machine is a thing of beauty. Very fast, and
deterministic. Interrupt latency is very small - there's nothing to
stack, it's already there!

The obsolete RTX2000 was a very, very nice part and at 10MHz would
outperform anything else I've come across with similar clock speed. The
Ignite1 is astonishingly rapid (www.ptsc.com) but is owned by a bunch of
suits. There are several FPGA stack machine implementations which look
very interesting.

C works as a reasonable assembler, but whoever thought up the use of =
and == should be shot. Slowly. I also dislike the stupid typing rules
which seem to exist so that the compiler can tell you that you've broken
them, and why can't I use any goddam character I want in a function or
other name. The pointer syntax seems to deliberately obfuscate a simple
concept.

I don't think C is perfect, but it's widely available, and it does the
job, even for 2k/128 byte targets, and it's got the low level dangerous
things that allows people who know what they are doing to get on with it.

Paul Burke

I have to use it sometimes too, but I'd be kicking and screaming at the
thought of 2KiB/128B work in C or Forth for that matter. For small PICs
I use my own assembler which allows Forth-like naming flexibility and
looping/branching constructs without trying to force a data stack onto
the poor thing and which runs under Win32Forth.

Cheers

 

[Ken Smith]

C works as a reasonable assembler, but whoever thought up the use of =
and == should be shot. Slowly.

Fortunately most C compilers check for the common mistakes on this. It
really is dumb though. Pascal's := for assignment is a little better.

I also dislike the stupid typing rules
which seem to exist so that the compiler can tell you that you've broken
them,

That is exactly what the type rules are for. Compile time type checking
is a very good idea but adding them to pointer heavy C makes things a bit
of a mess. Now in C++ we have both pointers and references so we can get
even more confused.

and why can't I use any goddam character I want in a function or
other name.

They allow 32 characters in names. If they limitted you to only using the
letter "0" and the digit "0" in names, you'd still be able to define over
4 billion of them.

The pointer syntax seems to deliberately obfuscate a simple
concept.

No, K&R were smart enough that if they had deliberately obfuscated them
things would be worse.