Memory Management/PIC 
Author Message
 Memory Management/PIC

Category 10,  Topic 36
Message 25        Sat Jun 01, 1991
R.BERKEY [Robert]            at 21:18 PDT

 Re: Address Alignment

S. Wheeler writes, 91-05-19,

 sw> Actually, though, ALIGN shouldn't have much effect on run-time
 sw> performance, since my understanding of it is that one would
 sw> normally use it at compile time.

In BASIS, ALIGNED must be used as a runtime operator, to match the compiled
ALIGNments.

 sw> In any case, 8086 processors take a performance hit (4
 sw> cycles/access) when making word accesses to odd addresses...
 sw> That may not make much difference, but I can just see a tight
 sw> timing loop changing because someone changed a name from WAIT to
 sw> DELAY :-).

Ho! is that a good point.  It's one the engineers here missed when they ported
the application from the 8085 to the 80186.  I've got an 80286 timing loop
whose time variation between an odd and an even alignment is 20%!  Here's a
note in my files for an F-PC running on an 80286 system:

 \ Alignment of code words, execution routines, and vocabulary tables
 \ costs about $C0 bytes, and on an 80286 increases compilation speed
 \ by 2%.

Robert

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Thu, 18 Nov 1993 22:09:39 GMT  
 Memory Management/PIC
Category 10,  Topic 36
Message 24        Sat Jun 01, 1991
B.RODRIGUEZ2 [Brad]          at 18:02 EDT

Well, as long as I'm being mentioned, I suppose I can respond...


LSI-11s, and such.  The problem with these CPUs is not just the 4-cycle
performance hit experienced by the 8086.  On the 68000 and LSI-11, word

have to be synthesized from two 8-bit fetch instructions.  Gag.

Also, judging by what I've learned recently in my architecture courses, this
problem is not going to go away.  Word access at odd addresses is a
significant hardware investment and has an unavoidable timing impact.  The
trend these days, what with RISCs and all, is to simplify the processor and
make the compilers smarter.

- Brad



-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Thu, 18 Nov 1993 22:09:37 GMT  
 Memory Management/PIC
Category 10,  Topic 36
Message 26        Sat Jun 01, 1991
R.BERKEY [Robert]            at 21:19 PDT

 Re: X3.J14 Address Alignment Proposal


is greater than the benefit in processor optimization.

The message, "Essay on X3.J14 Address Alignment" was a triggered by a
portability failure reported by Jack Woehr, in comments to John Wavrik, dated
91-04-23:

 jw>        John, WHAT ARE WE SUPPOSED TO DO?  We could say, "`Comma'
 jw> compiles six{*filter*} bits." WELL THAT DOESN'T EVEN WORK NOW!

 jw>        My co-worker came into my office to complain to me about my
 jw> Forth for the 80C196. Seems he had an application from our Forth for
 jw> the 80188 that had

 jw>        1234 , 34 c, 678 , 9999 ,

 jw> etc. scattered in an array. Of course it didn't run! The 80196
 jw> enforces word alignment on 16-bit quantities!

In the context of portability and address alignment, the issue here is what
the name , (comma) should do, rather than technical issues.  The point is that
there are two valid concepts, logical and physical access.

If it is inefficient to implement a logical fetch on a processor in assembler
code, it can only be more inefficient to implement it in high level.

Since physical-access addresses must be aligned, the savings for accesses
using a physical name versus that using a logical name, is the assembly code
for a bit test and a branch.

A while back I posted a Forth-83 Standard Program called QUOTE-TO.SCR, stated
that I was aware of aspects that were non-BASIS conforming, and challenged
readers to see if they could detect problems.  No one detected that the
program fails to force address alignment.  Also, it is an intermittent address-
alignment failure that is affected by previous compilation alignment, rather
than being a function of the data structure itself. In terms of conversion of
existing code, the X3.J14 address-alignment proposal falls into one of the
less-desirable categories that requires "human analysis" with "knowledge of
the program structure".

If the X3.J14 proposal is accepted:

For existing code rendered nonconforming, such as QUOTE-TO.SCR and the Vesta-
programmer's code, I think new names are needed for the logical accesses, but
without X3.J14 providing the leadership here, this is back to reinventing the
wheel.

"Essay on X3.J14 Address Alignment" has cited multiple problems:

 (1) Absence of technical necessity
 (2) Existing code would be broken
 (3) Conflicting implementation alternatives
 (4) Chaotic impact on standard/common programming technique
 (5) Loss of Standard Program entitlement to space-efficient programs
 (6) Costs to Standard Programs without benefits

However, the proposal is technically valid, and it can be used in a practical
manner to write portable code.  I do hope that analysts in the public review
will consider rejecting this proposal.

Robert

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Thu, 18 Nov 1993 22:09:42 GMT  
 Memory Management/PIC

Quote:
> In BASIS, ALIGNED must be used as a runtime operator, to match the compiled
> ALIGNments.

I disagree.  It is possible to perform the ALIGNED operation at compile time,
storing the result either in a constant or in a definition with LITERAL .

Here's how I do data structures:

   : STRUCT  0  ;


   STRUCT
      CHAR: >FIELDA
      CELL: >FIELDB
   CONSTANT /MYSTRUCT

   CREATE MYSTRUCT1  CHAR q C,  ALIGNED  1234 ,
   CREATE MYSTRUCT2  CHAR z C,  ALIGNED  5678 ,


   MYSTRUCT1 .MYSTRUCT
   MYSTRUCT2 .MYSTRUCT

This illustrates a fairly typical case in which alignment is required -
user-defined data structures with mixed-size fields.  All the alignment
is done at run time.  It can be done without the structure defining words:

   : .MYSTRUCT  ( adr -- )

   ;

Note that the ALIGNED step is again performed at compile time.

Mitch



Sun, 21 Nov 1993 00:21:17 GMT  
 Memory Management/PIC

 Date: 06-03-91 (12:21)              Number: 99 of 102 (Echo)
   To: B.RODRIGUEZ2 [BRAD]           Refer#: 81
 From: RAY DUNCAN                      Read: NO
 Subj: MEMORY MANAGEMENT/PIC         Status: PUBLIC MESSAGE
 Conf: FORTH (58)                 Read Type: GENERAL (+)

   >word access at odd address is flat-out illegal on the 68000

 That's true, but it has to be allowed I think if Forth code is to be
 portable.  In our CP/M-68K Forth systems (long since dead & buried) we
 took a compromise approach to this that didn't affect performance.  We

 operators use the "obvious" (i.e. word-oriented) MOVE instructions.
 However, we also captured exceptions that were caused by non-aligned


 appropriate byte-oriented MOVEs and resume execution.  This is a
 straightforward fix in a native Forth system or a Forth running under a
 dumb environment like CP/M-68K, but it is impractical in more complex
 environments since a lot of them won't let you handle these sorts of
 machine exceptions yourself.

 NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
 <<<>>>
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Wed, 24 Nov 1993 10:20:49 GMT  
 Memory Management/PIC
Category 10,  Topic 36
Message 29        Sat Jun 08, 1991
B.RODRIGUEZ2 [Brad]          at 14:17 EDT

Hmmm... reading Robert Berkey's comments, I'm beginning to believe that _all_
existing Forth code will be rendered nonconforming by the BASIS.  Does anyone
have (nontrivial) counterexamples?

I must admit I rather like Ray Duncan's solution to the problem.  I hadn't
thought of using the exception trap to resolve this problem. This is good for
68K and LSI-11; does the 80196 have such a trap?


I'm in the midst of converting a Super8 Forth from a RAM model to a register
model, and you wouldn't _believe_ how many words do memory reference.
Granted, many of them access stack (trivial to keep aligned) or threads (via
IP).  Should the dictionary (threads) be kept aligned, and not data?  This has
implications for those who would write IMMEDIATE words to extend the compiler
(e.g., no 8-bit branch offsets).

- Brad



-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).



Fri, 26 Nov 1993 02:06:53 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Memory Management/PIC

2. Memory Management/PIC

3. Memory Management/PIC

4. Memory Management/PIC

5. Memory Management/PIC

6. Memory Management/PIC

7. Memory Management/PIC

8. Memory and PIC

9. Memory and PIC

10. Memory and PIC

11. Read/Writes to memories/register files for PIC core

12. Moving a PIC X(20) to PIC S9(8)V9(2) COMP 3 field

 

 
Powered by phpBB® Forum Software