[comp.lang.vhdl] Problem with overloading in layered packages

ll@cae780.csi.com (Lars Erik Lundberg) (05/16/91)

I have a problem where I want to avoid overloading in more than one place in a
layered package structure.

Let's say I have two types that are declared identically (but still different):

  type UNSIGNED is array (INTEGER range <>) of BIT;
  type TWOSCOMP is array (INTEGER range <>) of BIT;

They are declared in the package PACK1 together with a bunch of procedures that
are overloaded with respect to UNSIGNED and TWOSCOMP:

  procedure Move1 ( L : UNSIGNED; O : out UNSIGNED);
  procedure Move1 ( L : TWOSCOMP; O : out UNSIGNED);
  procedure Move1 ( L : UNSIGNED; O : out TWOSCOMP);
  procedure Move1 ( L : TWOSCOMP; O : out TWOSCOMP);

Then I have another package, PACK2, that declares a number of procedures using
calls to procedures in PACK1. Do I really have to deal with overloading in PACK2
as well? Such as:

  procedure Move2 ( L : UNSIGNED; O : out UNSIGNED);
  procedure Move2 ( L : TWOSCOMP; O : out UNSIGNED);
  procedure Move2 ( L : UNSIGNED; O : out TWOSCOMP);
  procedure Move2 ( L : TWOSCOMP; O : out TWOSCOMP);

and in the body:

  procedure Move2 ( L : UNSIGNED; O : out UNSIGNED) is
  begin
    Move1 ( L, O);
  end;

  procedure Move2 ( L : TWOSCOMP; O : out UNSIGNED) is
  begin
    Move1 ( L, O);
  end;

and so on ... 

>> I'm talking a large number of procedures with more than two parameters! <<

As in the example above, all procedure bodies with the same name in PACK2 would
be IDENTICAL (albeit not this simple). Overloading COULD happen solely in PACK1.

My first idea for a solution was something like:

  type FIXPOINT is array (INTEGER range <>) of BIT;
  type TWOSCOMP is FXP;
  type UNSIGNED is FXP;

and define procedures in PACK2 on FIXPOINT:

  procedure Move2 ( L : FIXPOINT; O : out FIXPOINT);

This doesn't work (otherwise you wouldn't be reading this). I've also tried
subtypes, but they only provide a new name for the type, not a new type.

Is there any way I can avoid this tedious overloading?

/Lars Lundberg  (ll@csi.com)