x8086 (04/19/83)
I stand corrected on few points made recently on the net concerning the
8086 64k segments, but not on all counts.
1.) Comparing pointers is not complicated. Claim: according to the 'C'
manual pointer math and comparisons are only valid on pointers that
point to the same data object. (var, array, structure). This means
that if you've done your assigns right; the compare only involves
the offset (a 16bit quantity). Easy enough. Null is a special
case compare (check if 32bit pointer == 0). And you desreve what
you get for anything else.
2.) handling multiple global data segments envolves basically two problems.
One, very large arrays ( >64k storage) will never fit and require special
and painfull code to access {I agree that in cases like this the 8086
shines with all the power of a black light}. Two, simple vars and small
arrays should be collected into as few segments as possible. The segment
registers need only to be reloaded when the variable you want is not in
the segment your working with. Optimally, this cuts out segment loading
all together. Usually though something will get split across the segment
boundry and cause a speed reduction not unlike thrashing (of segments not
pages this time.) The only go thing to say about this is that most
large 'C' programs usually don't declare large arrays, but malloc reasonable pieces one at a time. For chunck less than 64k no problem, otherwise
back to the above again.
3.) Large stacks can be implemented 'fairly' well on the 8086. To get all
of the memory into use requires about 12 extra instruction on each
entry (about 30bytes or 15words). Assuming you don't write lots of
recursive tiny little < 30us subroutines the trade off is not too
painfull. For the 186 and 286 with ENTER and LEAVE instructions this
isn't needed at all.
4.) The 8086 addressing mode structure and it's architecture are designed
with high-level languages in mind. Just go read the Intel manual and
they can tell you themselves. But, the 8086 is a upgrade of a 8bit
processor the 8080. This has put severe restrictions on the cpu that
don't go away. Also, it is a 16bit cpu and puting a large word language
like 'C' on it is going to cause problems. Some like addressing which
will be severe in somecases.
5.) I'm not claiming the 8086 is better than the 68000, z8000, or the
16000. You can't really compare the two groups since the 8086 is a
16bit cpu while the others are generally 32bit cpu's. The 68000 is
debatable on this point with it's horrible lack of 32bit mult or div.
As for using the 8086 in place of a VAX I would laugh too, but it can
be used for better things than cash registers. It's cheap, and will
support all the 8080 code in existance and reassembly and checking for
a few flag changes.
If anyone wants to see examples or code please send mail to me personally
and not to the general net and I will try to support my above claims as
best as possible without giving away our entire compiler. As for the
8086 vs. 68k , 16k , and z8k, I would much prefer to have a 16k from national
myself than a 8086 anyday. The z8000 is too undersupported, and the 68000
is good despite some annoying omissions that would have been nice to have
like true 32bit multipy or divide to go with the 32bit registers set.
Tim Tucker
mntvax!x8086
P.S. PDP-11's use segmentation yet they are still here and fairly popular.
Why? The software base is large and noone likes to throw away everything
and start over. Step by step cross overs are a little safer.