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

["Ken Garlington" <Ken.Garlington@computer.org>]

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