By: gallier2 (gallier2.delete@this.gmx.de), August 5, 2014 1:28 am
Room: Moderated Discussions
Maxwell (max.delete@this.a.com) on August 4, 2014 7:55 pm wrote:
> Obviously a typo, he meant 8080. Although the 8086 wasn't binary compatible with the 8080, you could
> convert 8080 assembly source code to 8086 with a simple translator (not that anyone did).
NEC's V20/V30 were binary compatible with 8080 and with 80186. They had a special trap instruction that put the CPU in 8 bit mode. There was also an instruction to get back in 16 bit mode. The segment registers were set before going in emulation mode. This would allow something like multiple virtual 8 bit machines. I don't know if it was used that way anywhere but it's fascinating to see what was possible at a time.
>
> Personally I think it's awesome how Intel has maintained 100% compatibility over the years,
> avoiding the temptation to take shortcuts. And the "baggage" can be useful sometimes, e.g.
> x86 has a coherent instruction cache for compatibility, which boosts JIT performance.
>
> Obviously a typo, he meant 8080. Although the 8086 wasn't binary compatible with the 8080, you could
> convert 8080 assembly source code to 8086 with a simple translator (not that anyone did).
NEC's V20/V30 were binary compatible with 8080 and with 80186. They had a special trap instruction that put the CPU in 8 bit mode. There was also an instruction to get back in 16 bit mode. The segment registers were set before going in emulation mode. This would allow something like multiple virtual 8 bit machines. I don't know if it was used that way anywhere but it's fascinating to see what was possible at a time.
>
> Personally I think it's awesome how Intel has maintained 100% compatibility over the years,
> avoiding the temptation to take shortcuts. And the "baggage" can be useful sometimes, e.g.
> x86 has a coherent instruction cache for compatibility, which boosts JIT performance.
>