home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / ibm / pc / misc / 10923 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  4.6 KB

  1. Xref: sparky comp.sys.ibm.pc.misc:10923 comp.sys.ibm.pc.hardware:20491
  2. Path: sparky!uunet!noc.near.net!mars.caps.maine.edu!maine.maine.edu!ree700a
  3. Organization: University of Maine System
  4. Date: Tuesday, 28 Jul 1992 11:17:17 EDT
  5. From: <REE700A@MAINE.MAINE.EDU>
  6. Message-ID: <92210.111717REE700A@MAINE.MAINE.EDU>
  7. Newsgroups: comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
  8. Subject: 32 bit BIOS, etc. (was RE: 486/50'2 vs Sun 2's
  9. Lines: 76
  10.  
  11.   Somehow, the previous thread degenerated from a comparison to a speculation a
  12. bout 32-bit software, an over-hyped thing, given that it's all based on a real-
  13. mode bios!
  14.  
  15. +>perhaps this would have more to do with the key-repeat rate on the 486 ??
  16. +>also: a 486 running 32bit OS/2 2.0 programs is about 4 time faster on
  17. +>integer code ( let alone floating point ) than the same machine under dos.
  18. +>(ie: think about what you are actually measuring !!!)
  19.  
  20.    Maybe OS/2 avoids the DOS-bios (hence it's large size) but, 32-bit pointers
  21. don't inherently buy you anything except simpler segmentation (not to understat
  22. e the advantages to the developer there).  Otherwise, there is little or no sav
  23. ings between 32-bit protected mode pointers and 16-bit protected mode pointers.
  24. For that matter, given the BIOS problem, 16-bit real mode is probable faster wi
  25. thin it's MB area than either protected mode.  Alas, what runs in 1MB anymore?
  26.  
  27. +I can't see how this is possible.  I can see how recompiling stuff for
  28.  
  29.  
  30. +32-bit *might* make it up to twice as fast, but not 4 times as fast. Please
  31. +justify this.  I, myself, have ported DFLAT (the text mode user
  32. +interface lib from Dr. Dobb's Journal) and it's sample application,
  33. +to 32-bit extended dos and have noticed no speed increase at all.
  34. +And this code is full of far pointers.  I have seen some small, tight
  35. +programs (gif decoder code) that does not benefit at all from
  36. +32-bit.  The pointers are all near and the words used are all 16bit, and
  37. +there is no reason to make them 32-bit.  From my experience, the
  38.  
  39.   True, but even a 16-bit operating system can move 32-bit double-words
  40.  
  41. +advantages of having 32 bits are more in the form of having a large
  42. +flat address space, and much less in the form of more speed.
  43.  
  44.   And some advantage that is... try manipulating a 1MB data set...
  45.  
  46.   First, could someone please write a definitive post to the effect that
  47. 32 bit data values are available in both 16 bit and 32 bit operating
  48. systems?!  Recompiling something for 32 bit will, in all likelihood
  49. accomplish nothing, since the same segmentation, data manipulation
  50. and (MOST important) BIOS calls which require a drop from protected mode
  51. and back will be involved (OK a good compiler _may_ improve the segment-
  52. ation).
  53.    In order for 32-bit operating systems to be anything special (or
  54. for that matter, 16-bit protected mode operating systems), we need
  55. a revolution in BIOS itself.  Perhaps new BIOS chips should have an
  56. option, whereby you press some key combination for protected mode & a
  57. second ROM chip (in ultra-extended memory) takes over.  Real mode
  58. programs could be emulated, and even this would be faster than an XT!
  59.    Then again, the BIOS-controlled dual boot could allow a 16-bit real
  60. mode boot for DOS, etc. which would set up the normal IRQ table _OR_
  61. a more useful, truely protected mode, 32-bit, Screw-DOS operating system.
  62.    The only real catch is getting 32-bit protected mode BIOS extensions
  63. for all of those DOS-compatible cards.  But then again, in a system which
  64. can flatmode 4 GB, there's plenty of room for memory resident drivers.
  65.  
  66.    While I've got your attention - Here's my $0.02 worth on Video...
  67. with 4GB of real memory space, why not set aside, oh about 128 MB as
  68. reserved space for memory mapped terminals?   Rather than dealing with
  69. this bullshit about planes of memory and VGA registers, why not just
  70. allocate about 4MB for direct mapped Video, Mouse & Keyboard space and
  71. plan on allowing up to 32 users (OK, so I'm way ahead of it on this).
  72.  
  73.    I seriously think that a 32-bit BIOS, direct mapped, true-color
  74. (accelerated or co-processed) video and Fast-clocked (50 MHz) EISA
  75. will be sufficient to blow the lid off of desktop performance.  When I
  76. think about the wasted clock cycles incurred by DOS, Windows, OS/2 and
  77. even Unix in dealing with archaic hardware standards, like segmented
  78. real mode memory, Multi-plane mapped video and slow-clocked I/O busses,
  79. I wonder how everyone stands for it.
  80.  
  81.     Jeffrey C. Andle
  82.     U. Maine - Dept. of ELE & Surface Science Lab.
  83.     Orono, ME
  84. " I wish my ideas were your own, then I wouldn't have to convince you "
  85. They are, alas, mine, not my employers', or anyone's who will do anything
  86. with them.  If you want them, take them...
  87.