IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA 
Author Message
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA

Kent Dolan said:

"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!



Fri, 10 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA

Quote:
> Kathy:

> In misc.jobs.misc article


> > TechniSource has the following position available out of our IOWA office.

> > TECHNISOURCE REQUIREMENT NUMBER FOR REFERENCE: 9282aa
> >  Must have ADA software development experience for  80486 Intel
> >  processor with development on a VAX/VMS operating system.

> How bizarre!

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

> Perhaps your clients should learn to live by their own plans?

I don't find this the least bit bizarre.  While Ada has taken portability
issues into account in its design, and is probably one of the most portable
languages around, it does not lessen the importance of the software designers
knowledge and experience of the target architecture and host development
environment.  Virtually every job listing I've ever read lists a desire
for knowledge and experience in the language, target, and host system.
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.

-Bob



Sat, 11 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA

: 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?



Sun, 12 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA

Quote:
>Kathy:

>In misc.jobs.misc article


>[Note that your job ads don't belong in discussion newsgroup misc.jobs.misc.]

>> TechniSource has the following position available out of our IOWA office.

>> TECHNISOURCE REQUIREMENT NUMBER FOR REFERENCE: 9282aa
>>  Must have ADA software development experience for  80486 Intel
>>  processor with development on a VAX/VMS operating system.

>How bizarre!

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

Actually, this is an ad for a contract position and when a job shop
places someone on a contract that pays $42+/hr (plus the job shop's
take) they want an exact match in "skill" set.  It doesn't matter to
them that you can learn all the VMS commands you'll ever need in two
or three hours.  They want someone who can just walk in and start working.
That's how the contracting game is played.  I've still managed to pick
up unix (VADS tasking doesn't mix well with it) and X window/OSF Motif.
You see, they can't always provide the client with an exact match, so
go ahead and apply!

Tony



Sun, 12 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA


.
.
.
.

Quote:
>>  Must have ADA software development experience for  80486 Intel
>>  processor with development on a VAX/VMS operating system.

>How bizarre!

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

>Perhaps your clients should learn to live by their own plans?

I disagree.  The desire for VAX VMS experience directly relates to how
immediately productive the S/W Engineer would be in the developement
environment, esp important in for non-GUI/character based development using
DEC LSE, CMS, MMS and an Ada 83 cross-compiler.  Some existing developement
efforts are using these tools with good success.  When they want to staff
up with contract engineers, it is a plus for personnel to step into
on-going efforts with minimal re-training.  In the future when
multi-platform developement environments become popular, such as Rational's
Apex Ada developement, this type of particular knowledge will not be as
important.

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

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



Mon, 13 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA

Quote:


> : 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).
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.  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. 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



Tue, 14 Apr 1998 03:00:00 GMT  
 IA - Satellite Commun Project, sw engr exp., satellite com exp, ADA
[body of original left in since the Subject change was significant]



: >
: > : 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,



Mon, 20 Apr 1998 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Avaialable: Cobol Developer (8 yrs exp), Y2 K Programmer(2.5 yrs exp)

2. Ada rocket launches Ada satellite

3. Kirtland AFB RFP looking for satellite OS in Ada

4. US-CA-San Jose-S/W Engr., Ada, 2167A, GUI, Embedded SW-Recruiter

5. Ada/IA/Ada/IA Enough Already!

6. Clarion 5b and Satellite Forms OCX

7. Satellite forms with Clarion?

8. Clarion To Satellite Forms

9. Satellite Forms & Palm Emulator

10. Satellite Forms

11. Satellite Forms

12. she may love blunt hens among the filthy poor satellite, whilst Will tamely excuses them too

 

 
Powered by phpBB® Forum Software