home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / HAMRADIO / TCP90126.ZIP / TCP90126.TXT
Encoding:
Text File  |  1990-09-20  |  6.5 KB  |  181 lines
  1. TCP-Group Digest            Sat,  1 Sep 90       Volume 90 : Issue 126
  2.  
  3. Today's Topics:
  4.                'minor' problems with TC 2.0 and TC C++
  5.                                holidays
  6.                        SLIP help needed for NOS
  7.                          Some FORTH comments
  8.  
  9. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>
  10. Send requests of an administrative nature (addition to, deletion from the
  11. distribution list, et al) to: <ListServ@UCSD.Edu>
  12.  
  13. Archives of past issues of the TCP-Group Digest are available
  14. (by FTP only) from UCSD.Edu in directory "mailarchives".
  15. ----------------------------------------------------------------------
  16.  
  17. Date: Fri, 31 Aug 90 14:12:13 PDT
  18. From: Ron Henderson <crh@hpcvmcrh.cv.hp.com>
  19. Subject: 'minor' problems with TC 2.0 and TC C++
  20. To: tcp-group@ucsd.edu
  21.  
  22. I've run across another potential problem when using TC C++.  The
  23. following code compiled and ran ok with TC 2.0, but it fails with TC
  24. C++.
  25.  
  26. #include <stdio.h>
  27. #include <dos.h>
  28. main()
  29. {
  30.     int a, b, c;
  31.  
  32.     a=5555;
  33.     b=(a >> 8);
  34.     _AH=0x2c;
  35.     geninterrupt(0x21);
  36.     c=(a >> 8);
  37.     printf("b: %d, c: %d\n",b,c);
  38. }
  39.  
  40. will print : b: 21, c: 5
  41. rather than: b: 21, c: 21
  42.  
  43. The problem comes about because the geninterrupt call isn't, strictly
  44. speaking, a function call, it's a macro.  TC C++ knows that certain
  45. registers can be corrupted by function calls, and assumes their values
  46. might have changed.  The statement b=(a >> 8); loads the cl register
  47. with 8 which is used in the shift.  Since no 'true' function call exists
  48. between the b= and c= statements, the compiler obviously thinks cl is
  49. still valid, when in fact it is changed by the interrupt call to get
  50. current time.
  51.  
  52. Of course, TC 2.0 also has it's problems with the cx register.  The
  53. following code segment would fail:
  54.  
  55. ...
  56. int a, b, c;
  57. ...
  58.  
  59.     a = _CX;          /* line 1 */
  60.     c = (a >> 8);          /* line 2 */
  61.     d = a & 0xff;          /* line 3 */
  62.  
  63. because the compiler, in line 3, thinks the cx register still holds the
  64. value of a (as it did in line 1).  Actually, the cl register was used in
  65. line 2 to perform the shift.  Here is the applicable portion of the .asm
  66. file.
  67.  
  68. ; --     a=_CX;          /* line 1 */
  69.     mov    word ptr DGROUP:_a,cx
  70. ; --     b=(a >> 8);          /* line 2 */
  71.     mov    ax,cx
  72.     mov    cl,8
  73.     sar    ax,cl
  74.     mov    word ptr DGROUP:_b,ax
  75. ; --     c=a & 0x00ff;          /* line 3 */
  76.     mov    ax,cx   <---- OOPS, used the cx register which isn't valid now
  77.     and    ax,255
  78.     mov    word ptr DGROUP:_c,ax
  79.  
  80. This problem can be solved by changing the value of the cx register
  81. after storing it away, i.e.
  82.  
  83.     a = _CX; _CX=0;
  84.  
  85. will result in correct code.  TC C++ doesn't have this particular
  86. problem.
  87.  
  88.  
  89. -- 
  90. Ron Henderson  WA7TAS
  91. crh@cv.hp.com (crh@hp-pcd.hp.com)
  92.  
  93. ------------------------------
  94.  
  95. Date: Fri, 31 Aug 90 17:02:10 MDT
  96. From: Rob Janssen (PE1CHL) <cmgit!rob@relay.EU.net>
  97. Subject: holidays
  98. To: hp4nl!tcp-group@relay.EU.net (TCP/IP interest group)
  99.  
  100. I will be on holidays from next week tuesday.  I will not be reading
  101. my mail at rob@cmgit.uucp until October 1st.
  102. See you all at the CNC!
  103.  
  104. Rob PE1CHL
  105.  
  106. ------------------------------
  107.  
  108. Date: Fri, 31 Aug 90 18:33 EDT
  109. From: leon@ankh.ftl.fl.us (Leon Zetekoff)
  110. Subject: SLIP help needed for NOS
  111. To: tcp-group@ucsd.edu
  112.  
  113. I am desparately trying to get NOS to work on a slip bound landline link with
  114. netrom on top of it. My friend has no tnc and will use me to gateway out to
  115. the RF world. Everytime i try and boot I get garbage on the screen and NOS
  116. locks up tighter than a drum.
  117. I am using 900714 NOS and would apprecaite an assist ASAP
  118. 73 es tnx Leon wa4zlw
  119.  
  120. ------------------------------
  121.  
  122. Date: Fri, 31 Aug 90 16:08:09 UTC
  123. From: clark@tomcat.gsfc.nasa.gov (Tom Clark -- W3IWI)
  124. Subject: Some FORTH comments
  125. To: tcp-group@ucsd.edu
  126.  
  127. In a recent note, Jonathan Vail (N1DXG) stated:
  128.  
  129. > I agree that the disadvantages of using FORTH for NOS far outweigh the
  130. > advantages.  The times I have seen FORTH used in real projects they
  131. > never lived to see the light of day, were nightmares to maintain and
  132. > in one case ended in disaster and 200 people getting layed off.
  133.  
  134. I'll take exception to this statement with a few specific examples:
  135.  
  136. a. Chuck Moore originally "invented" FORTH when he was at the National Radio
  137. Astronomy Observatory and it has done yeoman service as a controller for a 
  138. number of telescopes (radio and optical) since the early '70s. This was
  139. especially true in the bygone days of yore when machines with 16kbytes of
  140. core (yes, core!) were all that was available.
  141.  
  142. b. The FORTH concept was ported to the RCA 1802 (and a number of other
  143. environments including the ATARI 400/800) by Dr. Karl Meinzer, DJ4ZC (Karl
  144. called his FORTH dialect IPS - Interpreter for Process Structures) as a high-
  145. level language to control complex instrument systems. Karl used IPS running
  146. on the 1802 as the native language for the AMSAT Phase-3A satellite (which
  147. was lost when the launcher blew up in 1980) and AMSAT-OSCAR-10 and -13. In
  148. these cases the entire spacecraft CPU had 16k or RAM (and no ROM) and the
  149. IPS software controls all the spacecraft functions including formatting and
  150. sending telemetry, processing commands, processing the position data from the
  151. Sun and Earth sensors, activating the spacecraft's magnet-torqurers to change
  152. the spacecraft's attitude, the firing of the kick motors, scheduling the
  153. transponder/antenna resources, etc. Except for the fact that AO-10's 16k
  154. dynamic RAM went brain-dead after several years exposure to radiation, this
  155. software has operated faultlessly for many years.
  156.  
  157. IPS was also developed for the telecommand stations using the ATARI computers
  158. (by DJ4ZC) and for Z80's (by W0PN, W1HDX, VE1SAT, ZL1AOX & W3IWI).
  159.  
  160. Karl also used the IPS/1802 combination in several University projects, 
  161. including one which automatically controlled a train. 
  162.  
  163. My experience using both FORTH (in the astronomical community) and IPS is
  164. the threaded interpreters are very powerful and very efficient of RAM. It
  165. is easy to write applications. But their are two weaknesses: (1) the code
  166. is slower at execution time, and (2) although code is easy to WRITE, it is
  167. very difficult to READ (by the writer several months later or by someone
  168. else). Any FORTH application MUST be extensively documented!
  169.  
  170. I think Anders' inclusion of FORTH in NOS is one of the cleverest ideas
  171. since sliced bread! Once a library of support utilities is available it will
  172. prove to be most valuable for all those "Gee I wish I could ... " extensions
  173. to NOS (I have a long list here just like that).
  174.  
  175. 73, Tom
  176.  
  177. ------------------------------
  178.  
  179. End of TCP-Group Digest
  180. ******************************
  181.