|Assembling span-dependent instructions email@example.com (2022-07-27)|
|Re: Assembling span-dependent instructions firstname.lastname@example.org (Kaz Kylheku) (2022-07-27)|
|Re: Assembling span-dependent instructions email@example.com (2022-07-28)|
|Re: Assembling span-dependent instructions firstname.lastname@example.org (2022-07-28)|
|Re: Assembling span-dependent instructions email@example.com (gah4) (2022-07-29)|
|Re: Assembling span-dependent instructions firstname.lastname@example.org (Kaz Kylheku) (2022-07-29)|
|From:||Kaz Kylheku <email@example.com>|
|Date:||Fri, 29 Jul 2022 22:36:03 -0000 (UTC)|
|Organization:||A noiseless patient Spider|
|References:||22-07-049 22-07-052 22-07-055|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="48733"; mail-complaints-to="firstname.lastname@example.org"|
|Posted-Date:||29 Jul 2022 19:01:02 EDT|
["Followup-To:" header set to comp.compilers.]
On 2022-07-28, email@example.com <firstname.lastname@example.org> wrote:
> In comp.arch Kaz Kylheku <email@example.com> wrote:
>> On 2022-07-27, Anton Ertl <firstname.lastname@example.org> wrote:
>> > However, one can also construct cases where making the code larger can
>> > reduce the minimum size of the immediate operand, e.g.:
>> > foo:
>> > movl foo+133-bar(%rdi),%eax
>> > bar:
>> That's weird; what is accessed this way, relative to the code,
>> and does it occur in compiler output?
> Code like this may appear due to alignment, say jump to page or cache
> line boundary. In realistic situation one is faced in much more
> compilex problem. Namely on many architectures best way to provide
> constant arguments is by storing constants in memory. This leads to
> "constant pools" and problem where to place them. One wants constant
> pools as close as possible to code, to use short offsets accessing
> them. But for performance reasons it is desirable to put constants in
> separate cache lines. Also, one needs jumps to jump around constant
> pools. Some jumps occur naturally in program, it is good to re-use
> them. But there are possible unused parts of cache lines (both for
> code and constant pools). So there is need to balance loss due to
> unused parts of cache lines (probably dominant factor), length of
> instructions and possible overhead due to extra instructions.
OK; so that makes sense. Say we have a program segment with
some PC relative references to a cache-aligned constant pool
which is farther down the program.
If this program segment shrinks, while the cache-aligned
constant pool stays where it is (to remain aligned),
then that pool will be farther away from some of those
This could even happen due to smaller alignments like 8 bytes.
Some instruction loses 4 bytes; then another one experiences
the data being 4 bytes farther than before, which now
> There is extra complication when machine has limited range of offsets
> which can be used in single intstruction: when needed offset exceeds
> allowed range one has to change to indirect form which needs free
> register. So there is extra interaction with registes allocation.
On an architecture that is not so register starved, you just
dedicate a register for that. MIPS calls it "at" ("assembler temporary").
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Return to the
Search the comp.compilers archives again.