Re:
> $CONTROL USLINIT
> BEGIN
>   INTRINSIC PRINT;
>    BYTE ARRAY OUT(0:12);
>    PRINT(OUT, -MOVE OUT:="Hello World!", 0);
> END.
>
> I don't get the warning on the PRINT now.

Really?  I do!  (And, you should!)


> I don't understand why it expects a word array when the documentation -
> http://docs.hp.com/en/32650-90821/ch04s177.html
>
> says it's a "character array".  Isn't that a byte array?

Ah...you're being misled by bad documentation.  When HP wrote the
Intrinsics manual for MPE XL (now MPE/iX), they give short shrift
to the CM intrinsics.   If you can find a Classic MPE Intrinsics
manual, you'll see PRINT declared something like:

   procedure PRINT (
      message              : ref   logical array,  ! Q - %6
      length               : value integer,        ! Q - %5
      control              : value integer);       ! Q - %4

...note that "logical array"...that's the real definition of that
paramter for *CM*.

BTW, consider:
   $control uslinit
   begin
     intrinsic print;
      byte array out(0:12);
      print(out (1), -move out:="Hello World", 0);
   end.

(Hmm...somewhat similar to the deprecated UCSD Pascal style of indenting
the contents of the begin/end ... I much prefer indenting the begin/end *and*
the contents.)

Note the minor difference to the version you posted ... the print
is passed "out (1)" as the first parameter.  Since "out" is a byte
array, and "print" expects a logical array, the SPL compiler will emit
an arithmetic shift right to try to convert it to a halfword address
(Note: older terminolgy is "word address", when our "words" were 16-bits.
With the advent of 32-bit PA-RISC, we say "word" when we're discussing
32-bit items in NM, halfword for 16-bit items, and byte for 8-bit items;
when discussing SPL (or other CM languages), we look puzzled, and say
either halfword or word :)

If the above is compiled/prepped/run in CM, the output is:

   Hello World

If the above is compiled/linked/run in NM (using our SPLash! compiler),
the output is:

   ello World       (plus one more character)

Why?  Because the NM PRINT intrinsic is defined to accept a byte address,
so SPLash! properly doesn't convert it to a halfword address ...
*and* the NM PRINT reallllllly does implement byte addresses properly,
and starts precisely where you told it to start, not rounded down to
the nearest halfword boundary.  (Whether or not it should have rounded
down, to maintain compatibitly with the Classic and CM is another issue.)

Common naming conventions:

   buf   ... array (the name should guide you to the type, if it matters)
   buf'l ... logical array
   buf'i ... integer array (16-bit integer)
   buf'd ... double array (32-bit integer)
   buf'  ... byte array

If you see buf'l and buf' in a program, you *KNOW* that they're equated
to the same storage area ... if they aren't, fire the programmer.

You don't want:

   l'buf, i'buf, d'buf, b'buf (which is similar to the Microsoft philosophy)

for two very good reasons:

  1) they sort into different places if you get a cross reference of your
     source code.  (buf', buf'i, ... all sort together)

  2) what's more *important*, the fact that it's "buf" of some kind,
     or the fact that it's a byte array or double array?
     (Answer: that it's a "buf" of some kind, of course :)
     So, make the important part come first!

Stan
--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *