home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / hardware / 2585 < prev    next >
Encoding:
Text File  |  1992-11-08  |  2.7 KB  |  58 lines
  1. Newsgroups: comp.sys.next.hardware
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!kronos.arc.nasa.gov!iscnvx!netcomsv!netcom.com!abell
  3. From: abell@netcom.com (Steven T. Abell)
  4. Subject: Re: Byte Swapping (Was: New RISC workstations)
  5. Message-ID: <1992Nov6.202712.22966@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <1992Nov2.195519.612@netcom.com> <1992Nov5.065817.4662@relief.com>
  8. Date: Fri, 6 Nov 1992 20:27:12 GMT
  9. Lines: 47
  10.  
  11. jjfeiler@relief.com (John Jay Feiler) writes:
  12.  
  13. > In article <1992Nov2.195519.612@netcom.com> abell@netcom.com (Steven T.  
  14. > Abell) writes:
  15. > > eboltz@jhunix.hcf.jhu.edu (Eric Scott Boltz) writes:
  16. > > 
  17. > > > As far as Intel CPUs go, aren't they the ones that expect multiple-byte
  18. > > > data to have bytes swaped? - Yuck.
  19. > > 
  20. > > As far as I'm aware, nobody has *ever* made a machine that got  
  21. > > byte-ordering right in combination with several other crucial factors.
  22. > > This has had an unpleasant effect on sofware quality.
  23. > > [munch]
  24. > > 
  25. > > The design I suggest is very different from what we're used to,
  26. > > but it works just as well in the machine, and better in our heads when
  27. > > we're writing programs. That translates into fewer bugs.
  28. > > 
  29. > > 0) All memory diagrams are written sideways,
  30. > >    with the most-significant bit, byte, word, whatever, on the left.
  31. > > 
  32. > > 1) The base address of a string, struct, array is its *end*,
  33. > >    not its beginning.
  34.  
  35. > Unfortunately, many string operations (formatting strings, strcat, etc) will  
  36. > grow the length of the string, and we than have to copy the entire string to  
  37. > a buffer, operate on it, then put it back with its end in the right place.    
  38. > Sigh......
  39.  
  40. Partly true. The left-to-right-is-high-to-low-always scheme invalidates
  41. some C-think. With a system and a language designed as I suggest, the
  42. mechanics of string processing will have to be different, but not much,
  43. and it will usually be more efficient. The only real implication of this
  44. design for the specific problem John describes is that string pointers are
  45. less constant. Algorithms that really require buffered copies in my scheme
  46. will also require copies in a standard C program.
  47.  
  48. To digress a little, one of the most frequent complaints I hear about C is
  49. its string-handling (in)ability. I hate to even mention the word, but BASIC,
  50. for all its wretchedness, is still the weapon of choice among traditional
  51. languages for string manipulation. There are fairly simple ways of putting
  52. that kind of functionality into a C-like language, and for that, the
  53. left-to-right-etc. design is ideal.
  54.  
  55. C is twenty years old. Maybe it's time to take what we've learned and move on.
  56.  
  57. Steve abell@netcom.com
  58.