Image Map Image Map
Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 38

Thread: What 8088 instructions work on segment registers?

  1. #11
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,646
    Blog Entries
    18

    Default

    Of course--and that was my gripe with 8086 35 years ago--I wanted an ISA that would make addressing large data structures simple--as simple as it was on the 68K.

    So, with a data structure consisting of 10,000 elements of 37 bytes each, what does the code look like to address any random element n in the 8086--and then in the 68K?

  2. #12
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,548

    Default

    Quote Originally Posted by Chuck(G) View Post
    So, with a data structure consisting of 10,000 elements of 37 bytes each, what does the code look like to address any random element n in the 8086--and then in the 68K?
    I'm not sure about 68k, but I believe the following would do it on x86. It's not hideous and I'm not sure you could avoid a multiply on any architecture since 37 is a prime. You'd have to add a lds to the below to indirect reference the base pointer if not static, but:
    Code:
    ; ax = array index on entry / byte result on exit
    ; di = byte offset into structure
    ; dx & bp are trashed on exit
    
    _lookup proc near public
    
     	push   ds
    
    	mov    dx, 37    ; could be made an input arg w/ a push/pop dx instead
    	mul    dx
    	add    ax, ds:[ARRAY_BASE]
    	adc    dx, ds:[ARRAY_BASE + 2]
    	push   dx
    	pop    ds
    	mov    bp, ax
    	mov    al, byte ptr ds:[bp + di]
    	xor    ah, ah
    
    	pop    ds
    
    	ret
    
    _lookup endp
    I'm not a strong x86 programmer anymore
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  3. #13
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,646
    Blog Entries
    18

    Default

    Well, you can avoid a multiply, but 37 reduced to shifts and adds is still pretty awkward. You don't need the push-pop DS; just stick the segment address into ES and use a segment override on the memory access instruction--and if you're not accessing stack space, any index register (BX, SI, SI) will work.

    The point is that you have to go through this with every memory access. Windows 2.0 had to really jump through hoops to make real-mode x86 code still work as the segments are descriptors.

    Since the 68K has a 24-bit flat address space with 32 bit registers, access is mostly a matter of multiplying the element by the element size and using the product as an index to the base address. You can address specific bytes within an element by using an immediate index: e.g. 5(A1,D3).

    In 1979, I could not understand how the 8086 could have been taken seriously with the 68K competition. I guess it was cheap and in ample supply.

  4. #14

    Default

    Pity IBM didn't use the 68K in the 5150. Didn't they almost do this though?

  5. #15

    Default

    Quote Originally Posted by eeguru View Post
    I may have missed the point, but after the 'add bp, 53', can't you just do a jc to the code that will re-normalize the segment/pointer pair? And by re-normalize, I mean just add 4096 to the segment and leave the offset alone. A conditional jump isn't as ideal as a nop. But it has to be better than re-normalizing after each increment.
    If you do this you will get an insidious bug. The 8086 discards the carry bit when computing the offset of an effective address instead of adding it to bits 16-19 of the physical address. So, suppose ES:BP==0x1000:0xffff. Then when you're accessing the last byte of your 53-byte record with [es:bp+52] you'll get the byte at address 0x1000:51 or physical address 0x10033 rather than the 0x20033 that you want.

  6. #16

    Default

    Quote Originally Posted by Chuck(G) View Post
    In 1979, I could not understand how the 8086 could have been taken seriously with the 68K competition. I guess it was cheap and in ample supply.
    Yes, and with the price of RAM being what it was, manipulating "big" (i.e. >64kB) datasets would have been a much rarer and more specialized activity than it was later, so I guess they thought the software hoops we'd have to jump through would be the least of our worries. Hindsight is 20/20...

  7. #17
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    553

    Default

    At the time, the 68000 was not available in quantity, and it was available only from Motorola (no alternative sources). I've heard that this is the reason the 68000 wasn't chosen for the IBM PC. The 8088 by comparison was available in quantity from Intel, and also from NEC.

    The 68000 is a nice CPU, arguably much nicer than the 8086/8088, but too often we are constrained to write software for the machine we have, rather than the one we wish we had.

    If the machine you have is an 8088, and you need to loop through 10,000 37-byte records, one simple way is to have an inner loop that processes 1000 records at a time (1000 37-byte records fits easily into a 64KB segment) then have an outer loop that runs the inner loop 10 times, updating the segment register each time. There are lots of options, anything that avoids updating the segment register needlessly is fine.

    -ken

  8. #18
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,646
    Blog Entries
    18

    Default

    Quote Originally Posted by cthulhu View Post
    Pity IBM didn't use the 68K in the 5150. Didn't they almost do this though?
    No, there was never any intention of doing that. What confused everyone back then was that IBM introduced the CS9000 lab computer at about the same time the 5150 was introduced. It spawned all sorts of rumors about IBM's new PC using a 68K, but that was it. I think that the CS9000 shares the 5150 keyboard, but that's about it.

    If it was a matter of 68K supply, arrangements, such as were very commonly done, could have been made to license a competitor with a large fab to take up the slack. The semiconductor business in 1980 was not a happy place.

    My own take is that IBM wanted something that would not have a hope of competing against their low-end commercial systems. That, IMOHO, was probably a reasonable short-term strategy, but really was doomed.
    Last edited by Chuck(G); May 16th, 2017 at 08:43 AM.

  9. #19
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    33,646
    Blog Entries
    18

    Default

    Quote Originally Posted by kgober View Post
    If the machine you have is an 8088, and you need to loop through 10,000 37-byte records, one simple way is to have an inner loop that processes 1000 records at a time (1000 37-byte records fits easily into a 64KB segment) then have an outer loop that runs the inner loop 10 times, updating the segment register each time. There are lots of options, anything that avoids updating the segment register needlessly is fine.
    You miss the point of the example. No one said that you processed items consecutively. Indeed, suppose that you were using the 10,000 entries as a lookup table.

    The segment register thing was barely better than many 8-bit bankswitching schemes. My view is that the 8086 was originally intended as an 8085 follow-on and used in embedded applications and not as a general-purpose CPU. Indeed, the 80186 seems to support this viewpoint.

  10. #20
    Join Date
    Apr 2015
    Location
    Austin, Texas
    Posts
    1,849

    Default

    Quote Originally Posted by reenigne View Post
    Yes, and with the price of RAM being what it was, manipulating "big" (i.e. >64kB) datasets would have been a much rarer and more specialized activity than it was later, so I guess they thought the software hoops we'd have to jump through would be the least of our worries. Hindsight is 20/20...
    The expense of implementing a 68000 motherboard was another factor. Instead of having to worry about an 8 bit data bus with a 16 bit address bus, you had a 16 bit data bus with a 24 bit address bus. The number of additional traces requires and other support logic would have made even a basic system considerably more expensive.

    Too bad Motorola didn't have the 68008 available at launch, it would have probably made it a more desirable part since it had an 8 bit data bus and a 20/22 bit address bus. It wasn't as fast as a full 68000, but was still much faster than all other 8 bit CPUs of the time.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •