Code Generation Question

Code Generation Question

[Charles H. Sampson]

     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.

                    Charlie


--
******

     For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".

Re: Code Generation Question

[Simon Wright]

claveman@cod.nosc.mil (Charles H. Sampson) writes:

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

It seems to me that if this board were a network device (for
instance), no one would expect a compiler to handle the limitations it
imposes. There are all sorts of hardware-related things you need to do
at a hardware interface, and this is just one of them. The fact that
it's memory-mapped is (IMHO) misleading you.

You could write specific word-oriented access subprograms in
assembler, perhaps. But what would you do if just _reading_ a word had
an external effect? (not sure if this is possible in a VME world).

OTOH. it would be most surprising if the compiler didn't handle
writing Interfaces.C.short as a single operation, perhaps a mapping
between your outer operations to a low-level interface in terms of
shorts would do.

  keep a main-store copy of what is (should be) in card memory, in
    a fully-represented Ada structure overlaid on an array of shorts
  the green lamp is lit by clearing bit 6 of word 12
    so type lamp_state is (on, off);
  light-the-green-lamp:
    set the green-lamp-state field in main memory to lamp_state'(on) ie 0
    write the whole of word 12 to the card

I think what you need to do in this sort of situation is to address
the actual problem not what you would like it to be. (Sorry if that
sounds po-faced, not trying to get at you)

-- 
Simon Wright                       Work Email: simon.j.wright@amsjv.com
Alenia Marconi Systems                        Voice: +44(0)23-9270-1778
Integrated Systems Division                     FAX: +44(0)23-9270-1800

Re: Code Generation Question

[Florian Weimer]

claveman@cod.nosc.mil (Charles H. Sampson) writes:

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

You might want to ask the compiler vendor to provide a pragma to force
the compiler to generate the appropriate read/write instructions.

Using machine code insertions is another possibility.

Re: Code Generation Question

[David Kristola]

On Sat, 17 Mar 2001 3:16:22 -0800, Florian Weimer wrote
(in message <87elvw4pdl.fsf@deneb.enyo.de>):

> claveman@cod.nosc.mil (Charles H. Sampson) writes:
> 
>> 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.
> 
> Using machine code insertions is another possibility.

Combine this (machine code insertions) with Jeff Creem's answer, and 
you will have (IMHO) the best solution.  Since you are working with 
picky hardware, use the power of machine code insertion to insure the 
access operations you need.  Isolate this in a package for easy 
maintenance and to help portability (since this part probably isn't 
portable anyway, but that's okay, it is isolated, and it is meant to 
work with a particular card in your PowerPC VME system).


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com

Re: Code Generation Question

[Jeff Creem]

This is very common especially in custom hardware.

In any case the best approach for anything like this is to
have a package that encapsulates all read/write access to the hardware. Once
that is setup, assuming it is complete, you will almost never be modifying
that package.

Leaving scattered access to hardware in many places is just asking for
trouble.

"Charles H. Sampson" <claveman@cod.nosc.mil> wrote in message
news:98ug7e$9oj$1@newpoisson.nosc.mil...
>      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.
>
>                     Charlie
>
>
> --
> ******
>
>      For an email response, my user name is "sampson" and my host
> is "spawar.navy.mil".

Re: Code Generation Question

[DuckE]

I have worked with one VME device that required 16 bit reads and writes, but
only returned/stored 8 bits at a time.  To make things even more difficult
the data was in the high order byte of the 16 bit word.

This device was one that was built in-house.  Apparently it was much easier
for the hardware designer to build it this way.

On an application developed using GCC on VxWorks I access 16 bit memory by
defining a pointer to a 16 bit value, assigning a memory address to the
pointer, and then accessing the memory through the pointer.

I hope this helps,

SteveD

"Charles H. Sampson" <claveman@cod.nosc.mil> wrote in message
news:98ug7e$9oj$1@newpoisson.nosc.mil...
>      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.
>
>                     Charlie
>
>
> --
> ******
>
>      For an email response, my user name is "sampson" and my host
> is "spawar.navy.mil".

Re: Code Generation Question

[Brian Orpin]

On 17 Mar 2001 01:55:58 GMT, claveman@cod.nosc.mil (Charles H. Sampson)
wrote:

>     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 function is controlled on our boards (DY4) by a chip called the
SCV64.  By changing registers in that chip you can control how the VME
transfers are conducted.

example http://www.dy4.com/Support/TechPapers.htm

HTH

-- 
Brian Orpin    BAE SYSTEMS, Edinburgh
"If you really know C++, there isn't much you can't do with it, though it may 
not always be what you intended!"  Tucker Taft 1998 

Re: Code Generation Question

[Charles H. Sampson]

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

Re: Code Generation Question

[Charles H. Sampson]

     Jim Gleason of Green Hills has just pointed out to me by email that
the Atomic pragma will probably do what I want.  I think it might be
pretty expensive for us, but I'm one of those who believe that expense
in writing long-lived code is usually irrelevant.

     So, if Atomic works I'm now in an odd position.  I'll have to argue
that the 16-but requirement is not a problem for us Ada users but that
it could be severe in other languages.

                    Charlie

--
******

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

Re: Code Generation Question

[Stuart Palin]

"Charles H. Sampson" wrote:

>      Jim Gleason of Green Hills has just pointed out to me by email that
> the Atomic pragma will probably do what I want.  I think it might be
> pretty expensive for us, but I'm one of those who believe that expense
> in writing long-lived code is usually irrelevant.
> 
>      So, if Atomic works ...
<snip>

Check deja news (or whatever it is now it has gone to Google -
http://groups.google.com/ ) for (recent) comp.lang.ada discussions on
atomic and this issue.  The discussions are relevant to your problem!

The Greenhills compiler may well do what you want when you use pragma
Atomic - but this may be (_is_) compiler specific.

--
Stuart Palin
Principal Software Engineer
BAE SYSTEMS Avionics Ltd, Rochester
G-NET 791 3364    mailto:stuart.palin@baesystems.com