Legacy apps in Windows/OS X was Re: Old MS-DOS & Win Software
cclist at sydex.com
Wed Dec 7 22:14:15 CST 2005
On 12/7/2005 at 10:09 PM Allison wrote:
>Therin lies the truth of the matter. It's why the VAX11/780 happend,
>DGs machine Eclipse, and many others. The investment of software
>and the desire for "customer retention" are often drivers of
>technology choices. Its basic to even chipsets be they 8080 to 8088
>then on to 80286 and Motorola did the same with 6800, 6809 and 68K.
>Granted in many cases at the chip level they are not binary compatable
>the idea being everyone gets to keep what they learned and has an
>upgrade path. I don't think for one second that was missed in
I remember the Intel sales guy pitching the 8086 at us because we had an
8085. The nut of his pitch was that Intel had an automatic conversion
system that could take our ISIS-II 8080 assembly and convert it to run
flawlessly on the 8086/8088. I asked if I could bring a sample down to the
sales office and have a go at the converter. I'd bring a self-contained
program that generated verifiable results on the 8085 which could give me a
benchmark both on the performance and accuracy of the conversion.
What I brought was a BCD floating point package that approximated pi by
Euler's method. Not the most efficient, but something that could produce a
verifiable result (at least to 14 decimal places). About 3000 lines of
assembler, but then the package did more than the basic 4 functions.
Well, the converter cranked up and we had a cup of coffee while he told me
how wonderful the 8086 was. I'd done some reading myself and wasn't
exactly sold on the idea of segment arithmetic, particularly when it came
to addressing elements of a structure larger than 65K, but he showed me
that it was "only" 7 instructions to compute an address...
Three hours and much coffee later, the converter was still grinding. I
went home after the sales guy said that he'd let it run all night.
My call to him the next morning revealed that the converter had crashed
badly. He asked if he could take my code to an applicaton engineer who
might be able to figure out the converter bug. About 4 weeks later, I got
a call saying that the converter could now handle the whole shebang. I
went over to the sales office with my stopwatch and we got down to
business. The result on a 5 MHz 8086 took about twice as long to run as it
did on an 8085-5 and was more than twice the size. But the result checked
out--I suspect that the applications guy made sure of that. The big reason
for the poor performance was that the code was very tight and condition
code behavior had to be scrupulously preserved (e.g. on an 8085, a DCX
doesn't affect flags, but an 8086 DCR does, an 8085 DAD affects only the
carry flag, but an 8086 ADD affects all flags, etc.).
Heckuva way to make a sale. I thought that this would cinch the argument
for any other 16-bit processor (I liked the 68K a whole lot), but since we
had a VP from Intel on the board, we wound up with early (and very buggy)
samples of the 80186. I was very disappointed.
BTW, the selfsame floating point package wound up in Supercalc.
More information about the cctech