comp.lang.ada
 help / color / mirror / Atom feed
From: claveman@cod.nosc.mil (Charles H. Sampson)
Subject: Re: Code Generation Question
Date: 19 Mar 2001 18:25:15 GMT
Date: 2001-03-19T18:25:15+00:00	[thread overview]
Message-ID: <995iub$3e0$1@newpoisson.nosc.mil> (raw)
In-Reply-To: 98ug7e$9oj$1@newpoisson.nosc.mil

     So far I've gotten a number of responses and it looks like my at-
tempt to give some background was more misleading than helpful.  What I
was driving for was my question about compilers.  Does any known com-
piler, current or obsolete, have the capabilities needed to get around
this problem?

     I'm interested in this question because I might be able to influ-
ence the design of the next generation of this board if I can come up
with a strong enough argument that it's an idiot implementation.  An ar-
gument that the board can only be accessed in assembly code--in this day
of high-level languages--sounds like a strong argument to me, although
I'm not sure it would impress the hardware designer.

     Most of the suggestions for working around the problem we've al-
ready done, except for writing a machine code insertion.  We don't want
to do that because of its impact on portability.

     One responder claimed that we might as well bite the bullet because
working with this board is inherently non-portable.  That's not the term
I would use.  I call such code board-specific.  What I mean by that is
that it is targeting a specific piece of hardware and I recognize that
if we change that piece of hardware, to a replacement that gives the
same functionality, then our code would likely have to change.  However,
I think that I have a right to expect to access this board (in Ada) in a
manner that is independent of compiler and operating system.  This is
what I mean by portability.  Writing machine code doesn't work because
it's compiler-dependent.

                    Charlie

In article <98ug7e$9oj$1@newpoisson.nosc.mil>,
Charles H. Sampson <me> wrote:
>     This is not strictly an Ada issue but, since this group has one of
>the best signal to noise ratios in USENET, I'll post it here anyhow.  In
>my defense, it did arise in an Ada project that I'm currently working
>on.
>
>     Our project uses a heavily populated VME rack with a PowerPC as the
>CPU.  I certainly don't understand all of the VME arcania but it seems
>obvious to me that VME is at its root byte oriented.  One of the cards
>in the rack requires 16-bit reads and writes to its memory.  If you at-
>tempt an 8-bit read or write there is no indication of error; instead
>the board silently zeros the other byte of the 16-bit word.
>
>     This causes quite a bit of problem, as you might guess when you re-
>flect on it for a minute.  Whenever the module is modified (fortunately,
>it's now pretty stable), we have to investigate the code generated by
>the compiler to verify that there are no byte reads or writes to the
>board's memory.  If there are, we have to figure out a way to trick the
>compiler into not doing it.
>
>     I consider this wildly unreasonable.  My question is this: Are
>there compilers, for any language, that give the user the ability to
>subset the hardware instruction set used for a compilation?  I don't
>know of any and I've had experience with 20-30 compilers in my career.
>Other people, particularly those in academic settings, might have seen
>many more.
--
******

     For an email response, my user name is "csampson" and my host
is "csc.com".



  parent reply	other threads:[~2001-03-19 18:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-17  1:55 Code Generation Question Charles H. Sampson
2001-03-17  7:39 ` Simon Wright
2001-03-17 11:16 ` Florian Weimer
2001-03-17 12:36   ` David Kristola
2001-03-17 11:54 ` Jeff Creem
2001-03-17 15:00 ` DuckE
2001-03-19 16:10 ` Brian Orpin
2001-03-19 18:25 ` Charles H. Sampson [this message]
2001-03-19 18:49   ` Charles H. Sampson
2001-03-20  9:23     ` Stuart Palin
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox