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: <2690.UUL1.3#5129@willett.pgh.pa.us> Date: 28 Apr 91 21:26:49 GMT Organization: (n.) to be organized. But that's not important right now. Lines: 128 Category 10, Topic 36 Message 20 Sun Apr 28, 1991 R.BERKEY [Robert] at 05:23 PDT ---------------------------------------------------------------------- Essay on X3.J14 Address Alignment "Imposing an even-address alignment requirement could simplify an architecture's implementation, but only at the expense of more difficulty for the programmer (and compiler), and reduced efficiency of memory utilization for data and instruction storage. For example, consider a record declared to contain two elements, one of which is byte-sized and the other word-sized." (Colin Hunter, _National Semiconductor Series 32000 Programmer's Reference Manual_, Prentice-Hall, Englewood Cliffs, NJ: 1987.) Forth-83 specifies that @ ! and +! work independently of underlying machine architecture. The X3.J14 committee puts forth that there are machine architectures for which implementors cannot provide optimally-efficient memory-access operators within the scope of the Forth-83 standard. X3.J14 proposes to redefine the memory-access operators such that @ ! and +! are, at the implementor's option, functions of the underlying machine architecture. However, exposure of programs to the underlying machine architecture means that there are addresses which if accessed result in failure of the program. So, the introduction of these new definitions of @ ! and +! brings the addition of the words ALIGN and ALIGNED to the Core word set, and a set of procedures which programs must follow involving ALIGN and ALIGNED . ------------------------ This proposal has multiple problems. (1) Absence of technical necessity This change may be seen as a "naming jealously" issue--there exists no technical necessity for the change. (I define "naming jealously" as the bias of Forth standard's committees to prefer to "fix" an existing function rather than also add to the task the problem of getting concensus on a new name.) (2) Existing code would be broken The X3.J14 proposal would break numerous Forth programs ("broken code" is that which is compliant with the previous standard, but which is non-compliant with the new standard, and thus can no longer be relied upon to port between Standard Systems). (3) Conflicting implementation alternatives Implementors on systems with memory-access limitations are presented with the issue of choosing between: (3A) speed-optimized @ ! and +! (3B) space-efficient, bus-error free, Forth-83 compatible @ ! and +! (3C) providing both sets of operators, with the names @ ! and +! assigned to (3A) definitions (3D) providing both sets of operators, with the names @ ! and +! assigned to (3B) definitions. These last two elections add the issue of what names to assign for the alternate set of operators. Some architectures don't have memory-access limitations, but aligned- address access has some efficiency benefits. On these systems, implementors will have unclear decisions regarding ALIGN and ALIGNED . Should ALIGN and ALIGNED be (3E) immediate noops and space-efficient, or (3F) active operations? (more considerations--the time it takes to execute ALIGN and ALIGNED may well result in less overall program speed efficiency than the benefit gained from bus alignment) (4) Chaotic impact on standard/common programming technique. The (3F) implementation alternative provides defacto encouragement to programmers to use non-standard programming technique for routine implementation-specific coding. For machine architectures not listed above, ALIGN and ALIGNED will be immediate noops. It seems unrealistic to anticipate that implementors; on either these systems; or for (3B), (3D), or (3E) systems; will encourage programmers to use standard programming technique; and that all Forth programmers will begin using such technique. (5) Loss of entitlement to space-efficient programs Under the new BASIS definitions, space-efficient programs can be designed only with considerable speed-efficiency loss in implementing the Forth-83 style definitions in high level. (6) Taxation without representation While Standard Programs must carry the burden of coding for the new technology, implementations may choose or need to remain Forth-83 compatible: so BASIS doesn't guarantee programs to the benefit of the new technology. ---------------------- All because of a few names. X3.J14 should provide new names for the new operators. This gives clear guidance to implementors, and also allows programmers to optimize for either space efficiency or execution efficiency. All of the problems cited above are eliminated. ---------------------------------------------------------------------------- ----- 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