home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 1090 < prev    next >
Encoding:
Text File  |  1996-08-05  |  6.7 KB  |  165 lines
  1. Path: cs.uwa.edu.au!jasonb
  2. From: jasonb@cs.uwa.edu.au (Jason S Birch)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: PPC compilers
  5. Date: 15 Jan 96 02:49:26 GMT
  6. Organization: The University of Western Australia
  7. Message-ID: <jasonb.821674166@cs.uwa.edu.au>
  8. References: <john.hendrikx.40ka@grafix.xs4all.nl> <jasonb.820051107@cs.uwa.edu.au> <VBzVx*M3f@yaps.rhein.de> <4d0tf0$i4i@maureen.teleport.com> <jasonb.821371468@cs.uwa.edu.au> <4d5k6h$a2j@maureen.teleport.com>
  9. NNTP-Posting-Host: decadence.cs.uwa.oz.au
  10. X-Newsreader: NN version 6.5.0 #3 (NOV)
  11.  
  12. sschaem@teleport.com (Stephan Schaem) writes:
  13.  
  14. >Jason S Birch (jasonb@cs.uwa.edu.au) wrote:
  15. >: No, it wasn't, which is what I've been repeatedly saying. It was about
  16. >: whether assembler is easier to debug than C because the line:
  17.  
  18. >: move.w (a0)+,(a1)+ 
  19.  
  20. >: tells you how many bytes are being moved, and added to a0 and a1,
  21. >: whereas:
  22.  
  23. > It tells me that I move a word from a0 to a1 and let point a0 and a1 to
  24. > the next word. (I just happen to know word is 2 byte:)
  25.  
  26. Yes, but it *doesn't* tell you if you *wanted* to move a word from a0
  27. to a1. This is the whole point - you have to know what a0 and a1 are
  28. pointing to, and you have to know the *size* of the thing they are
  29. pointing to (ie. the implementation of the abstract data type) in
  30. order to know if that line is correct. Keep this in mind.
  31.  
  32. >: *a++ = *b++;
  33.  
  34. > Notice I didn't mention type size for asm or C... And where we not talking
  35. > about debuging already compiled code, right?  I recall we where talking 
  36. > about writting code.
  37.  
  38. We were actually talking about trying to debug a program, and whether
  39. it was easier to debug C or asm because in asm you have more knowledge
  40. of what the machine is actually going to do. The idea was you have just
  41. that one line of code and want to know if it's correct or not.  The
  42. answer is, in both cases, you can't tell. In C, you need to look at the
  43. variable declarations of a and b and do a simple check to see if they
  44. are the same type. This requires absolutely no knowledge of the
  45. behaviour of types under C - if a and b are the same type, that line
  46. *will* work - you then just need to check to see if that type is what
  47. you wanted. If they are not, then you need to know a bit about how the
  48. types are defined to establish if they are *equivalent*. In asm,
  49. however, you first have to work out where the current values of a0 and
  50. a1 came from, to make sure that's correct. Then you have to work out
  51.                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
  52. whether the type they're pointing to is actually a word. *Then* you
  53. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  54. have to be sure it was *meant* to be a word. I've underlined the
  55. biggest difference.
  56.  
  57. > I will repeat:
  58.  
  59. > move.word    (a0)+,(a1)+
  60.  
  61. > I would not write the above if I didn't know a0 and a1 are of the same type.
  62.  
  63. Unless you make a mistake. We were talking about debugging. If you
  64. never write lines of code without incorrectly "knowing" all the
  65. required information beforehand, I guess you never have bugs. Also,
  66. you have to know that a0 and a1 are *implemented* as words.
  67.  
  68. > a++ = b++
  69.  
  70. > I would not write the above if I didn't know a and b are of the same type,
  71. > or a type compatible with C operators, or a type that can be converted..
  72.  
  73. Likewise, except you don't need to know how a and b are implemented (oh
  74. - I'm assuming you made one of those mistakes in the above and actually
  75. meant to write *a++ = *b++).
  76.  
  77. > basicly in both case know the variable type, and type definition.
  78.  
  79. Of course - it's just that the claim the asm one is easier to debug
  80. because it includes type information is bogus. 
  81.  
  82. >: This is a red herring. If the *type* of an element in a structure is
  83. >: given as ulong, then it must be a ulong, it is bound to being a ulong,
  84. >: and you can forever more treat it as a ulong. If it's given as a
  85. >: bilby, however, and somewhere else a bilby is defined to be a ulong
  86. >: (via typedef), then it is only bound to being a bilby and you can only
  87. >: treat it like a bilby - you may not treat it as a ulong.
  88.  
  89. > Yes, and I read that clock_t was a ulong... 
  90.  
  91. This is why I said it was a red herring. If you have:
  92.  
  93. struct SomeType {
  94.     ulong a_field;
  95.     ulong b_field;
  96. };
  97.  
  98. Then you are quite legitimately able to treat a_field as a ulong. If,
  99. however, you have:
  100.  
  101. typedef ulong field_t;
  102.  
  103. struct SomeType {
  104.     field_t a_field;
  105.     field_t b_field;
  106. };
  107.  
  108. Then you can only assume a_field is of type field_t, and *not* of type
  109. ulong. Similarly, if you have:
  110.  
  111. typedef ulong clock_t;
  112.  
  113. Then you can only create relevant variables of type clock_t (NOT
  114. ulong) and give those to functions expecting a variable of that type.
  115. The *reason* clock_t is created at all (and the support functions
  116. don't simply use ulong) is that they want it to be abstract. You must
  117. respect that.
  118.  
  119. > Yes... I rely on ANSI standart of min range assigned ... 
  120.  
  121. What ANSI standard for min ranges???
  122.  
  123. > I mentioned all that early on in my post. I also mentioned that I write 
  124. > common code for windows & macos, So I would hope to know about making code
  125. > portable...
  126.  
  127. Do you often use things like ulong when you mean clock_t? Also,
  128. AmigaOS, Windows, and MacOS aren't that different for standard ANSI
  129. code - only int changes in size.
  130.  
  131. >: It couldn't, because "-" would no longer work; however, if a
  132. >: DiffClock() function existed, it could. time_t is a better example.
  133.  
  134. > This is also true for asm... 
  135.  
  136. Except - and here's the kicker - if you wanted to do anything
  137. non-trivial, you need to know how big the implementation of a size is,
  138. like in the move.w (a0)+,(a1)+ example above. With C, if you know it's
  139. an ordinal type, for example (such as for clock_t), you can use all the
  140. arithmetic operators without having to worry about *which* ordinal type
  141. it's equivalent to.
  142.  
  143. >: This is the problem - he never wanted to prove that. You misinterpreted
  144. >: his comments, and have thus far refused to give up your straw man. :-)
  145.  
  146. > Ok then... its just that when I saw something, and one respond "no you
  147. > are wrong" + detail, I like to prove my original point. I fell strong
  148. > about it because this fact ahappen on everyline I write in ASM or C.
  149. > So someone telling me (Or me reading) that I dont have to bother with type
  150. > definition and even variable type after I define:declare them turn my
  151. > world around :)
  152.  
  153. Well, it's not just your misunderstanding of the original comments,
  154. you keep giving the impression (as this post shows) that you think
  155. having to know if an assembler type is equivalent to a word is the
  156. same as knowing clock_t is a ulong, which is not the case at all.
  157.  
  158. > Stephan
  159.  
  160. -- 
  161. Jason S Birch                        ,-_|\ email: jasonb@cs.uwa.edu.au
  162. Department of Computer Science      /     \ Tel (work): +61 9 380 1840
  163. The University of Western Australia *_.-._/ Fax (work): +61 9 380 1089
  164. Nedlands  W. Australia  6907             v  Tel (home): +61 9 386 8630
  165.