Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom <quanstro@quanstro.net>]

> WRT to drawbacks in the loader for writing assembly, one of the
> biggest problems is merciless optimization that cannot be disabled on
> a per translation-unit basis (we're using a loader, remember?) As an
> example, it's damned near impossible to perform PC-relative branching
> in the vector table. Instead you end up having to the slower (and
> sillier) load method that exists today.

profiling can be disabled on a per function basis, so it would be
a small amount of effort confined to the linker to add a per-function
optimization disable. it would not require a change to the asm grammar,
as another bit in the profile-disable field could be used.

can you explain exactly what optimization that is causing trouble, and
do you have timing information on both methods?

> opcodes into the instruction stream. The exynos port relied on it
> heavily since the Cortex-A15 required a bit more special handling than
> the simpler cores in the omap, pi2, and teg2 ports. As you mentioned,

the typical case of adding an opcode is easy.  /n/atom/patch/applied2013/6l8laes
adds 4 opcodes with 7 lines in a table (with a comment and a blank line).
i see the arm refresh patch adds 12 to the analogous file in 5l.

but it also aliases R14 to LC and bubbles that change through (etc), which
may explain the line count.

> 5[al], libmach, even acid were updated. You really can't touch one

i was confused at first by this claim, since acid has not architecture-
dependent code.  but you mean /sys/lib/acid/arm, an acid script.
none of those changes were required by additional instructions.

thanks for the patch, btw!  i have made use of a number of parts of it.

- erik