On 5/24/2016 3:32 PM, Swift Griggs wrote:
On Tue, 24 May 2016, Fred Cisin wrote:
(OB_Picky: Due to the overlap of segment and
offset, on machines that had 21
address bits, real mode actually had a maximum of 1114096 (10FFF0h) bytes,
instead of 1048576 (100000h).
This was always the biggest pustule on the facade of x86 to me. Gate A20
and other chicanery was nasty business. It always struck me as a hardware
hack to work around earlier bad design. Sure, you can eschew segmentation
and try to use multiple instructions to delivery some flat addressing, and
then your code was snail-slow. Real mode in 16 bit on x86 was/is some
fairly vulgar stuff due to segmentation (hate hate hate). Then it was made
"all better now" by protected mode and segment descriptors later *pat
pat*. Yeah. Ugh. Pleah. Ick.
I think Windows made it big because they could handle the flat 386 model
and dos did not.
All that fun sent me running into the arms of the M68k
and it's git, and
later MIPS (queue hallelujah chrous from the clouds). I'm not a MIPS god
(we have a some here), but much love and respect to the architecture
nonetheless. I know enough to know "that's the good stuff". Nowadays I
wonder, since I'm using flat memory on the Unix boxes I code in (now
pretty much just in C, I haven't done ASM in a long while), what kind of
masochist maintains the SLAB/SLUB allocators for x86 Unix variants these
days. I want to buy them a six pack, pat them on the back, and say "you're
a braver man than, I."
I never could buy the RISC argument of being a faster design.
Data access to main memory is allays what slows a system down.
-Swift
Still playing around with TTL macros with Altera FPGA here,
planning mid 1970's TTL CPU. The cleanest version so far
is 2 -16 LS bit ALU boards and 1 control card. This gives
me a CPU with 2 sizes of data - BYTE and WORD and a WHOPPING
5 registers. PC, AC1 , AC2 , INDEX , STACK.
No risc here, just a simple CPU.
Ben.
PS: NO blinking lights sadly.