HP3000-L Archives

March 1999, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank McConnell <[log in to unmask]>
Reply To:
Frank McConnell <[log in to unmask]>
Date:
Tue, 2 Mar 1999 21:44:58 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
Ted Ashton <[log in to unmask]> wrote:
> Not sure if this is an SPL or an FREAD question.  I'm calling FREAD from SPL
> and handing it the byte array WORK. WORK is defined in the globals
> (many) at the top of the program as BYTE ARRAY WORK(*) = WORKL and
> WORKL is defined previous to that as ARRAY WORKL(0:128).  If those
> definitions are near the top of the global definitions, it has a
> small address (I'm printing the value of @WORK in my debugging code)
> and seems to work beautifully.

FREAD expects you to give it a logical array, so hand it WORKL
instead of WORK.

At least for SPL on the classic (meaning I have no idea how this works
when Splash! and/or PA-RISC 3000s are involved), when you call an
intrinsic that expects a word pointer but give it a byte pointer, the
compiler inserts an arithmetic shift right (ASR) to convert the byte
pointer to a word pointer (and should give you a warning to tell you
that it's been so helpful).  ASR preserves the sign bit, so if the
value of the byte pointer is negative, so will be the value of the
word pointer.  (Also, if the byte pointer is odd (not word-aligned),
the least significant bit will get lost, so the resulting word pointer
will likely point one byte off from your byte pointer.)

-Frank McConnell

ATOM RSS1 RSS2