Image Map Image Map
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 22

Thread: Check for 386+ cpu in assembly.

  1. Default

    Quote Originally Posted by Chuck(G) View Post
    I don't have a 186 system (who does?) to see how the 186 behaves with the SGDT instruction. So there's that.

    Just checked--you get a type 6 "illegal instruction" interrupt. So add another test to separate the 186 from the 286+ (i.e. use bit 15 in the flags register =1 on 186; =0 on 286). or just grab the "illegal instruction trap).
    The 186 also pushes the value of SP after it has been decremented, just like the 8086/88 (tested it on a HP 200LX, not exactly rare).

    SMSW, SGDT and SIDT should all work to distinguish 286 vs. 386, undefined bits will all be set on the 286.
    This seems to me like the best way since you don't need to install an exception handler.

  2. #12
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,368
    Blog Entries
    18

    Default

    Thanks--that explains why nobody ever complained about my code for that even after 12 years in the field...

  3. Default

    Thinking about it some more, the GDTR is not used at all in real mode and might contain garbage left over from the BIOS. And in V86 mode with paging enabled, both the GDT and IDT could conceivably be at FFxxxxxx, causing your code to assume it is running on a 286 processor.

    Looking at the MSW / low half of CR0 doesn't have this problem, and the code is also shorter. Might have been risky to rely on this in the past, but now that these bits have been reserved for over 30 years, we can assume they are never going to be used for anything

  4. #14
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,368
    Blog Entries
    18

    Default

    It would be interesting to try to see if V86 mode fakes my code, but even so, the erroneous assumption that an 80286 was present wouldn't have broken the code in my application, where 32-bit registers were being used for computation as a speedup over 16 bit. I'm pretty certain that I tried it under Window NT DOS emulation, however--that was my standard development platform for years.

    Besides, the behavior WRT to reserved bits is documented in the Intel instruction references.

    Just goes to show you that there's more than one way to skin a cat...

  5. #15
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,546
    Blog Entries
    1

    Default

    Quote Originally Posted by codyw1996 View Post
    i'm looking for a simple test to determine if a 386+ cpu is installed.
    I just need a simple binary test. Is it internally a 32-bit cpu? Yes or no?
    I'm curious, why are you looking for this?
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  6. Default

    Quote Originally Posted by Chuck(G) View Post
    It would be interesting to try to see if V86 mode fakes my code, but even so, the erroneous assumption that an 80286 was present wouldn't have broken the code in my application, where 32-bit registers were being used for computation as a speedup over 16 bit. I'm pretty certain that I tried it under Window NT DOS emulation, however--that was my standard development platform for years.

    Besides, the behavior WRT to reserved bits is documented in the Intel instruction references.

    Just goes to show you that there's more than one way to skin a cat...
    I didn't remember that SGDT always stores zero in the high byte when used with a 16-bit operand. So you are correct, the detection code works regardless of what is actually in that register.

    As for my code, I actually don't have a real 386 to test it on, and I have just now stumbled on this comment that the reserved bits behave the same as on the 286:

    http://www.os2museum.com/wp/icebp-fi...comment-346613

    If this is the case, Intel's manual is blatantly wrong:

    14.8.4 MSW Initialization

    The 80286 initializes the MSW register to FFF0H, but the 80386 initializes
    this register to 0000H. This difference should have no effect, because the
    bits that are different are undefined on the 80286. Programs that read the
    value of the MSW will behave differently on the 80386 only if they depend on
    the setting of the undefined, high-order bits.
    Conclusions
    * Use SGDT, not SMSW
    * Always test your code on real hardware

  7. #17
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,368
    Blog Entries
    18

    Default

    And one can only assume, absent testing on real hardware, that this stuff works on the x86 "clone" architectures, such as Transmeta, VIA, etc.

  8. #18

    Default

    Quote Originally Posted by Trixter View Post
    I'm curious, why are you looking for this?
    It's the first procedure in a program that will transition to protected mode.
    It's a real mode DOS program that happens to also be a 32-bit kernel.
    I've made a lot of progress. I have a working 386+ test, a20 gate enabler, pic reinitializer, and i'm working on setting up my own IDT.

    I want access to linear memory, and I prefer to own the computer by loading my own GDT.
    I don't want to cuck to some other developer and be forced to use a Local descriptor table, if I can't own it, there's no point. I'd rather just error out.

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

    Default

    So "unreal mode"?

  10. #20

    Default

    Quote Originally Posted by Chuck(G) View Post
    So "unreal mode"?
    Real nigga mode maybe.

    I'm just kidding, it's gonna be protected mode, probably copied into high memory.
    Past DOS which might be in the UMB, I think.
    Gotta figure out that memory map at some point.

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
  •