Semantics of .align pseudo-op

I have been investigating the semantics of the .align pseudo-op in an
effort to convince Sun to change their assembler. There seem to be two
distinct semantics in use, so I thought I'd solicit opinions from this
news group.


I'm concerned about using .align's within code sections. There have
traditionally been three locations for aligning code: function boundaries,
general code labels and loop top labels. In recent years, alignment has
been extended to handle architectural requirements for superscalar
sequences.


For purposes of discussion, assume the general semantics of .align are:
.align number
Advances the location counter until a "number" boundary is reached.


The semantics are differentiated by the choice of instructions used for
filling skipped space.


1) fillers are valid executable instructions with no side-effects, eg. NOP.
2) fillers are illegal instructions that terminate program execution.


I've looked at several systems to determine their behaviour. I believe
the RS/6000, Alpha, i860, R4000, i386/i486 and 68K assemblers use the
first choice. The Sun SPARC assembler and the HP-9000 series assembler
use the second definition.


The rationale for the first choice revolves around its use for aligning
loop top labels and superscalar sequences.


The rationale for the second choice revolves around its use for catching
errant programs that transfer control to invalid locations.


The definition I would prefer is based on the first choice. If the
assembler has done the analysis to detect that the filler region is in
unreachable code, then either definition is acceptable. Otherwise, use a
NOP (or equivalent). Note: Many of the systems above use different
instruction sequences for the filler code depending on the required length
or superscalar mix.
--
David L. Reese, Emulation Products SunSelect
Two Elizabeth Drive Chelmsford, MA 01824-4195 USA
david.reese@East.Sun.Com (508)442-0608 Fax:(508)250-5513
--

Return to the comp.compilers page.
Search the comp.compilers archives again.