Re: Layout Hell-o

From: JerryMouse (nospam_at_bisusa.com)
Date: 07/28/04 

Date: Wed, 28 Jul 2004 07:56:42 -0500

Carol wrote:
> I have seen that junk! I have cheated by fudging the starting
> poinsts of some of the translated fields.
>
> I see that I may have been on to something. Thank you for telling me
> why that is.
> !

He told you "what." Here's the "why" of "slack" bytes.

Early on, and continuing to this day, there were machines that had a marked
decrease in efficiency if some data fields were not on the proper
(half-word, full-word, double-word) boundary. The program must move these
mis-aligned fields to a proper alignment before they could be operated upon.

For example, assume the computer, in order to do binary arithmetic, could
load the register (where the binary arithmetic was to be done) only from a
memory location on a full-word boundary.

Extra code was generated by the compiler to move the binary-word argument to
a temporary full-word boundary in memory before the register-load
instruction. After the binary computation in the register, additional code
would have to be generated to take the result from the register and store it
in a temporary area then move it from the temporary area to its rightful
place in the program.

In days of yore (and sometimes today), COBOL programmers kept in the front
of their mind these hardware oddities. The compiler, itself, helped by
forcing all "01" level data names to full-word boundaries.

77-level data items in COBOL told the compiler to ignore this default
alignment. You'll see programs with tons of 77-level items in
Working-Storage instead of 01-level items for this original reason. In other
words, originally:

01 Data-A Pic X.
01 Data-B Pic X.
01 Data-C Pic X

took up 12 bytes of storage. Change the "01" in each to "77" and the same
set takes up only three bytes - because the 01-level forces the compiler to
begin the data element on a full-word boundary in memory.

Many of today's machines don't really care about byte alignment. They can do
binary arithmetic in situ, that is, memory-to-memory, without having to load
a register. There are other machines with hardware instructions to load
accumulators/registers without regard for byte alignment of the parameters.

Still, "slack bytes" will be with us forever.

"Slack bytes" are not to be confused with "expansion bytes" (areas stuck in
by the programmer for future use).

Relevant Pages

  • Re: checking if a floating point number is equal in value to an integer
    ... the value in the register is not exactly an integer, ... value stored in memory is an integer value. ... operations (and can be an issue on x86 if A is double). ... You can declare A to be VOLATILE (if your compiler supports ...
    (comp.lang.fortran)
  • Re: warning: read-write constraint -- 2.6.15-git8 onwards
    ... whether the compiler used there has an extra, ill patch (after all there's generally nothing wrong for a read-write ... constraint to only allow memory on x86). ... > It seems that the following commit causes a bunch of warnings out of ...
    (Linux-Kernel)
  • Re: volatile and multiple threads
    ... such that reading a register fetches the "next" input value. ... you don't want the compiler optimizing away ... If the memory address isn't ... ting systems will use volatile. ...
    (comp.lang.c)
  • Re: next mystery: 32 vs 64 bits...
    ... etc. Stack and register reorganization are always ... (this is not too much of a problem in my compiler, I just resort back to the ... given the newer way I am handling memory references (better ... 'on stack' typically, is not 'in memory'. ...
    (alt.lang.asm)
  • Re: can somebody help me with the problem with tasm models
    ... When Intel created the x86 originally, ... registers...now, when addressing memory with something like "", this ... valid...the rest aren't yet wired in and are ignored in memory addressing ... "offset" register, this would give a 20-bit address...if, in time, they ...
    (alt.lang.asm)