Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Memory Management/PIC
Message-ID: <2844.UUL1.3#5129@willett.pgh.pa.us>
Date: 2 Jun 91 14:09:42 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 74

Category 10,  Topic 36
Message 26        Sat Jun 01, 1991
R.BERKEY [Robert]            at 21:19 PDT
 
 
 Re: X3.J14 Address Alignment Proposal

My experience with a must-align @ is that the cost in programmer productivity
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 sixteen 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.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp