Referencing Origin from Other Module or Unit

Product Version(s): 3.20
Operating System:   MS-DOS
Flags: ENDUSER | TAR17015 buglist3.20 fixlist3.30
Last Modified: 30-SEP-1988    ArticleIdent: Q10408

Problem:

In the following examples, I am trying to reference variables with the
origin (segmented address) attribute across compilation modules.
However, both fail to pass the origin. In the first example, I attempt
to use the unit/interface method; in the second example, I am
trying to reference the origin via modules with public/external
variables. The only way that I can successfully reference origin
variables across compilation units is to declare the variables with
matching-origin attributes in each compilation unit.

The following is a short sample code:

Example 1

   {$INCLUDE: 'yu.int'}
   program x(input,output);
   uses y;
   begin
   I := 13;
   subcall;
   WRITELN('FROM MAIN PROGRAM I, J AND K ARE: ', i:8, j:8, k:8);
   end.

   {$INCLUDE: 'yu.int'}
   implementation of y;
   procedure subcall;
   begin
   J := 33;
   WRITELN('USING SUBCALL: i, j and k are: ', i:8, j:8, k:8);
   end;

   begin
   K := 53;
   end.

   interface;
   unit y(i, j, k, subcall);
   var
   I[ ORIGIN 16#6000 : 16#0000 ] : integer;
   J [ ORIGIN 16#6001 : 16#0000 ] : integer;
   K [ ORIGIN 16#6002 : 16#0000 ] : integer;
   procedure subcall;
   begin
   end;

Example2

   program x(input,output);
   VAR [EXTERN] I, J, K : integer;
   procedure subcall;extern;
   begin
   I := 13;
   subcall;
   WRITELN('FROM MAIN PROGRAM I, J AND K ARE: ', i:8, j:8, k:8);
   end. {program x}

   module y;

   VAR I [PUBLIC,ORIGIN 16#6000:0000] : integer;
   J [PUBLIC,ORIGIN 16#6001:0000] : integer;
   K [PUBLIC,ORIGIN 16#6002:0000] : integer;

   procedure subcall;
   begin
   J := 33;
   K := 53;
   WRITELN('USING SUBCALL: i, j and k are: ', i:8, j:8, k:8);
   end;

   end. {module y}

Response:

The above examples actually constitute two completely separate
problems.

In Example 1, the variables are being allocated when the interface
was processed. They then were reallocated when the implementation was
processed and the origin forgotten.

Microsoft has confirmed this to be a problem in Version 3.20. This
problem was corrected in Version 3.30.

In Example 2, external variables are assumed to be in "ds"; there
is no way, in the examples, to indicate that they are origined (this
cannot work correctly). Versions 3.3x of the compiler will not allow
specification of origin and extern on the same object. However, simply
making them static will work properly because the actual address is
being explicitly specified.

If you want to access origined variables using the unit/interface
route, it is suggested that all origined variables be declared as such
in each module with matching allocation specifications. This procedure
can be easily accomplished by using the $include file facility.
