home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / ibm / pc / misc / 16999 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  3.3 KB
  1. Path: sparky!uunet!mcsun!ub4b!alcbel!se.alcbel!se.alcbel.be!jpra
  2. From: jpra@se.alcbel.be (John PR Archer   SE141    X4763)
  3. Newsgroups: comp.sys.ibm.pc.misc
  4. Subject: 8086 & 8026 code growing out of 64K
  5. Message-ID: <1445@se.alcbel.be>
  6. Date: 21 Jan 93 16:07:48 GMT
  7. Sender: jpra@se.alcbel.be
  8. Reply-To: jpra@se.alcbel.be
  9. Organization: Alcatel Bell
  10. Lines: 65
  11. Nntp-Posting-Host: btmw89
  12.  
  13.  
  14. Hi, 
  15.  
  16. I posted this to the intel.sys group and got no response, it's not directly a 
  17. PC problem but  I'm pretty sure that some of you PC gurus can answer my 
  18. question(s) and maybe give me some references.
  19.  
  20. Problem: 8086 and 80286 source growing out of 64K
  21.  
  22. Framework: 
  23. We have our own 8086 and 286 code generators and can change or upgrade  
  24. them as required. We have some very large modules that are approaching 
  25. 64K of 8086 or 80286 code and extra functionality has to be added 
  26. to these modules quickly. Our system does not support modular programming 
  27. very well and so splitting up the large modules is a painful process. 
  28. A solution could be to upgrade to 386 machines running in protected 
  29. mode this means that the code size limitation of 64K could be removed.
  30. (I should add that our system does not (currently) support multi code segment 
  31. modules either! Configuration management restrictions, 1 source -> 1 code seg )   
  32.  
  33. Questions: 
  34. Without changing any of the existing source code is it possible to 
  35. have a code segment of more than 64K described as a 16 bit segment 
  36. (D bit set to 0)? Will the code execute correctly when it passes the 
  37. 64K boundary? When in 16 bit mode, is the 32 bit instruction pointer 
  38. (EIP) maintained correctly, or is only the lower half maintained (old 
  39. 16 bit IP)? 
  40.  
  41. Our code never makes calls or jumps to other code segments but if 
  42. we allow code sizes to grow out of 64K we may well jump or call out 
  43. of the 64K boundary. 
  44.  
  45. If we change our code generators to generate the operand and address 
  46. size override prefixes for all jumps and call - return instructions 
  47. and remove the 64k size limitation on code segments only, can we then create 
  48. descriptors with the D bit cleared so that the code will execute correctly 
  49. on a 386 (protected mode)? 
  50.  
  51. Will the 386 trap out if it finds a code segment descriptor with the 
  52. D bit cleared but a code size greater than 64K, does it simply ignore 
  53. bits 19-16 of the segment (size) limit field and continue but then 
  54. fall over when you try to go past 64K? 
  55.   
  56. Comment: 
  57. I know I am probably asking the same question in several different 
  58. ways. I really want the reply to be "yes it'll all work fine".  I 
  59. can find nothing concrete in the Intel 386DX  "Programmer's Reference 
  60. Manual" (1990)  that says  NO , but James L Turley's "Advanced 
  61. 80386 Programming Techniques"  implies that it is will not work. Also neither
  62. MASM nor Intel's ASM386 allow USE16 modules to have more than 64K, but I am still
  63. hoping. 
  64.  
  65. Alternative: 
  66. The alternative is to maintain that the code segment is a 32 bit segment 
  67. (D bit set) and  then use the prefixes 66H and 67H to override  
  68. every  existing instruction and addressing operation  except  
  69. the jumps and calls. We estimate that this could increase the code 
  70. sizes by 35-50% and also involves a much larger change to our code 
  71. generators.  
  72. Would this massive use of override prefixes slow down the processing 
  73. appreciably?  
  74.  
  75. Thanks in advance.
  76.                       Cheers,
  77.                               John
  78.