"DoD designed Ada specifically so that code written in Ada would be
completely portable between processors and operating systems, yet they are
advertising through you as if Ada experience on one platform were not
transferable to other platforms."

oh dear, perhaps it is time to post my "Ada myths" again. First of all
DoD did not design Ada! Second, the designers of Ada certainly did not
design Ada so that all code written in Ada is automatically portable.
There are lots of ways to write non-portable code in Ada, and that's
a god thing, because lots of problems require the ability to write
highly target specific codee.

What Ada does is facilitate a style of programming in which the
non-portable code is isolated, and reusability is maximized. Ada
is by no means unique in its ability to allow the writing of
portable code (I have written portable code in fortran and COBOL
successfully for a long time), but it makes it easier.

As for the ad, it is perfectly reasonable to want specific knowledge of
either the host or target system. For the host system, the specific
knowledge that may be of use is the implementation dependent aspects
of an implementation (e.g. special pragmas, or special packages, like
Startlet on VMS), and tools, like library managers etc.

For the target system, if you are doing low level stuff, or interfacing
directly to the operating system or hardware, it may well be an advantage to
be very familiar with the target system.

Nothing I can see to criticize here!

-Bob

: You could have infinite wisdom of the Ada language, but it is of little
: use if you can't logon to the host system and invoke an editor to write
: some code, and many, many, applications are highly target specific.

I'd say that many many more applications are highly target specific
than ought to be.  I have yet to be exposed to an embedded system
where, say, more than 10% of the code had to be target/CPU-specific
Yet, people often write code this way, and often hire this way.
Perhaps it's a side-effect of the heavy influence of hardware
design on embedded systems, where software is seen as a blob sitting
on top of all this cool hardware.  With a decent software architecture,
most of that hardware dependence can be abstracted away.  Yes, it
does require someone with deep knowledge of the hardware to create
that abstraction; my fear is that too often people with that
detailed hardware knowledge know little about software design,
abstraction, etc.

[Caveat: I haven't been involved in DSP-related development, but
I'd be surprised if a decent SW architecture couldn't reduce the
target-dependence significantly as well.]

Can you give an example of an application where the _application_
code needs to be target specific?   Not the device drivers or
kernel, but the application?

Tony

The need for knowledge of 80486 processor is important when it comes to
debugging and making an embedded system work.  A good S/W engineer can
identify the compiler's or their own bugs by backtracing instruction
execution from where a exception is raised.  We can't always live in a
completely source level de{*filter*} yet!  Most embedded system software
engineers end up getting down and dirty with the hardware when they are
making the system work and stretching the limits of the power/thruput
performance envelope.
___________________________________________________________________________
Robert S. White                    -- an embedded systems software engineer

---------------------------------------------------------------------------

I would have to make similar trade-offs when it comes to memory usage
(availability) vs processing time.  For example, our application is not
too memory bound, but we have some very stiff timing requirements, so
we implemented a conversion routine of a six{*filter*} bit resolver input by
using the raw value input as an index into an array of floating point pre-
computed values. This was possible only because we had sufficient memory,
as the array consumes a large block of memory, and if the timing wasn't
so critical (we're implementing a 40 Khz servo loop) I wouldn't have
performed the conversion in that manner.  Again, I have to have intimate
knowledge of the processor and its architecture to make a software design
decision to implement the data conversion routine by either 1) taking the
raw data value and converting it to a float value, scaling it by performing
a multiply, and bias it with an add, or 2) use the raw data value as an
index into a large array of pre-computed values to be returned.

As for things like device drivers, interfaces, kernels, etc.  I find that
the majority of the code I write probably falls into these categories.
But this might be a bit of a biased view since I do mostly embedded
applications, generally without the benefit (hinderance?) of an operating
system.  For example, I wrote a lot of lines of code to implement
a generic interface and several generic applications for the DMA coprocessor
of the C40, certainly more code to provide the DMA services than all
the lines of code to instantiate and use the services in the application
specific parts.

-Bob

: >
: > : You could have infinite wisdom of the Ada language, but it is of little
: > : use if you can't logon to the host system and invoke an editor to write
: > : some code, and many, many, applications are highly target specific.
: >
: > I'd say that many many more applications are highly target specific
: > than ought to be.  I have yet to be exposed to an embedded system
: > where, say, more than 10% of the code had to be target/CPU-specific
: > Yet, people often write code this way, and often hire this way.
: > Perhaps it's a side-effect of the heavy influence of hardware
: > design on embedded systems, where software is seen as a blob sitting
: > on top of all this cool hardware.  With a decent software architecture,
: > most of that hardware dependence can be abstracted away.  Yes, it
: > does require someone with deep knowledge of the hardware to create
: > that abstraction; my fear is that too often people with that
: > detailed hardware knowledge know little about software design,
: > abstraction, etc.
: >
: > Can you give an example of an application where the _application_
: > code needs to be target specific?   Not the device drivers or
: > kernel, but the application?

: I do mostly embedded applications.  I am currently writting Ada code
: that runs on TI's C40 processor (eight of them) that control a FLIR/
: TV sensor system for the Comanche helicopter.  The fact that we are
: using a C40 target has a very large impact on the overall design of
: the software.  The C40 offers a lot of performance, but only if you
: are careful in the way you design your code so that you can take
: advantage of its features (e.g. extensive DMA capability including
: the ability to use the DMA coprocessor to perform I/O over the six
: available serial communication ports, or to respond to interrupts).

DMA I/O can be entirely hidden under a communication layer, no?
(But I see in your later comment that you did just that...)

: If I didn't have the ability to use a DMA coprocessor to move data
: through the system and over the com ports in parallel with CPU
: processing, I probably would have structured my software design
: differently.

Excellent point.  

: Since timing is critical, I would have to evaluate
: whether I have a bottle neck performing I/O or performing data
: processing. I might consider a design that allows for less data
: movement by performing more processing to compact the data should
: I be bound by the I/O, or I might just pass larger volumes of raw
: data through the system if I were to be processing bound.  I must
: have intimate knowledge of the processor and the surrounding
: architecture before I can make these decisions that may greatly
: influence my overall software design.

: I would have to make similar trade-offs when it comes to memory usage
: (availability) vs processing time.  For example, our application is not
: too memory bound, but we have some very stiff timing requirements, so
: we implemented a conversion routine of a six{*filter*} bit resolver input by
: using the raw value input as an index into an array of floating point pre-
: computed values.

I don't really consider this to be target-dependent.  You have an
implementation that has particular performance characteristics, and it
would have those characteristics regardless of the underlying
hardware.

: This was possible only because we had sufficient memory,
: as the array consumes a large block of memory, and if the timing wasn't
: so critical (we're implementing a 40 Khz servo loop) I wouldn't have
: performed the conversion in that manner.  Again, I have to have intimate
: knowledge of the processor and its architecture to make a software design
: decision to implement the data conversion routine by either 1) taking the
: raw data value and converting it to a float value, scaling it by performing
: a multiply, and bias it with an add, or 2) use the raw data value as an
: index into a large array of pre-computed values to be returned.

: As for things like device drivers, interfaces, kernels, etc.  I find that
: the majority of the code I write probably falls into these categories.

Do most of the people on your project also write device drivers?

: But this might be a bit of a biased view since I do mostly embedded
: applications, generally without the benefit (hinderance?) of an operating
: system.  For example, I wrote a lot of lines of code to implement
: a generic interface and several generic applications for the DMA coprocessor
: of the C40, certainly more code to provide the DMA services than all
: the lines of code to instantiate and use the services in the application
: specific parts.

Well... I'm not surprised that the instantiation/use of the services
is smaller than the service implementation -- you've done your job
well if that's the case ;-)   I'm more interested in the size of
the application-specific parts vs. the size of the target-specific
parts.

Thanks for the detailed description of a highly target-specific application.

Perhaps it is wise, during development, to identify _design_ decisions
that are target dependent INDEPENDENT OF coding decisions that are
target dependent (e.g. device drivers).   Let's call this first kind of
target dependence "loose" : code that should run, albeit without
required performance, on any machine.

The portions of the system that are "loosely" target-dependent can
still be developed and tested for correctness on the host, _if_ they
are kept free of device and architecture-specific code (perhaps
sitting on top of a target-dependent layer).  This is probably what
all good engineers do anyway, but maybe not consciously ;-)

Regards,