home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / advocacy / 3323 < prev    next >
Encoding:
Text File  |  1992-07-28  |  2.7 KB  |  68 lines
  1. Newsgroups: comp.os.os2.advocacy
  2. Path: sparky!uunet!microsoft!hexnut!adamba
  3. From: adamba@microsoft.com (Adam Barr)
  4. Subject: What portable is
  5. Message-ID: <1992Jul27.165547.1517@microsoft.com>
  6. Date: 27 Jul 92 16:55:47 GMT
  7. Organization: Microsoft Corporation
  8. Lines: 58
  9.  
  10. This whole "discussion" about portability is talking about
  11. the amount of assembly language code as if this is the only
  12. area that affects portability. This isn't true. You can
  13. write lots of C code that is wonderfully structured, chock
  14. full of comments, and completely non-portable.
  15.  
  16. If you are talking about an x86 to RS/6000 port, one of the
  17. basic differences is bit ordering. All the kernel code that
  18. is twiddling bits *may* have assumptions about this, whatever
  19. language it is written in. There is no easy way to find code
  20. like this either; it may be scattered everywhere.
  21.  
  22. (Cynics will point out that the current list of NT platforms
  23. includes only little-endian machines. This is true, for the
  24. *current* list. This is a case where being designed with
  25. portability in mind helps; you may have code like that, but
  26. you can put it all in one place or put a big comment about
  27. it in the code.)
  28.  
  29. Another non-portable area is handling of things like the
  30. interrupt controller. The x86 machines all have an Intel
  31. 8259 interrupt controller sitting between the bus and the
  32. cpu. How often does the OS/2 kernel touch this chip? Is
  33. it all in one place? Assuming the RS/6000 doesn't have
  34. this chip, all that code needs to be replaced, not
  35. just converted from C to assembler.
  36.  
  37. Worse, how many times did a programmer working on something
  38. not obviously connected to interrupt handling say to themselves,
  39. "I can fix this problem if I just do this and this to the 8259"?
  40. Again, the fact that the code is in assembler is a minor point;
  41. differences like this may invalidate fundamental assumptions
  42. that were made during the design of the OS.
  43.  
  44. What about the memory manager? The scheduler? The cache?
  45. What crucial piece of code depends on a feature of the
  46. x86 that doesn't exist on an RS/6000? Or depends on a
  47. certain operation being really fast on one processor,
  48. when it is extremely slow on another?
  49.  
  50.  
  51. I'm not saying any of this happened; note that I use "may"
  52. a lot. Accuse me of FUD if you want; I think these are
  53. the kinds of questions people should be asking when IBM
  54. makes portability claims, instead of arguing about how
  55. much assembler is in the code (although this matters too!).
  56.  
  57.  
  58. I could make similar arguments about symmetric multiprocessor
  59. support. Are the functions for SMP support in one place? Does
  60. the kernel call those functions when needed? How many assumptions
  61. about non-preemption does the OS/2 kernel make while accessing
  62. global data?
  63.  
  64.  
  65. - adam
  66.  
  67. DISCLAIMER: Fire hazard, do not burn
  68.