Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Juergen Pfeifer]

jross wrote:
 
> My first question is how do you define and write a dispatching
> mechanism as you would in C++ using function pointers in a table for
> execution speed efficiency,  like this:
> 
> ---------------------------------
> -- the .h file
> ---------------------------------
> 
> class TACpu : public TCpu
> {
>     ? define registers and much stuff  (not shown)
> 
>     struct OpStruct  // define the op code jump table structure
>     {
>         char Byte; // the opcode byte for reference only
>         void (TACpu::*Func)();  // executes opcode
>     };
> 
>     static OpStruct OpTable[];  // the table in the .cpp file
> 
>     void Op_U();  // undefined
>     void Op_00();  // functions that execute the opcodes
>     void Op_01();
>     void Op_02();
>     void Op_03();
>     // ?  thru Op_FF
> };
> 
> ---------------------------------
> -- in the .cpp file
> ---------------------------------
> 
> TACpu::OpStruct TACpu::OpTable[] = {  // opcode table
>     { 0x00, Op_00 },
>     { 0x01, Op_01 },
>     { 0x02, Op_U  },
>     { 0x03, Op_03 },
>     // ?  thru Op_FF
> };
> 
> ... the Op_xx functions would go here
> 
> now the code for calling the opcodes
> 
>    IR = Core[PA++];  // get the opcode, advance the program address
>    (this->*OpTable[IR].Func)();   // execute it
> 
> ----------------
> 
> This is very efficient C++ code (could have been just as easy in plain
> old C without the class encapsulation?)  How would you do this in Ada
> without using a Case Statement?
> 
Ada95 allows the definition of "access to function" or "access to procedure"
types. You obviously can then use these types to build arrays of "function pointers"
or to use it in records.

I recommend Norman H. Cohens "Ada as a second language" (ISBN 0-07-011607-5). It is
an excellent Ada95 textbook for programmers coming from C/C++ or similar languages.
This would have answered your question easily.

Cheers
Juergen

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jim Rogers]

In article <38E05E84.BB5507FC@gmx.net>,
> jross wrote:
>
> My first question is how do you define and write a dispatching
> mechanism as you would in C++ using function pointers in a table for
> execution speed efficiency, like this:
>
> ---------------------------------
> -- the .h file
> ---------------------------------
>
> class TACpu : public TCpu
> {
> ? define registers and much stuff (not shown)
>
> struct OpStruct // define the op code jump table structure
> {
> char Byte; // the opcode byte for reference only
> void (TACpu::*Func)(); // executes opcode
> };
>
> static OpStruct OpTable[]; // the table in the .cpp file
>
> void Op_U(); // undefined
> void Op_00(); // functions that execute the opcodes
> void Op_01();
> void Op_02();
> void Op_03();
> // ? thru Op_FF
> };
>
> ---------------------------------
> -- in the .cpp file
> ---------------------------------
>
> TACpu::OpStruct TACpu::OpTable[] = { // opcode table
> { 0x00, Op_00 },
> { 0x01, Op_01 },
> { 0x02, Op_U },
> { 0x03, Op_03 },
> // ? thru Op_FF
> };
>
> ... the Op_xx functions would go here
>
> now the code for calling the opcodes
>
> IR = Core[PA++]; // get the opcode, advance the program address
> (this->*OpTable[IR].Func)(); // execute it
>
> ----------------
>
> This is very efficient C++ code (could have been just as easy in plain
> old C without the class encapsulation?) How would you do this in Ada
> without using a Case Statement?
>
There are some differences in the Ada approach and the C++ approach.
What you are asking is if Ada can be C++. The answer is that Ada is
only moderately good at being C++.

Some differences:
  Ada does not have an equivalent of a ++ operator.

 All your C++ functions would be implemented as Ada procedures.

 You can build a similar table of access to procedures in Ada. This
 would not be what Ada describes as a dispatching operation. Ada uses
 the term dispatching to refer to what in C++ would be calling a
 virtual function through the vtbl.

The Ada specification for the procedures and access types would look
something like:

   type Proc_Ptr is access procedure;

   type OpCode is range 16#00#..16#FF#;

   type Opcode_Table is array(OpCode) of Proc_Ptr;

   procedure Op_00;

   procedure Op_01;

   procedure Op_02;
   ...

   OpTable : Opcode_Table := (
     16#00# => Op_00'Access,
     16#02# => Op_01'Access,
     16#03# => Op_02'Access,
     ... );

  IR : OpCode;
  function Core(Item : in System.Address) return OpCode;

Now get the opcode, advance the program address, execute the opcode

  IR := Core(PA);
  PA := PA + 1;

  OpTable(IR).all;

--
Jim Rogers
Colorado Springs, Colorado USA


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Ed Falis]

I guess what I don't understand about this conversation is why noone has
proposed the use of tagged types instead of manual procedure dispatching.

- Ed

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[James S. Rogers]

Ed Falis wrote in message ...
>I guess what I don't understand about this conversation is why noone has
>proposed the use of tagged types instead of manual procedure dispatching.


Although the original author of this thread used the term dispatching, his
description of what he wants does not really want dispatching.

He wants to execute a procedure associated with a particular opcode value,
not based upon a separate type. He also did not want to use any form of
case statement to determine the procedure to execute. This rules out the
use of a discriminated record.

The approach of a manually constructed dispatching table is valid in either
C++ or Ada. The reason it is used in C++ is that he is not really using
virtual functions there either. The C++ vtable will not work for him.

Show me how you will design a hierarchy of tagged types differentiated only
by  values of discrete type. I have not yet seen that trick.

Jim Rogers

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jean-Marc Bourguet]

In article <aBfE4.2740$AW1.181200@bgtnsc05-news.ops.worldnet.att.net>,
"James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote:
> The approach of a manually constructed dispatching table is valid in
> either C++ or Ada. The reason it is used in C++ is that he is not
> really using virtual functions there either.

With what I've seen from the code, I can't tell he doesn't want virtual
functions. A pointer to member function is able to trigger what in Ada
we'd name a dispatching call.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article
<aBfE4.2740$AW1.181200@bgtnsc05-news.ops.worldnet.att.net>,
  "James S. Rogers" <jimmaureenrogers@worldnet.att.net> wrote:

> Although the original author of this thread used the term
> dispatching, his description of what he wants does not really
> want dispatching.

I disagree. Yes, he does not know to think at that abstraction
level, but it is completely appropriate to his problem.

> He wants to execute a procedure associated with a particular
> opcode value, not based upon a separate type.

But dynamic polymorphism is all about associating types with
values, and having separate types for the different opcodes
would likely give a far clearer, higher level, more abstract,
and just as efficient expression of his intent.

> He also did not want to use any form of
> case statement to determine the procedure to execute. This
> rules out the
> use of a discriminated record.

Now one can ask *why* he did not want to use a case statement,
and the answer has nothing to do with case statements, but
rather with thoughts about how they are likely implemented.

Note that access to procedures could perfectly well be
implemented using case statements, and indeed such an
implementation would be attractive in a safety critical
environment where indirect calls are not permitted at the
object level.

Equally case statements are typically implemented using indirect
jumps and may well be much more efficient than the use of
access to procedures.

> Show me how you will design a hierarchy of tagged types
> differentiated only by  values of discrete type. I have not
> yet seen that trick.

Not clear what you mean at all here. The point is to replace
the "values of discrete type" by not a hierarchy, but rather
a flat tree of subtypes.

What we have here is a classic case of confusing

  1. high level abstract design
  2. low level language solutions
  3. concern about efficiency of generated code

All three are quite valid in context, but often you find
people worrying about 3. when they should be worrying about 1.

We really can't tell what the right advice is in this situation
because all we are presented with is a low level solution and
associated (but slightly bogus) concerns with efficiency. We
really have no idea what the high level problem is. It might
or might not be the case that the use of tagged types is an
improvement (there are plenty of cases where tagged types and
OO stuff in general is horribly abused after all)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

"James S. Rogers" wrote:
> 
> Ed Falis wrote in message ...
> >I guess what I don't understand about this conversation is why noone has
> >proposed the use of tagged types instead of manual procedure dispatching.
> 
> Although the original author of this thread used the term dispatching, his
> description of what he wants does not really want dispatching.
> 
> He wants to execute a procedure associated with a particular opcode value,
> not based upon a separate type. He also did not want to use any form of
> case statement to determine the procedure to execute. This rules out the
> use of a discriminated record.
> 
> The approach of a manually constructed dispatching table is valid in either
> C++ or Ada. The reason it is used in C++ is that he is not really using
> virtual functions there either. The C++ vtable will not work for him.
> 
> Show me how you will design a hierarchy of tagged types differentiated only
> by  values of discrete type. I have not yet seen that trick.
> 
> Jim Rogers

Here's one way to use dispatching on tagged types - but I still
need a "dispatch" table.
I don't think it is any clearer or better than my original.
The main loop, on a sparc with gnat 3.12p -gnatp -O3, is 9 instructions
instead of the 8 when using procedure access types - which would obviously
be insignificant in a real program.


with Ada.Text_IO; use  Ada.Text_IO;

procedure Example3 is

   package Foo is

      type Opcode is range 16#00# .. 16#FF#;

      type Op_Root is tagged null record;
      procedure Func (Op : Op_Root);

      subtype Op_U is Op_Root;
      type Op_00 is new Op_Root with null record;
      type Op_01 is new Op_Root with null record;
      type Op_02 is new Op_Root with null record;
      type Op_03 is new Op_Root with null record;

      procedure Func (Op : Op_00);
      procedure Func (Op : Op_01);
      procedure Func (Op : Op_02);
      procedure Func (Op : Op_03);

   end Foo;

   package body Foo is

      procedure Func (Op : Op_Root) is
      begin Put_Line ("undefined opcode"); end Func;

      procedure Func (Op : Op_00) is
      begin Put_Line ("opcode 00"); end Func;

      procedure Func (Op : Op_01) is
      begin Put_Line ("opcode 01"); end Func;

      procedure Func (Op : Op_02) is
      begin Put_Line ("opcode 02"); end Func;

      procedure Func (Op : Op_03) is
      begin Put_Line ("opcode 03"); end Func;

   end Foo;
   use Foo;

   OU : Op_U;
   O0 : Op_00;
   O1 : Op_01;
   O2 : Op_02;
   O3 : Op_03;

   Op_Table : array (Opcode) of Op_Root
    := (Op_Root (O0),
        Op_Root (O1),
        Op_Root (O2),
        Op_Root (O3),
        others => OU
        );

  Core : array (Natural range <>) of Opcode := (0, 1, 2, 3, 55);
  IR : Opcode;

begin

   for PA in Core'Range loop
      IR := Core (PA);
      Func (Op_Root'Class (Op_Table (IR)));
   end loop;

end Example3;

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[tmoran]

> Here's one way to use dispatching on tagged types ...
>    Op_Table : array (Opcode) of Op_Root
>     := (Op_Root (O0),
>         Op_Root (O1),
>         Op_Root (O2),
>         Op_Root (O3),
>         others => OU
>         );
>    ...
>       Func (Op_Root'Class (Op_Table (IR)));

> The main loop, on a sparc with gnat 3.12p -gnatp -O3, is 9 instructions
  It also works with Gnat 3.12p NT.  But both ObjectAda and Janus
print a series of "undefined opcode".  It seems to me that is
actually the correct behavior, since Op_Table is a table of Op_Root,
not a table of Op_Root'class.  I'd be inclined to report this as
a Gnat error.
  As alternatives, you might make Op_Table a table of
access-to-Op_Root'class or use a "case statement IR is".
The latter, of course, is explicitly what you were trying to avoid.

> I don't think it is any clearer or better than my original.
  Agreed.  It's slower, more complex, and, it seems to me, has
no benefits.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E2DC8A.45AE7226@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:

> I don't think it is any clearer or better than my original.

I disagree, the use of general access-to-procedure values is
far less reliable, and has far less constrained semantics. The
use of explicit access-to-procedure values suffers from much
of the same problems as gotos.

Just as we prefer to replace a network of gotos with a case
statement, we prefer to replace the use of access-to-procedure
with dynamic dispatching where possible for many reasons.

As you note, there is very rarely any significant penalty for
this and this transformation is in fact a very nice example.

The version with tagged types is a little more complex
semantically, and that does have to be taken into
consideration.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

jross wrote:
> 
> C/C++ is prime for such a low level application.  How about Ada?

Anything you can write in C you can more or less directly translate to Ada.


> My first question is how do you define and write a dispatching
> mechanism as you would in C++ using function pointers in a table for
> execution speed efficiency,  like this:
>

The following is a direct translation of your code:

with Ada.Text_IO; use  Ada.Text_IO;

procedure Example is

   type Opcode is range 16#00# .. 16#FF#;

   type Func_Access is access procedure;

   type Op_Struct is
      record
         Byte : Opcode;
         Func : Func_Access;
      end record;

   procedure Op_U is begin Put_Line ("undefined opcode"); end Op_U;
   procedure Op_00 is begin Put_Line ("opcode 00"); end Op_00;
   procedure Op_01 is begin Put_Line ("opcode 01"); end Op_01;
   procedure Op_02 is begin Put_Line ("opcode 02"); end Op_02;
   procedure Op_03 is begin Put_Line ("opcode 03"); end Op_03;

  Op_Table : array (Opcode) of Op_Struct
    := ((16#00#, Op_00'Access),
        (16#01#, Op_01'Access),
        (16#02#, Op_02'Access),
        (16#03#, Op_03'Access),
        others => (16#FF#, Op_U'Access)
        );

  Core : array (Natural range <>) of Opcode := (0, 1, 2, 3, 55);
  IR : Opcode;

begin

   for PA in Core'Range loop
      IR := Core (PA);
      Op_Table (IR).Func.all;
   end loop;

end Example;

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jean-Marc Bourguet]

In article <38E05DF5.D9AEC67A@research.canon.com.au>,
Geoff Bull <geoff@research.canon.com.au> wrote:
>
> jross wrote:
> >
> > C/C++ is prime for such a low level application. How about Ada?
>
> Anything you can write in C you can more or less directly translate
> to Ada.

But I'd warn against trying to put a C++ design in Ada. Success would
perhaps proove something -- but I do not know what -- failure surely
nothing more that Ada is not a better syntax for C++. You'll have
problem with features not present in Ada, and never think about
using features not present in C++ (in you exemple, do you have though
about using taks to for the different parts of the processor and the
peripherals? I'd do this more rapidly in Ada than using threads in C++)

> > My first question is how do you define and write a dispatching
> > mechanism as you would in C++ using function pointers in a table for
> > execution speed efficiency, like this:
> >
>
> The following is a direct translation of your code:

No, it isn't. For one, the original C++ made use of pointers to member
functions. Having little used of access to procedures, I do not know if
the equivalent is possible -- calling throw the access would need to
trigger a dispatching call (James, this term has a technical meaning
in Ada); I think a wrapper procedure would be needed to achieve the
equivalent (I'm supposing that the TCpu class not showed declare the
Op_xx as virtual functions).

In either case, I know too little about your design (what is the TCpu
class for) and your design goals (what where you trying to achieve
by introducing it) to give a good translation of your code. The correct
equivalent of a class in C++ may be a package or a non tagged type or a
tagged type. Even for TACpu I can not tell which one is better.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Ken Garlington]

"jross" <rem.jross@rem.codemecca.com> wrote in message
news:38e148e2.5089627@news.shreve.net...
>I was thinking of what kind of application to write to learn Ada and
> put it through it paces.   Since I have heard that Ada was designed
> for system level programming (at the embedded level nonetheless) I
> thought what better application to test the language with than an
> emulator of an older CPU and its peripherals.

I'd like to echo the other comments regarding the difference between
learning the Ada language, and learning how to translate between C++
and Ada syntax. For example, most interesting system levels programs
require more than a few lines of code. So, one of the first issues to
consider
is how to partition the system to make it easy to understand, extend, etc.
Questions you'd need to ask are:

- How do I use packages and types to organize my system?
- What information should go in the package specification?
The private area of the package spec? The body?

Some questions that might be interesting to ask for your specific
example, below:

- Do I want to use the C++ style names, or something else?
- Is a byte the best type for the internal representation of an opcode? More
importantly, is it the right representation for users of this functionality?
Is
it likely to change (affecting all users), and so would another external
representation (an enumeration type?) reduce the maintenance impact?

- Do I want to be able to change the layout of OpStruct to improve
efficiency
on certain machines without affecting the users of this functionality?

- Do I really want users to declare their own OpStructs, etc.?

> My first question is how do you define and write a dispatching
> mechanism as you would in C++ using function pointers in a table for
> execution speed efficiency,  like this:

Without thinking excessively hard, and certainly without checking for
correctness, I'd probably start with something like:

-- file CPU.ads
package CPU is

  -- define registers and much stuff (maybe too much for one package?)

  type Opcode_Type is ( Jump, Test, Undefined_02, Add ... );

  procedure Invoke ( Opcode: in Opcode_Type );
  pragma Inline (Invoke);

  -- might want to declare an Illegal_Opcode exception?

private

  -- declare the internal representation of Opcode_Type here, if needed

  for Opcode_Type...

end CPU;

-- file CPU.adb
package body CPU is

   type Operation_Access is access procedure;

   procedure Undefined_Operation is separate;
   procedure Jump_Operation is separate;
   procedure Test_Operation is separate;
   procedure Add_Operation is separate;

  -- This may actually be more efficient than your C++ example, since the
  -- opcode is not explicitly stored...
  Dispatch_Opcode: constant array (Opcode) of Operation_Access :=
  ( Jump => Jump_Operation'access,
    Test => Test_Operation'access,
    Add => Add_Operation'access,
    ...
    others => Undefined_Operation'access );

  procedure Invoke ( Opcode: in Opcode_Type ) is
     Dispatch_Opcode(Opcode).all;
  end Invoke;

  -- You can also look at moving all the declarations to within Invoke.

end CPU;

-- definitions of xx_Operation procedure bodies would be
-- in separate files.

In real life, of course, you might need more than a single value to invoke
an
instruction. Some architectures have extended opcodes or other modifiers.
Therefore, whether the Invoke should be so tightly coupled with Opcode,
or whether these should be different packages, is a question to consider.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

jross wrote:

> This is very efficient C++ code (could have been just as easy in plain
> old C without the class encapsulation?)  How would you do this in Ada
> without using a Case Statement?

Actually I would probably use case statement!
After a little bit of experimentation I found the case
statement is about as fast as any other method.

Or do you have some other reason for not wanting to use a case statemnt?

Cheers
Geoff

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]


jross <rem.jross@rem.codemecca.com> a �crit dans le message :
38e7e951.8384503@news.shreve.net...
>
> I was making the assumption that a case statement would compile to
> evaluate every case until finding a match -- hence, not efficient.
> Several years ago, I am sure this would have been the case (no pun
> intended).  However, now that I think about it, a compiler these days
> should be intelligent enough to create an indexed jump table where all
> (or most all) consecutive values are provided and create efficient
> execution code.
>
As a point of information, when I was working on Ada/Ed (some years ago
now), I had in my office a PhD thesis on "efficient code generation
techniques for case statements". There was literally a dozen of techniques
possible, depending on how the values were split over the whole range...
Moral: NEVER make assumptions about the way code is generated, unless you
REALLY know what's happening in the compiler (which in practice means, you
are part of the compiler team!)
--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3509 bytes --]

In article <8c7j8c$plf$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> jross <rem.jross@rem.codemecca.com> a �crit dans le message :
> 38e7e951.8384503@news.shreve.net...
> >
> > I was making the assumption that a case statement would
> > compile to evaluate every case until finding a match --
> > hence, not efficient.

> > Several years ago, I am sure this would have been the case

Completely wrong, the switch or case statement from the earliest
days (it is after all in Algol-60, Fortran, C etc in some form
or other) has always been associated with the idea of a jump
table, and all computers have always had instruction sets
suitable for this kind of generation.

It is always surprising when people make these kind of
assumptions -- why not look at the generated code to find
out what kind of machine language is being generated.

It is not unreasonable to write high level code without worrying
too much about low level code efficiency.

It is better to know enough about code generation to have a
reasonable idea of how the compiler generates code.

The worst thing is to worry about what kind of machine language
is being generated and not know the answer, this can lead you
very much astray.

> (no pun
> > intended).  However, now that I think about it, a compiler
these days
> > should be intelligent enough to create an indexed jump table
where all
> > (or most all) consecutive values are provided and create
efficient
> > execution code.

Generally most compilers do indeed do far more than just
generate a simple jump table.

If the jump table is sparse, then it is reasonable to break
it up into ranges, with specific tests on the ranges. These
tests are often arranged into a binary search tree to minimize
run time tests. GCC has done this kind of optimization for a
long time.

If the set of values is really sparse, a hash table is a
reasonable choice, especially given that a perfect hash
function can be computed at compile time. BCPL compilers
had this optimization quite early (in the 60's I would guess).

> As a point of information, when I was working on Ada/Ed (some
> years ago now), I had in my office a PhD thesis on "efficient
> code generation techniques for case statements". There was
> literally a dozen of techniques possible, depending on how the
> values were split over the whole range...

Indeed there are many techniques and it is quite reasonable to
study them formally. I saw a much more recent thesis on the same
topic (the consideration is made more difficult by paging and
icache considerations on modern processors).

> Moral: NEVER make assumptions about the way code is generated,
> unless you REALLY know what's happening in the compiler (which
> in practice means, you are part of the compiler team!)

That's a bit extreme, but I know what you mean. In particular
the whole Realia COBOL team knew the compiler very well and
what it generated, and that was one of the reasons this
compiler is so fast (it compiles high quality run-time code
for COBOL at a very high speed -- well over 100,000 lines a
minute on a 25MHz 386, I have no idea how it does on a
gigahertz Pentium, should be several million lines a minute :-)

By the way, the -gnatG option in GNAT is quite useful for
finding out what code the compiler is generating at a macro
level. It is also a very useful verification tool (see also
the asociated -gnatD option).

Robert Dewar
Ada Core Technologies



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Paul Graham]

It sounds like the Realia compiler ran about as fast as grep or some
similar text scanning program.  How did you achieve such compiler
speed?  Is there something about COBOL that makes it easier to compile
than Ada?

Paul

> That's a bit extreme, but I know what you mean. In particular
> the whole Realia COBOL team knew the compiler very well and
> what it generated, and that was one of the reasons this
> compiler is so fast (it compiles high quality run-time code
> for COBOL at a very high speed -- well over 100,000 lines a
> minute on a 25MHz 386, I have no idea how it does on a
> gigahertz Pentium, should be several million lines a minute :-)

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E8F9C4.6D0E137@cadence.com>,
  Paul Graham <pgraham@cadence.com> wrote:
> It sounds like the Realia compiler ran about as fast as grep
or some
> similar text scanning program.  How did you achieve such
compiler
> speed?  Is there something about COBOL that makes it easier to
compile
> than Ada?
>
> Paul


No, in fact COBOL is a tough language to compile. But actually
in my experience, grep on many Unix machines runs dismally
slow, far slower than it should given the speed of disks,
and the speed of processors today.

Do some rough back of the envelope calculations

a 2 million line COBOL program is typically about 70 million
bytes long. Modern disks can easily read that much data in
10 seconds. Modern memories are large enough to hold all
intermediate data, so the only output is writing the object
file, and that will take less, say 5 seconds.

Now let's suppose we compile using 10,000 instructions per
line of COBOL, Realia COBOL is actually lower than this by
quite a margin but let's see where that gets us.

THat means that we need to execute 2 million x 10 thousand
instructions = 2 * 10**10 instructions.

A top of the line x86 machine (costing of the order of
$2500) has a 1 gigahertz chip capable of executing at
least two instructions per cycle in typical use, so that's
2 * 10**9 instructions per second.

So our compilation requires 10 seconds of CPU time. Since this
can be overlapped with reading the sources, there is no reason
not to expect the compilation to be finished in less than half
a minute.

Could one write an Ada compiler that compiled this fast? Yes,
but it would be a very large project. Is it worth it? No.

As machines get faster and faster, fast compilation becomes
less critical, and this trend will steadily continue.

When Realia started, it is was really interesting that we
compiled 10,000 lines/minute on a PC-1 with the competition
only compiling 1000 lines/minute.

But a few years later, when both figures were multiplied by
a large factor, this became a much less critical competitive
advantage.

I must say I do miss the days when doing a full bootstrap
of the compiler took 40 seconds with Realia COBOL, about
the time to go get another Diet Coke from the fridge, but
we are getting back to within hailing distance of that
now with recent high performance machines, and indeed if
you can afford a multi-processor top of the line SGI
machine, you can indeed get compilation speeds this fast.

I remember Jean Ichbiah in the late 80's coming up with
the term Megaloch to describe compiler speed (millions
of lines of code ber hour), and thinking we were not
far from the first megaloch Ada compiler. Interesting
that we have now overtaken that benchmark by a big factor
already.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Larry Kilgallen]

In article <8ciddt$2v7$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:

> So our compilation requires 10 seconds of CPU time. Since this
> can be overlapped with reading the sources, there is no reason
> not to expect the compilation to be finished in less than half
> a minute.
> 
> Could one write an Ada compiler that compiled this fast? Yes,
> but it would be a very large project. Is it worth it? No.

Another area of overlap is program compilation with programmer
thinking about the problem.  Human instinct can sometimes lead
the programmer to try to "keep up with" the machine and make a
test run as soon as the compilation is done rather than waiting
until the thinking is done.

A faster compiler can result in a considerably larger number of
compilations to reach the same end result, possibly with a much
longer wall clock time.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <2000Apr6.125002.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> A faster compiler can result in a considerably larger number
> of compilations to reach the same end result, possibly with a
> much longer wall clock time.

That's an argument more appropriate to the 70's than now.

For a long time now, compilers have been fast enough on most
machines (perhaps not on Vaxes running VMS :-) that working
on individual modules (the most normal case), recompiling
and relinking are fast enough in most environments that this
is not a major barrier.

What is useful about fast compilers is the ability to rebuild
entire systems rapidly, which allows changes to be made to
specs with greater facility.

In the old Ada 83 days I often saw horrible kludges being
introduced in bodies to avoid changes to specs, since spec
changing was so painful for rebuilding time.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Gautier]

>   Kilgallen@eisner.decus.org.nospam wrote:

> > A faster compiler can result in a considerably larger number
> > of compilations to reach the same end result, possibly with a
> > much longer wall clock time.

Robert Dewar wrote:
 
> That's an argument more appropriate to the 70's than now.

> For a long time now, compilers have been fast enough on most
> machines (perhaps not on Vaxes running VMS :-) that working
> on individual modules (the most normal case), recompiling
> and relinking are fast enough in most environments that this
> is not a major barrier.

There is an exception to both arguments: compiling with DEC
Ada on a fast AXP server. Compiling a module with a few errors
can produce thousands of lines of fast scrolling terrifying
disagnostics, so I hesitate to recompile too early...

_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38ECE79C.4F70D434@maths.unine.ch>,
  Gautier <gautier.demontmollin@maths.unine.ch> wrote:
> There is an exception to both arguments: compiling with DEC
> Ada on a fast AXP server. Compiling a module with a few errors
> can produce thousands of lines of fast scrolling terrifying
> disagnostics, so I hesitate to recompile too early...


Well I think we can all agree that fast scrolling terrifying
diagnostics are NOT a good thing :-)

Actually there is an interesting debate there, some people
like the extreme verbosity of the DEC Ada error messages,
for me they are simply too verbose, and I prefer terser
messages.

In GNAT, we introduced the -gnatf flag which gives some useful
level of control over the level of verbosity, If you like
error messages in the DEC Ada style, you will certainly find
-gnatf an improvement (I don't like to use it personally).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Gautier]

Robert Dewar wrote:

> Well I think we can all agree that fast scrolling terrifying
> diagnostics are NOT a good thing :-)

For those who haven't come across the wonderful but incredibily
verbose DEC Ada, I just ran a little test on a project of mine.

I change
  package FIO  is new Float_IO(float);
  package LFIO is new Float_IO(float);

into
  package FIO  is new Float_IO(float);
  package LFIO is new Float_IO(FT_real);

DEC Ada produces 2925 lines of insults (180 KB),
at the end of which you can read:

 Terminating compilation because ERROR_LIMIT=30 reached

!!!
_____________________________________________
Gautier  --  http://members.xoom.com/gdemont/

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[swhalen]

I'm surprised that no one has pointed you to the Ada95 Quality and
Style Guide (AQS95). It's available in some of the places the
reference manual is, and in several formats. I keep an html copy that
I've run a quick perl script over to make it run from disk.  It's not
as "authoritative" as the RM, but unless you're writing an Ada
compiler, the RM can be a bit much to follow....

I think the AQS is one of the most useful "semi-official" documents
around and I also happen to agree with just about everything it says
is "good" Ada95 <g>.

I'd also recommend Dale Stanbrough's "Quick Ada" tutorial notes at

  http://goanna.cs.rmit.edu.au/~dale/ada/aln.html

as one of the more helpful for experienced programmers. There is a
postscript version you can print out.  It is written at a good level
for experienced programmers.  I seem to recall there was a minor typo
or two, but overall I think you might find it helpful.

Good luck with Ada!

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <8btrv3$p8d$1@slb7.atl.mindspring.net>,
  swhalen@netcom.com wrote:

> I'm surprised that no one has pointed you to the Ada95 Quality
> and Style Guide (AQS95).

Probably because it seems a surprise to think of this as an
Ada 95 text book, it does not have much to say about rules of
the language, it is more about style rules. I suppose it does
have some useful examples, but learning by example alone seems
dangerous to me.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[swhalen]

Robert Dewar <robert_dewar@my-deja.com> wrote:
:   swhalen@netcom.com wrote:
:> I'm surprised that no one has pointed you to the Ada95 Quality
:> and Style Guide (AQS95).
: Probably because it seems a surprise to think of this as an
: Ada 95 text book, it does not have much to say about rules of
: the language, it is more about style rules. I suppose it does
: have some useful examples, but learning by example alone seems
: dangerous to me.

I don't really think of it as a text book and would not recommend it
over Barnes or any of the real text books. However it has a few
things to recommend it:

  - it's free and immediately available over the net for those 
    just starting out in Ada who aren't sure they want to invest
    in any books

  - it is written such that experienced programmers will be able
    to see the "preferred" idiom for doing various common and 
    some not so common things the "Ada way"

  - experienced programmers who are wondering "why" certain features
    of the language are the way they are, may get some quick 
    insights into why certain language features are the say they are.
    I know that more than once I've had a minor epiphany from an 
    example in the Ada83 or Ada95 style guide by seeing from one
    of those examples something it hadn't occurred to me to do.
    The examples in the AQS are to me more accessible than many
    of the text books because it's much shorter and to the point.
    In many ways, it says: "if you're not using this idiom, you're
    not taking full advantage of the language" (my gross 
    oversimplification, not flaim bait).

  - I don't advocate learning by examples _alone_, but I think when 
    experienced programmers are starting out to learn a new language,
    examples can give them a "hook" to begin relating some of the 
    features of the new language to their experience (or begin to 
    realize that something is new to them).

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Marin D. Condic]

jross wrote:
> 
> Just a note about the RM95 -- who wrote this stuff?  My head hurts
> reading this!!!  Ouch!   :)

Try to keep in mind that the ARM was written to provide a precise
definition of the language primarily for the benefit of implementors. It
is not a "how to" text for Ada and there are plenty of better sources
for learning the language. Goto <<Adapower_Website>> (Proper use of
gotos? :-) for lists of books and on-line tutorials.
http://www.AdaPower.com/

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Marc A. Criley]

jross wrote:
> Just a note about the RM95 -- who wrote this stuff?  My head hurts
> reading this!!!  Ouch!   :)

A suggestion:  Use the RM95 as a reference manual (which I regularly
do) and familiarize yourself with the language via the Ada 95
Rationale.  The rationale is eminently readable and provides a good
overview of the language features, details of which can then be
investigated within the RM.

Marc A. Criley
Software Architect
Lockheed Martin M&DS
marc.a.criley@lmco.com

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[David Starner]

On Wed, 29 Mar 2000 05:39:20 GMT, jross <rem.jross@rem.codemecca.com> wrote:
>values.  Actually the entire array can be a constant (don't know if
>that would help with optimizing the compiled code).  

It's generally a good idea to make anything that will be constant defined
as such in the code, especially in Ada, which puts emphasis on strong
typing. It quite possibly could help optimize access to the array in the
code.

>Just a note about the RM95 -- who wrote this stuff?  My head hurts
>reading this!!!  Ouch!   :)

You do realize probably half the authors of the RM95 are reading this
message? :-) Honestly, I've found the RM95 pretty easy reading
compared to some of the other standards I've tried to read. 
(ISO 7185: Basic Pascal comes to mind as a fairly painful standard.)

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <8bs49i$baq1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> On Wed, 29 Mar 2000 05:39:20 GMT, jross
<rem.jross@rem.codemecca.com> wrote:
> >values.  Actually the entire array can be a constant (don't
know if
> >that would help with optimizing the compiled code).
>
> >Just a note about the RM95 -- who wrote this stuff?  My head
> >hurts reading this!!!  Ouch!   :)
>
> You do realize probably half the authors of the RM95 are
> reading this
> message? :-) Honestly, I've found the RM95 pretty easy reading
> compared to some of the other standards I've tried to read.
> (ISO 7185: Basic Pascal comes to mind as a fairly painful
> standard.)


The important thing to understand is that the RM is a language
definition, NOT a text book. Almost no one could learn the
language from the RM, and no one is expected to. You do not
read the RM until you know the language, that is what the
"reference" in the title means. Now there are sections which
are more accessible than others, e.g. Annex A is straightforward
and can be used as a text book for the standard library.

But you cannot expect to read much of the body of the RM without
a thorough understanding of Ada.

There is always a trade off in a language standard between
readability/accessibility and precision. Many standards are
FAR harder to read than the Ada standard, e.g. the PL/1
standard, or the Algol-68 revised report, the latter being
a fully formal definition, which you have to be a skilled
mathematician to read.

The original Ada 83 report was designed to be as readable as
possible while still meeting the fundamental requirements for
precision. It was a success and a failure depending on your
point of view:

  a) it was a success because for the first time since Algol-60,
     ordinary practicing programmers read the language Standard.
     (by comparison, virtually no C, C++, or COBOL programmers
     have a copy of the standard or have read it, and of course
     there does not even exist a standard for Java, or Visual
     Basic or Delphi).

  b) it was a failure in the view of some (not me) because it
     was not felt to be formal enough and precise enough.

There was a very concious effort in Ada 95 to make the document
more precise, even if at the expense of readability and
accessibility. The result is that the Ada 95 document is indeed
more precise, but it is also MUCH harder to read (at least I
think so, and I am one of the people who can read the RM for
the most part).

What's the right balance? Well I prefer the Ada 83 RM, but
obviously the authors, and many of the reviewers prefer the
Ada 95 RM style.

In any case, both the Ada 83 and Ada 95 RM are far superior to
other standards, since for both languages it is normal practice
for working programmers to have a copy of the RM accessible on
paper or electronically (*) and to refer to it at least
occasionally as a reference document. This is still not
achieved with other languages. So the difference in style
between 83 and 95 is minor here if we start comparing with
other standards for other languages.

Why do standards/definitions of languages tend to be hard to
read compared to a text book. Among the reasons are:

  1. Redundancy (saying the same thing more than one way) is
     a friend in a text book, but an enemy in a definition (in
     a definition it is unnecessary, and risky, because you
     might not say exactly the same thing each time).

  2. Exploring consequences is a friend in a text book, but an
     enemy in a definition. What I mean here is that if you
     state a set of rules, and it is possible to deduce a
     consequential rule from these rules, then a standard does
     NOT need to state this consequential rule even if it is
     non-obvious. Again, stating it is redundant, and
     unnecessary. But in a text, exploring non-obvious
     (but often useful) consequences of rules is a very
     important aspect.

  3. Examples and notes are just examples of redundancy, they
     have no place in a definition. An example is either right,
     in which case it tells you nothing, or wrong, in which
     case it is damaging. On the other hand, examples are of
     the essence in text books because many people like to
     learn by example.

  4. A definition must cover 100% of the language, including
     highly obscure cases that no one is interested in. A
     text book can simplify by stating rules in a way that is
     not formally 100% correct, but is in practice good enough
     for everyone actually using the language, and thus
     simplify the presentation.

The RM does of course have notes and examples, but they are
NOT part of the definition of the language. I personally think
they have no place in the RM, because I don't like learning
from examples (I am one of the peculiar people who learned
most languages from their reference manuals, including COBOL
and Algol-68), but I recognize that people do find the examples
useful. Just remember never to cite them in arguments about
what the standard says.

As a specific example, a typical text book for Ada will
tell you explicitly when discussing FOR loops that you cannot
modify the loop variable, and that is a useful rule for
beginners, stated in that form.

But in the definition of Ada in the RM, you will find no such
rule, since it is not necessary. Why? Because in chapter 3,
the definition of a "constant" includes the FOR loop entity,
and other rules make it clear that you cannot modify constants.
None of these rules is anywhere near the loop statement
description itself.

Now in this particular case, I suggested a note (right, I don't
like notes, but I understand why others do), and that note can
now be found in the section on loops:

10   (6) A loop parameter is a constant; it cannot be updated
         within the sequence_of_statements of the loop (see
         3.3).

But this note is not part of the definition and is entirely
redundant.

What would be useful to many people is an annotated version of
the RM that explains what each section means in simpler terms
with more examples and notes. There was a very nice version of
the Fortran standard printed in large format with the standard
in small print giving giant margins used for explanations and
comments.

The AARM (Annotated Ada Reference Manual) that exists now has
some explanatory material that is at this level, but mostly
is at a very different level, exploring detailed implementation
consequences and weird cases that lead to various decisions.

The Rationale also has some of this material, but not keyed to
the RM paragraph by paragraph.

However, these two documents are very useful adjunct reading,
and if you don't understand something in the RM, seeing if there
are AARM annotations is always a useful check.

By the way, it is the lack of accessibility of the RM that makes
it inadvisable in our view to put RM references in all error
messages. Most of the time such RM references either lead you
to sections that simply restate the rule stated in the error
message, or to incomprehensible sections of the RM that will
indeed make your head ache. We only put RM references in when
we think they are genuinely useful (which is quite a few
situations, but most ordinary error messages do not have RM
references for very good reasons).

Interestingly, when we have discussed the issue of RM references
in GNAT error messages, most people strongly in favor of the
idea base their views on experience with Ada 83 compilers and
the Ada 83 RM, but that was, as I mentioned above, a much more
accessible document. Even more interestingly, when we have
discussed this issue, I always suggest that people give examples
of messages where an RM reference would help, and that always
seems to strangely end the thread :-)

Robert Dewar
Ada Core Technologies



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Marin D. Condic]

Robert Dewar wrote:
> There was a very concious effort in Ada 95 to make the document
> more precise, even if at the expense of readability and
> accessibility. The result is that the Ada 95 document is indeed
> more precise, but it is also MUCH harder to read (at least I
> think so, and I am one of the people who can read the RM for
> the most part).
> 
What occurs to me is that it would be an interesting project to take the
ARM in hypertext and annotate it with more hypertext that explains the
intended usage or "how to" aspects of the various sections. You look up
a specific feature and get the precise definition of what it means, but
can punch into someone's "gloss" on the subject where there might be
example code, plain-English explanations of how the feature was intended
to be used, etc.

Certainly we have the AARM, but that was obviously aimed at a different
crowd and IMHO is less accessible than the rest of the standard. Those
annotations could have been made into hyperlinks as well.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert A Duff]

"Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes:

> What occurs to me is that it would be an interesting project to take the
> ARM in hypertext and annotate it with more hypertext that explains the
> intended usage or "how to" aspects of the various sections. ...

IMHO, a text book can be better organized than that, for its purpose.
The problem with the RM is not just that it's difficult reading, but the
topics are presented in an unhelpful order for learning.

- Bob

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Marin D. Condic]

Robert A Duff wrote:
> IMHO, a text book can be better organized than that, for its purpose.
> The problem with the RM is not just that it's difficult reading, but the
> topics are presented in an unhelpful order for learning.
> 
Very true. There is no substitute for a good textbook. What I had in
mind was not for purposes of teaching/learning Ada, but more of adding
some "user friendly" information to the ARM that doesn't intrude on its
original purpose.

I know from my own experience that I've gone into the ARM looking for an
understanding of a particular feature and have maybe come back with an
incomplete understanding of what I was really supposed to do with it. An
example or two or some text that explained what the designers intended
the usage to be would certainly have helped.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jean-Marc Bourguet]

jross>Just a note about the RM95 -- who wrote this stuff? My head
jross>hurts reading this!!! Ouch! :)

Well it is the standard which I found the easiest to read. The worst
beeing the Verilog one.

dewar> (I am one of the peculiar people who learned
dewar> most languages from their reference manuals, including COBOL
dewar> and Algol-68)

I do not know COBOL, but learning Algol-68 from the RM does impress
me a lot. I can find my way in it, more or less easily, but I knew
a good part of the language before opening the RM.

-- Jean-Marc


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <8bt1vk$r0e$1@nnrp1.deja.com>,
  Jean-Marc Bourguet <bourguet@my-deja.com> wrote:
> dewar> (I am one of the peculiar people who learned
> dewar> most languages from their reference manuals, including
COBOL
> dewar> and Algol-68)
>
> I do not know COBOL, but learning Algol-68 from the RM does
impress
> me a lot. I can find my way in it, more or less easily, but I
knew
> a good part of the language before opening the RM.


If you can find your way in the Algol-68 report, you are part
of a VERY small group of people in the world :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Jean-Marc Bourguet]

In article <8bu375$2mh$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8bt1vk$r0e$1@nnrp1.deja.com>,
> Jean-Marc Bourguet <bourguet@my-deja.com> wrote:
> > dewar> (I am one of the peculiar people who learned
> > dewar> most languages from their reference manuals, including
> COBOL
> > dewar> and Algol-68)
> >
> > I do not know COBOL, but learning Algol-68 from the RM does
> impress
> > me a lot. I can find my way in it, more or less easily, but I
> knew
> > a good part of the language before opening the RM.
>
> If you can find your way in the Algol-68 report, you are part
> of a VERY small group of people in the world :-)

And now I'll wonder if I've understood anything in the report :-)

-- Jean-Marc, who have better things to do than go and read the report
anew


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <8buu98$j$1@nnrp1.deja.com>,
  Jean-Marc Bourguet <bourguet@my-deja.com> wrote:
> In article <8bu375$2mh$1@nnrp1.deja.com>,
> Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <8bt1vk$r0e$1@nnrp1.deja.com>,
> > Jean-Marc Bourguet <bourguet@my-deja.com> wrote:
> > > dewar> (I am one of the peculiar people who learned
> > > dewar> most languages from their reference manuals,
including
> > COBOL
> > > dewar> and Algol-68)
> > >
> > > I do not know COBOL, but learning Algol-68 from the RM
does
> > impress
> > > me a lot. I can find my way in it, more or less easily,
but I
> > knew
> > > a good part of the language before opening the RM.
> >
> > If you can find your way in the Algol-68 report, you are
part
> > of a VERY small group of people in the world :-)
>
> And now I'll wonder if I've understood anything in the report
:-)


Well the dynamic semantics is not so bad, I actually often find
it much easier to read than the Ada RM (certainly than the Ada
95 RM). The static semantics is another matter. It is not that
the w grammars are inpenetrable, it is that they are code, and
completely uncommented code at that. I think a good set of
comments would make the W grammars much more accessible.

By the way, just so you know not everyone reacts like everyone
else, Jack Schwartz had a student (sorry name escapes me now)
who designed a language called GYVE for operating system
building. He loved the original Algol-68 report, and provided
a complete definition of GYVE in that style. Then the revised
Algol-68 report came out, with the major discovery of predicates
in the W grammars (that allow much clearer code by exploiting
the idea of preconditions which parse to null if true, and a
blind alley if false). The student was so impressed that he
completely *rewrote* the entire definition in the thesis to use
predicates :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

Robert Dewar wrote:
>  and of course there does not even exist a standard for Java,

???

http://www.javasoft.com/docs/books/jls/html/index.html
http://java.sun.com/aboutJava/communityprocess/maintenance/JLS/jls2draft.pdf

I guess you mean that the standard does not exist in the sense 
that it is not approved by a standards body such as ISO.
Obviously ISO sanctioned standards are better than proprietary standards.
Of course, some will argue that a proprietary standard isn't a standard 
... I think we've had that discussion before.

Anyway, getting an ISO standard for Java is not going to solve the
numerous shortcomings in the language, e.g.:
    only form of abstraction is class (which is heap allocated)
    everything must be an object even when that is not appropriate
    no unsigned arithmetic (that causes a HUGE number of bugs)
    no enumerated/abstract type
    no fixed point arithmetic
    no range checking except for arrays
    no operator overloading (boy does that make using my FixedPoint
       class ugly)
    no support for large programs (let's start with package renaming!)
    no rep clauses - have to do raw bit bashing
    finalizers aren't guaranteed to be ever called (limiting them
       to rather specialised uses)
    poor standard style
    difficulty interfacing to other languages
    etc etc etc (I write lots of Java so have discovered a lot of problems)

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E2B049.F12CFD39@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:
> Robert Dewar wrote:
> >  and of course there does not even exist a standard for
Java,

> I guess you mean that the standard does not exist in the sense
> that it is not approved by a standards body such as ISO.

That to me is what a standard is about.

> Obviously ISO sanctioned standards are better than proprietary
> standards.

Indeed.

> Of course, some will argue that a proprietary standard isn't a
> standard

Indeed they will, and they will be right :-) A proprietary
standard is a contradiction in terms (*). More to the point,
if you accept the notion, then everything is standardized,
since you can always find a proprietary definition for anything.
For instance, are we to agree that all architectures are
standardized simply because vendors provide reasonably complete
and accurate definitions?

(*) but not an oxymoron, being a charter member of the
please-let's-preserve-the-nice-word-oxymoron-and-not-misuse-it
club I like to take the opportunity to make this point :-)
Yes, yes, I know it is a lost cause, just like moot :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

Robert Dewar wrote:
> 
> In article <38E2B049.F12CFD39@research.canon.com.au>,
>   Geoff Bull <geoff@research.canon.com.au> wrote:

> > Of course, some will argue that a proprietary standard isn't a
> > standard
> 
> Indeed they will, and they will be right :-) A proprietary
> standard is a contradiction in terms (*). More to the point,
> if you accept the notion, then everything is standardized,
> since you can always find a proprietary definition for anything.
> For instance, are we to agree that all architectures are
> standardized simply because vendors provide reasonably complete
> and accurate definitions?

According to the OED, a standard is a "weight or measure
to which others conform or by which the accuracy or quality
of others is judged".

By this definition Sun's Java Language Specification *is* a standard. 
Most Java implementors are making big efforts to conform to
Sun's standard, MS being the notable exception.

I am not saying that privately controlled standards are a good thing.
I was just objecting to the claim "there is no standard for Java"
because, unless you twist the meaning of the word standard,
it is false.

Also, proprietary standard is not a contradiction in terms.
I could say proprietary is orthogonal to standard,
but in light of (*) I won't :-)

> (*) but not an oxymoron, being a charter member of the
> please-let's-preserve-the-nice-word-oxymoron-and-not-misuse-it
> club I like to take the opportunity to make this point :-)
> Yes, yes, I know it is a lost cause, just like moot :-)

Cheers
Geoff

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E6971D.3A8435B9@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:

> According to the OED, a standard is a "weight or measure
> to which others conform or by which the accuracy or quality
> of others is judged".

Sure, that is the informal meaning of standard, it is the
meaning that is appealed to when you here an advertisement
saying something like "moogoo gizmos, the standard by which
gizmos are judged".

But in the computer language field, it is helpful to understand
the word "standard" in a technical sense to talk about something
in the class of ISO or ANSI standards. Sure, Java has a standard
in the informal sense, and so does every other non-standardized
language. Since every language has a standard in this informal
sense, the informal sense is not much use.

So I reserve the word standard to mean a national or
international standard approved by an appropriate national or
international body. This is a useful usage, and corresponds
to common usage as well. Certainly if you see me use the
word standard in connection with a programming language it
is meant in this technical sense.

Obviously people can use words anyway they want, like
Humpty-Dumpty in Alice, so I will repeat the statement,
now that you understand it better, there is no standard
for Java.

Is this just semantics? or is it an important distinction?
It is indeed an important distinction! When there is an
international standard, there is a very strong pressure
on vendors to conform, for example, the Microsoft C compiler
is indeed compliant with the ISO standard, which has been
prepared in a consensus process to meet everyone's requirements
as best as possible.

The trouble with an informal "standard" like Sun's "standard"
for Java is that it is designed first and foremost to meet
Sun's commercial requirements. This is not a criticism in any
sense, for Sun to do otherwise would make no sense. Now to
a certain extent, trying to be reasonably universal may be
part of this commercial requirement, but there is no guarantee
of this.

The argument between Sun and Microsoft is a perfect example. An
international standards body would give equal weight to the
requirements of Sun and Microsoft (and IBM and ....). In fact
Microsoft's requirements that Java interface well with COM and
DCOM is a perfectly reasonable technical point to be considered.

It is not at all surprising that Sun objects to doing something
that would help Microsoft, and consequently it is not at all
surprising that Sun pulled out of the standardization process.

Proprietary standards are simply not the same kind of beast
as international standards arrived at by consensus. Microsoft
can't complain too much about Java, because they play the game
of using proprietary "standards" for their own technology with
the intention of maintaining commercial advantage.

Probably the most helpful terminology is to use standard in
this context to imply a standard reached by a consensus
process among experts, and "proprietary standard" to talk
about "standards" maintained by vendors to their own advantage.

Note once again that it is not a criticism of Sun and Microsoft
that they use these proprietary standards to their own
commercial advantage. You could even make the case that
their fiduciary responsibilities to their stockholders require
them to take this viewpoint!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[swhalen]

Geoff Bull <gbull@acenet.com.au> wrote:

: According to the OED, a standard is a "weight or measure
: to which others conform or by which the accuracy or quality
: of others is judged".

: By this definition Sun's Java Language Specification *is* a standard. 
: Most Java implementors are making big efforts to conform to
: Sun's standard, MS being the notable exception.

: I am not saying that privately controlled standards are a good thing.
: I was just objecting to the claim "there is no standard for Java"
: because, unless you twist the meaning of the word standard,
: it is false.

First, those of us here in the colonies do NOT swear allegiance to
the Oxford English Dictionary<g>.  You'll recall we had a bit of a
fracas a while back so we could choose our own dictionaries, form of
government, etc.

I think the problem many of us have with "proprietary standards" is
that unlike a measure of weight or such, the "standard" can be
changed at the whim of the proprietor, and is thus not a "stable"
standard.

I submit that a unit of weight that weighs as much as _I_ want it
to, is just as "non-standard" as a "Sun Java Standard".  The
measures I think the OED refers to, seldom if ever change, unlike
"proprietary standards" like Java or the "Windows API".

I think an ISO standard like Ada is far nearer to the OED meaning
because it changes slowly if at all, and in full public view (like
when they changed the basis for the length of a meter, or when the
working groups work on a "fix" or proposed revision to the Ada
standard).

Sun and Microsoft and other proprietors change their "standards"
much more frequently, and with no mandatory concern for the impact
on others who have adhered to the standard as it existed before
(their proprietary interests come before the common good whenever
the two come into conflict).

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert A Duff]

dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:

> >Just a note about the RM95 -- who wrote this stuff?  My head hurts
> >reading this!!!  Ouch!   :)
> 
> You do realize probably half the authors of the RM95 are reading this
> message? :-)

Yes, but most of them (including me) are not so quick to take offense.
;-)

Besides, I *agree* that the RM95 is head-hurting reading.  The goal of a
standard (IMHO) is uniformity across implementations, and that (sadly)
seems to require unreadable prose.

Anyway, as several people have pointed out, the original poster should
put the RM95 away for now, and read a textbook first.

>... Honestly, I've found the RM95 pretty easy reading
> compared to some of the other standards I've tried to read.

You're unusual.  Most people find the Ada 83 RM more readable than RM95.
Except compiler writers, who *have* to care about all the odd corners.

> (ISO 7185: Basic Pascal comes to mind as a fairly painful standard.)

- Bob

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

Robert A Duff wrote:

> Besides, I *agree* that the RM95 is head-hurting reading.  The goal of a
> standard (IMHO) is uniformity across implementations, and that (sadly)
> seems to require unreadable prose.

It's *not* that bad.

> Anyway, as several people have pointed out, the original poster should
> put the RM95 away for now, and read a textbook first.

IMO, this is bad advice for an experienced programmer.
The RM is a valuable means of clarifying concepts that may be unclear
in a textbook.

BTW I read the RM and did an online tutorial.
Once I was hooked, I then bought a couple of books.
My guess is that "C/C++ programmer giving Ada95 a chance"
is not going to part with too many $$$ on books until
he is fairly sure that he is going to get some use out of them.

Cheers
Geoff

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E2B446.C9A4D1@research.canon.com.au>,
  Geoff Bull <geoff@research.canon.com.au> wrote:

> > Anyway, as several people have pointed out, the original
poster should
> > put the RM95 away for now, and read a textbook first.
>
> IMO, this is bad advice for an experienced programmer.

maybe, but you used a textbook (an online tutorial *is* a
text book in this sense) to learn the language, so you don't
disagree that much.

The point is that trying to learn from the RM alone is a bad
idea for most folk (that incidentally is why I do not think
there should be examples in the RM, if you are at the level
where you can really understand things from the RM, you should
not need examples, if you do need examples, you will probably
do better to first learn Ada elsewhere -- now I know some
people are SO used to learning from example, and in fact
are almost "formalism-challenged" that in practice this is
not feasible advice, but I think you get my point :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Samuel T. Harris]

jross wrote:
> 
> 
> Just a note about the RM95 -- who wrote this stuff?  My head hurts
> reading this!!!  Ouch!   :)

My sentiments exactly. I learned Ada reading the Ada 83 LRM while
floating in my apartment pool while off duty in the Air Force
in 1985. Having been something of a language design hack in
college, I found a great many episodes of "wow, that is exactly
what I've been wanting in a language" moments.

In 1995, I tried the same thing with the Ada 95 LRM and did
not have much success. Too many new things, too many new interactions
amoungst the new things and the old things. Of course, the Ada 95 LRM
is not meant to be tutorial material and I felt in no way let down
by the authors.

It is interesting how two documents from two different
sets of folks concerning basically the same things
can be so very different in style.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E3D0A5.4F93106F@Raytheon.com>,
  "Samuel T. Harris" <samuel_t_harris@Raytheon.com> wrote:

> It is interesting how two documents from two different
> sets of folks concerning basically the same things
> can be so very different in style.

Note that it is not so much a difference in authors style here,
as a very deliberate design choice of favoring formalism and
supposed precision over readability.

I am not sure everyone on WG9 and the reviewers group really
understood what a very big change was being made. The above
note is *exactly* what concerned me when I tried to argue for
retaining the original style.

I suspect that if the original Ada 83 RM had been written in
this style we simply would not have achieved the pretty much
unique status among languages that practicing programmers use
the defining document as a reference.

Luckily we benefit from history here, Ada programmers from 83
days are so used to operating in this mode that they continue
the habit, even though it is harder these days.

Is the Ada 95 RM more precise? I am not 100% convinced at all.
Looking at the set of AI's that are coming in, we are seeing the
same kinds of minor gaps and errors that happened with the
Ada 83 RM, I would be hard put to say there was a big
qualitative difference in the scope of AI's considered in the
two cases. Bob (Duff) what do you think on that score? [I
think Bob's input here is useful since he knows both RM's
well and both sets of AI's, and if biased at all would be
biased to thinking the 95 AI's are less significant (*)

(*) in fact, I never noticed Bob's viewpoints being perceptibly
affected by bias of any kind :-) even though he is constantly
warning that as an author he may be biased!



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Is the Ada 95 RM more precise? I am not 100% convinced at all.
> Looking at the set of AI's that are coming in, we are seeing the
> same kinds of minor gaps and errors that happened with the
> Ada 83 RM, I would be hard put to say there was a big
> qualitative difference in the scope of AI's considered in the
> two cases. Bob (Duff) what do you think on that score?

I think the Ada Issues from the Ada 83 era are "bigger" (on average)
than the Ada 95 ones, in two senses: more impact on users, and more
difficult to fix without damaging other parts of the language.

I'm not so sure that's because the RM is more precise.  That could be
part of it, but it is also the case that the Ada 83 design was a bigger
job (from scratch language design, as opposed to a modification of 5% of
an existing language) -- so you would expect bigger bugs.

The above is just my gut feel.  It might be interesting to go through
all the AI's and rate them more-or-less objectively and add up the
ratings.  But not interesting enough for me to waste time doing it!  ;-)

>... [I
> think Bob's input here is useful since he knows both RM's
> well and both sets of AI's, and if biased at all would be
> biased to thinking the 95 AI's are less significant (*)
> 
> (*) in fact, I never noticed Bob's viewpoints being perceptibly
> affected by bias of any kind :-) even though he is constantly
> warning that as an author he may be biased!

Well, that's a nice thing to say.  Thanks!

- Bob

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Ken Garlington]

"jross" <rem.jross@rem.codemecca.com> wrote in message
news:38e19656.17008608@news.shreve.net...
> Ah! Access types and the ability to Initialize an array with record
> values.  Actually the entire array can be a constant (don't know if
> that would help with optimizing the compiled code).

I think in my example I used a constant table. You might be right if it
helped
with optimization, also. However, I didn't define the table as constant
because of
optimization -- I defined it as constant because logically I probably won't
change it
dynamically, and if some part of the code attempted to do so, I'd probably
want to
know about it. That sort of checking built into the language is very
powerful, and
you should make use of it whenever you can. This sort of thought process is
going
to help you understand the dfference between using the predefined types
(Integer,
Float, etc.) and user-defined types (e.g. type Opcode is new Integer?)
later.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[tmoran]

>And the conversion to Op_Root'Class to force dispatching
>seems reasonable to me (you can find this on p546 of Cohen).
  On p546 Cohen says:

> Given (the declaration File_Name_Copy : Heirarchical_File_Name;)
> if we were to replace the statement
>
> This_Delimiter := Delimiter(File_Name'Class(File_Name));
>   (he presumably meant to say:
> This_Delimiter := Delimiter(Heirarchical_File_Name_Type'Class(File_Name));
>   )
>
>    with
>
> File_Name_Copy := File_Name;
> This_Delimiter := Delimiter(Heirarchical_File_Name_Type'Class(File_Name_Copy));
>
> the call on Delimiter would no longer redispatch based on the
> tag of File_Name.  The assignment to File_Name_Copy throws away
> the tag of File_Name, and the call on Delimiter always dispatches
> to the Heirarchical_File_Name_Type version of the function.

I believe that your assignment

>    Op_Table : array (Opcode) of Op_Root
>     := (Op_Root (O0),
>         Op_Root (O1),
>        etc
likewise throws away the tags of the things copied into spots in
Op_Table, and the call on
>       Func (Op_Root'Class (Op_Table (IR)));
always dispatches to the Op_Root version of the function.
  I think we have here both an error in Gnat and an error in
Cohen's book!

> It is also obvious my code wouldn't work if the derived types
> added components.
Exactly.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

tmoran@bix.com wrote:
> 
> > This_Delimiter := Delimiter(File_Name'Class(File_Name));
> >   (he presumably meant to say:
> > This_Delimiter := Delimiter(Heirarchical_File_Name_Type'Class(File_Name));
> >   )

Another of the many minor mistakes in what is still an excellent book.


> > The assignment to File_Name_Copy throws away
> > the tag of File_Name, and the call on Delimiter always dispatches
> > to the Heirarchical_File_Name_Type version of the function.

That makes sense.

If I Initialise the array like so:

   Op_Table : array (Opcode) of Op_Root 
     := (0 => Op_Root (O0),
         others => OU);

then make the assignments:
    Op_Table (1) := Op_Root (O1);
    Op_Table (2) := Op_Root (O2);
    Op_Table (3) := Op_Root (O3);

I get the output:

opcode 00
undefined opcode
undefined opcode
undefined opcode
undefined opcode

What is going on here?
It look like the assigments throw away the tag (like Cohen
says it should) but the initializer keeps the tag.
Indeed the RM says in section 3.9 (22):
"The tag of an object of a class-wide tagged type is that of its
initialization expression. "
The trouble is Op_Table components are not of a class wide type.

Instead section 3.9 (20) applies:
"The tag of a stand-alone object, a component, or an aggregate of a
specific tagged type T identifies T"


>   I think we have here both an error in Gnat and an error in
> Cohen's book!

Unless somebody can show me where the RM says otherwise, I agree.
I guess I'd better report this.

Thanks for the enlightenment.
Cheers
Geoff

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Tucker Taft]

Geoff Bull wrote:
> 
> If I Initialise the array like so:
> 
>    Op_Table : array (Opcode) of Op_Root
>      := (0 => Op_Root (O0),
>          others => OU);
> 
> then make the assignments:
>     Op_Table (1) := Op_Root (O1);
>     Op_Table (2) := Op_Root (O2);
>     Op_Table (3) := Op_Root (O3);
> 
> I get the output:
> 
> opcode 00
> undefined opcode
> undefined opcode
> undefined opcode
> undefined opcode
> 
> What is going on here?
> It look like the assigments throw away the tag (like Cohen
> says it should) but the initializer keeps the tag.

That would be a bug.  The tag is *not* determined by the initial
value if the target type is "specific" (as opposed to classwide).
The tag *is* determined by the initial value if the target type is classwide.
 
> Indeed the RM says in section 3.9 (22):
> "The tag of an object of a class-wide tagged type is that of its
> initialization expression. "
> The trouble is Op_Table components are not of a class wide type.
> 
> Instead section 3.9 (20) applies:
> "The tag of a stand-alone object, a component, or an aggregate of a
> specific tagged type T identifies T"
> 
> >   I think we have here both an error in Gnat and an error in
> > Cohen's book!
> 
> Unless somebody can show me where the RM says otherwise, I agree.
> I guess I'd better report this.

Definitely a bug.  It looks like GNAT is copying the tag from the initial value,
which it shouldn't do in this case.
> 
> Thanks for the enlightenment.
> Cheers
> Geoff

-Tucker Taft  stt@averstar.com

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

Tucker Taft wrote:
> 
> Geoff Bull wrote:
> >
> > If I Initialise the array like so:
> >
> >    Op_Table : array (Opcode) of Op_Root
> >      := (0 => Op_Root (O0),
> >          others => OU);
> >
> > then make the assignments:
> >     Op_Table (1) := Op_Root (O1);
> >     Op_Table (2) := Op_Root (O2);
> >     Op_Table (3) := Op_Root (O3);
> >

> >
> > What is going on here?
> > It look like the assigments throw away the tag (like Cohen
> > says it should) but the initializer keeps the tag.
> 
> That would be a bug.  The tag is *not* determined by the initial
> value if the target type is "specific" (as opposed to classwide).

> 
> Definitely a bug.  It looks like GNAT is copying the tag from the initial value,

I worked out exactly what is happening.
The bug is in aggregate assignments to an array or a record
of tagged components. I.e. I can later change the tags
in Op_table by making an aggregate assignment to it.

Also, if I don't initialise Op_table, it seems the tags in it are 
not initialised either. This seems wrong to me too, but I am just
guessing in this case.

Geoff

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Robert Dewar]

In article <38E621C2.87B64ED9@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> > What is going on here?
> > It look like the assigments throw away the tag (like Cohen
> > says it should) but the initializer keeps the tag.
>
> That would be a bug.  The tag is *not* determined by the
> initial value if the target type is "specific" (as opposed to
> classwide). The tag *is* determined by the initial value if
> the target type is classwide.

I certainly agree, and so, for all the examples I tried, does
GNAT, so I am not exactly sure what program Geoff is running
here! Part of the trouble is that if you don't have the exact
complete text, there can be confusion.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: C/C++ programmer giving Ada95 a chance -- writing an emulator.

[Geoff Bull]

Robert Dewar wrote:
> 
> In article <38E621C2.87B64ED9@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:

> > That would be a bug.  The tag is *not* determined by the
> > initial value if the target type is "specific" (as opposed to
> > classwide). The tag *is* determined by the initial value if
> > the target type is classwide.
> 
> I certainly agree, and so, for all the examples I tried, does
> GNAT, so I am not exactly sure what program Geoff is running
> here! Part of the trouble is that if you don't have the exact
> complete text, there can be confusion.

The complete text is hidden somewhere in this thread!
I used gnat 3.12p with the same results on two platforms.
Maybe this is fixed in 3.13?
Anyway, I have put in a bug report which demonstrates the problem.


Cheers
Geoff