Re: OT: horrible 8086 segmentation

On 26/11/2024 18:50, Charlie Gibbs wrote:

On 2024-11-26, Josef Möllers <josef@invalid.invalid> wrote:
 

On 25.11.24 18:33, mm0fmf wrote:
>

My eyes! My eyes! That was COMPACT model code, so 64k of code and 1MB of
data, code addresses were 16bit offsets to the CS reg and data was far
so 32 bits of segment and offset of DS or ES. And of course you had to
be extra careful of any pointer arithmetic as a far pointer wrapped
after 64k. You had to use slower HUGE pointers to get automatic
normalisation. God it was shit.

>
And to consider that, at that time, processors like MC68000 or NS32016
were readily available.

 Which proves once again that a shitty design beats a good one
if it's released first.
 Everybody was yapping about the 640K barrier.  I was more concerned
with the 64K barrier.  I remember manually normalizing pointers
everywhere, and if I wanted to work with a large arrays of structures
I'd copy individual structures to a work area byte by byte so I
didn't get bitten by segment wrap-around in the middle of a structure.
 As the joke goes, aren't you glad the iAPX432 died out?
Otherwise a truly horrible Intel architecture might have
taken over the world.
 

I found this when digging around...
"void KERNELsetvect(unsigned wVec, void far *pVect)
{
void far * far *pPtr ;
pPtr = (void far * far *) MK_FP(0x0000, wVec << 2) ;
*pPtr = pVect ;
}"
It simply looks so ugly.
ISTR trying to push to use 68000 or even 68E020 but 80186EB became the CPU of choice. It had lots of nice embedded features on chip and ran at 20MHz. And you could use PC development tools.
It's 26 years since I had to deal with this segmented rubbish and a lot of it I had forgotten or repressed!