Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1686 > unrolled thread

Beyond binary compatibility

Back to article view | Back to comp.arch

Contents

  Beyond binary compatibility "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-19 02:47 -0700
    Re: Beyond binary compatibility torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-19 12:49 +0200
      Re: Beyond binary compatibility Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-19 18:33 +0200
        Re: Beyond binary compatibility "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-19 10:50 -0700
    Re: Beyond binary compatibility MitchAlsup <MitchAlsup@aol.com> - 2011-05-19 09:40 -0700

#1686 — Beyond binary compatibility

It seems that there are some areas of incompatibility which 
are easier to handle than others.  E.g., an ISA with the 
same semantics as another would be easier to automatically 
translate, especially if the instructions are the same 
size.  (For x86, an 'extension' which further constrained 
the ordering of prefixes to allow some prefix sequences 
to encode new semantics might be somewhat easily handled.  
A compatibility mode could trap on encountering improper 
prefix ordering.  [As long as instructions were not used 
as data and the program never jumped into the middle of an 
instruction, such would allow full compatibility.]  One 
might also be able to reclaim some no-ops and other 
instructions [e.g., subtract self for register clearing 
when xor self is the preferred form].  There might also be 
some opportunity for simplifying instruction decoding.)  
This might be called "instruction reencoding" to 
distinguish it from the more general "binary translation".

There might be some advantage to being able to translate in 
place at the granularity of instructions in the old ISA.  
If the new ISA provided instructions that were usually not 
larger than the old ISA, it might be practical to insert 
trap instructions where the new ISA cannot be translated.

Being able to introduce minor incompatibilities (e.g., 
removing the recently mentioned no-op semantics of shift 
by zero in x86) might facilitate minor improvements in 
later implementations while not being exceedingly 
difficult to manage a migration of software.  (There 
might be some software which actually depends on the 
no-op semantic of shift by zero, but I am guessing that 
a lot of software could be proven, with limited overhead, 
to not rely on this behavior.)

Isolating incompatibility exclusively to 'system' code 
can also significantly ease a transition to a new ISA, 
especially if the organization providing the ISA also 
provides or provides significant help in maintaining 
the system code.

Semantic-performance compatibility (where translation 
may involve a change in instruction count and/or size 
but performance is not greatly impacted) would be more 
difficult to manage, but such would provide much 
greater flexibility in making changes.  Examples of 
such might be support for saturating arithmetic and 
support for 80-bit FP.  (It is disappointing to me that 
80-bit FP was not moved into SSE, allowing the more 
rapid deprecation of x87.)

Endian compatibility might simplify some transitions.

Memory consistency model compatibility might be 
especially important.  Transitioning to a stronger 
ordering would generally be easy, but moving to a 
weaker ordering could be painful (even if memory 
operations include acquire/release indicators as in 
Itanium).  Unlike typical instruction semantics, the 
required ordering is not localized in the program.
It might be practical to provide weaker ordering on 
a larger scale and stronger ordering on a smaller 
scale (e.g., cores might grouped into clusters that 
support inexpensive strong ordering and legacy code 
could be run within such clusters or use more 
expensive/lower performance support for strong 
ordering outside the cluster).

It seems to me that more rapid Architectural 
transition should be possible.  Unfortunately, such 
accelerated transition would require cooperation 
between the providers of hardware and the providers 
of system software (including JIT compilers).

[toc] | [next] | [standalone]

#1688

"Paul A. Clayton" <paaronclayton@gmail.com> writes:

> It seems that there are some areas of incompatibility which 
> are easier to handle than others.  E.g., an ISA with the 
> same semantics as another would be easier to automatically 
> translate, especially if the instructions are the same 
> size. [...]
>
> There might be some advantage to being able to translate in 
> place at the granularity of instructions in the old ISA.

This is what Intel did in the transition from 8080 to 8086: 8086 was not
binary compatible, but you could do an instruction-by-instructions
translation that didn't expand the code size, so you could preserve
addresses.

In any case, it is in most cases not too difficult to find the branch
targets by analysing code, so translation that doesn't preserve
addresses is usually O.K.  And in the cases where this isn't enough, you
can construct a table that translates old addresses to new addresses and
use this at runtime for computed and indirect jumps.  This, obviously,
requires that you don't combine two or more instructions in the old code
to one instruction in the new code, reorder instructions, and so on.
This might reduce the efficiency of the translated code, but probably
not by a lot.

Instead of keeping a table, you can do the normal branch-target
ananlysis and translate all branches to known target normally but also
keep a (hashed) table that maps the known old branch targets to new
addresses.  If there is an indirect jump, you look up in this table.  If
you get a hit, you jump, but otherwise you translate a basic block
starting at the previously-unknown branch target and add this to the
code.

	Torben

[toc] | [prev] | [next] | [standalone]

#1695

Torben Ægidius Mogensen wrote:
> "Paul A. Clayton"<paaronclayton@gmail.com>  writes:
>> There might be some advantage to being able to translate in
>> place at the granularity of instructions in the old ISA.
>
> This is what Intel did in the transition from 8080 to 8086: 8086 was not
> binary compatible, but you could do an instruction-by-instructions
> translation that didn't expand the code size, so you could preserve
> addresses.

I think this is partly wrong: I.e. I don't believe the translated asm 
code generated exactly the same code size, but as long as the source 
program used symbolic jump targets, this didn't matter.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#1697

On May 19, 11:33 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
> Torben Ægidius Mogensen wrote:
> > "Paul A. Clayton"<paaronclay...@gmail.com>  writes:
> >> There might be some advantage to being able to translate in
> >> place at the granularity of instructions in the old ISA.
>
> > This is what Intel did in the transition from 8080 to 8086: 8086 was not
> > binary compatible, but you could do an instruction-by-instructions
> > translation that didn't expand the code size, so you could preserve
> > addresses.
>
> I think this is partly wrong: I.e. I don't believe the translated asm
> code generated exactly the same code size, but as long as the source
> program used symbolic jump targets, this didn't matter.


That's correct.  Not only are 8086 longer on average, a fair number of
8080 instructions required short sequences of 8086 instructions to
replace.  For example, 8080 had conditional call and return
instructions, those obviously need two 8086 instructions, likewise
conditional branches on 8080 allowed 16 bit addresses, which needed a
two instruction sequence if the target was not within the 8-bit
*displacement* range for 8086.  A number of other instructions
required multiple instructions in the translation, at least one (DAD*,
I think) requiring as many as five if you actually wanted the exact
8080 flag semantics preserved.

BTDTGTTS.


*The 8080 16 bit add altered *only* the carry, so you'd end up with
something like LAHF / ADD / RCR / SAHF / RCL

[toc] | [prev] | [next] | [standalone]

#1694

With respect; actual compatability will sell lots more chips that
almost compatability. If for no other reason that Fear Uncertanty and
Doubt.

Mitch

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web