HP3000-L Archives

January 1997, Week 2

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:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Thu, 9 Jan 1997 15:21:25 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
Hi all,

Several people asked me:
> Why to you place "big" vars first.

The following applies to Pascal/iX ... other languages use different
strategies for assigning addresses to variables...

First, there's a hardware constraint that limits most load/store
instructions to an offset of 8191 bytes ... this means that if you
have a register (like DP (or R27)) pointing to a block of data, you
can access any byte from register-8192 to register+8191 with a single
load (or store) instruction.  Any byte further away (e.g., register+9000)
requires two instructions.

For outer-block variables, Pascal/iX allocates the variables in ascending
offsets from DP.  Thus, you generally want all your small variables
first, and then all larger variables.  Otherwise, if your first outer block
variable was "var buf : string [8192]", then EVERY other outer block
variable will require 2 instructions to access.

For procedures, Pascal assigns addresses as increasingly smaller
negative offsets from SP...so the last 8191 bytes allocated are efficient
to access.

For the example program's "test" procedure, here's how the compiler
allocated the local variables:

     BUFFER                VARIABLE     ARRAY            SP-  3F8.0 (200.0)
     CC                    VARIABLE     INTEGER          SP-  1F8.0 (4.0)
     ERR16                 VARIABLE     SHORT INTEGER    SP-  1F4.0 (2.0)
     FID                   VARIABLE     SHORT INTEGER    SP-  1F2.0 (2.0)
     INFILENAME            VARIABLE     ARRAY            SP-  1F0.0 (51.0)
     LEN                   VARIABLE     INTEGER          SP-  19C.0 (4.0)
     NEXTCHAR              VARIABLE     CHAR VALUE       SP-  198.0 (1.0)
     NUM_BYTES             VARIABLE     INTEGER          SP-  194.0 (4.0)
     NUM_LINES             VARIABLE     INTEGER          SP-  190.0 (4.0)
     TOTAL_BYTE_COUNT      VARIABLE     INTEGER          SP-  18C.0 (4.0)

If the declaration where "buffer" was declared was changed to be:

  var
     slow : integer;
     buffer  : packed array [1..8192] of integer;      <--- bigger than before

then "slow" would be more than 8192 bytes below SP, and therefore require
2 instructions to access.


  My understanding is that the most
> commonly accessed vars should be placed first (if you'll end up
> exceeding 8192 bytes of storage).

For outer block, yes ... but not just "commonly accessed".  If you
have an array of 9000 bytes, I'd still put it after all the smaller
variables (or "before" in a procedure), because if you put it first
(or last in a procedure), then NONE of the other variables would be
efficient to access.

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

ATOM RSS1 RSS2