comp.lang.ada
 help / color / mirror / Atom feed
From: anon@att.net
Subject: Re: Using representation clauses in networking software
Date: Mon, 16 Aug 2010 09:12:55 +0000 (UTC)
Date: 2010-08-16T09:12:55+00:00	[thread overview]
Message-ID: <i4avel$pvb$1@news.ett.com.ua> (raw)
In-Reply-To: 8739ugqfeb.fsf@mid.deneb.enyo.de

In <8739ugqfeb.fsf@mid.deneb.enyo.de>, Florian Weimer <fw@deneb.enyo.de> writes:
>Have there been any efforts to fix representation clauses so that they
>are suitable for expressing elements commonly found in networking
>protocols?
>
>My understanding is that representation clauses are totally unsuitable
>for this purpose because they do not allow the programmer to express
>endianness.  I dimly recall a technical report which argued that
>expressing endianness portably was impossible.  However, Erlang's bit
>syntax seems to be a counterexample, so I wonder if that issue has
>been picked up in recent years.

  The representation clauses be used in endianness but it is a little 
  tricky the first time. After that it is easy to do. And it does not 
  matter if you using little or big endian Ada using the representation 
  clauses can handle them as is. So, no modications is needed.

  And one of the first uses of the enumeration representation clause was 
  to aid in converting programs files written in IBM EBCDIC character set 
  into ASCII set back in the mid 1980s using Ada 83.

--------
> So why were representation clauses added to Ada in the first place?

  First, to be able to assign internal values to enumeration value such 
  as the character set (see Standard package) or

    "type Boolean is ( False, True ) ;"  

  In most C compiler today False has an internal value 0, but there are 
  C compilers like Miscrosoft that were used back in the 70 to the mid 
  90s and the compiled code is still use today that uses -1, while others 
  C compilers assigned True to 0.  The representation clause allowed an 
  Ada programmer to correct this problem without having to deal with the 
  close source or binary code. Just interface and use the representation 
  clause to match the Ada code to the external world and the program is 
  good to go.

  Second, is to set size and location of elements in a pack record. A 
  simple example is the status registers, like a UART.  Does not matter 
  what the IO port it uses the status word values and bit pattern is 
  standardize and using the representation clause with a pack record 
  can allow a programmer to use simple Boolean logic instead of dealing 
  with integer masking algorithms. In other words, let the compiler do 
  the hard work.

  The Address representation clause has 100s of uses. Like setting up 
  DOS and no-OS type of interrupts. Also can be use to calculate the 
  physical memory size for an Ada OS. 

  All of which allows Ada to translate the outside environment into 
  the Ada world.  Making the Ada program more portable and universal 
  which extents the life of the program!

--------
> Would it make sense to deprecate them?

  The answer is NO!!! And they should not be expanded! They have a 
  special place to aid the programmer in special areas. Such as insuring 
  the code is portable when dealing with others areas that are not 
  standard or in a pre-standard design! 


  An example is in writhing a keyboard driver.  Is it easier to replace 
  the keyboard layout every time a different keyboard is used and then 
  re-booting or is it better to add an additional translation package 
  using representation clause. Then allow the program to ask which layout 
  to use from the hardware or in some cases the user.





      parent reply	other threads:[~2010-08-16  9:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-15 11:33 Using representation clauses in networking software Florian Weimer
2010-08-15 13:44 ` Yannick Duchêne (Hibou57)
2010-08-15 14:32   ` Dmitry A. Kazakov
2010-08-15 14:44     ` Florian Weimer
2010-08-15 15:04       ` Dmitry A. Kazakov
2010-08-15 15:32         ` Florian Weimer
2010-08-15 16:10           ` Dmitry A. Kazakov
2010-08-15 16:40             ` Yannick Duchêne (Hibou57)
2010-08-15 17:58               ` Dmitry A. Kazakov
2010-08-15 19:11                 ` Shark8
2010-08-15 19:15                 ` Simon Wright
2010-08-15 20:25                   ` Maciej Sobczak
2010-08-15 21:24                     ` Simon Wright
2010-08-16  6:40                     ` Dmitry A. Kazakov
2010-09-04 20:46                     ` Florian Weimer
2010-08-15 15:39         ` Yannick Duchêne (Hibou57)
2010-08-15 15:31       ` Yannick Duchêne (Hibou57)
2010-08-15 15:30     ` Yannick Duchêne (Hibou57)
2010-08-15 16:10       ` Dmitry A. Kazakov
2010-08-16 10:57     ` Stephen Leake
2010-08-15 15:58 ` Simon Wright
2010-08-15 16:03   ` Florian Weimer
2010-08-17  3:32     ` Randy Brukardt
2010-08-16  9:12 ` anon [this message]
replies disabled

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