home *** CD-ROM | disk | FTP | other *** search
/ Crawly Crypt Collection 1 / crawlyvol1.bin / program / compiler / nasm20b / doc / hack.txt < prev    next >
Text File  |  1993-02-10  |  18KB  |  418 lines

  1. ----------------------------------------------------------------------
  2.                   Copyright (C) 1991 by Natürlich!
  3.                      This file is copyrighted!
  4.                Refer to the documentation for details.
  5. ----------------------------------------------------------------------
  6. ======================================================================
  7.                             Hacking NASM65
  8.          ***  READ THIS IF YOU WANT TO PORT OR IMPROVE NASM ***
  9.                            RANDOM THOUGHTS
  10.                            TABs @ 3, 6, 9 ...
  11. ======================================================================
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22. STEP 1   L O O K   A T   Y O U R   M A C H I N E .   D O   
  23.          Y O U   T R U S T   I T   T O   C O M P I L E   
  24.          A N D   E X E C U T E   A   L A R G E   C   
  25.          P R O G R A M   P R O P E R L Y  ?
  26.          
  27.          H I N T :   I F   Y O U   A R E   A   M S - D O S   
  28.                      U S E R   Y O U   P R O B A B L Y   
  29.                      D O N ' T .  S K I P   T O   T H E   
  30.                      E N D   O F   T H I S   T E X T
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44. STEP 2   E D I T   P O R T A B L E . C   A N D   T H E N
  45.          T R Y   T O   C O M P I L E   I T    F I R S T !
  46.          I F   Y O U   C A N ' T   G E T   P O R T A B L E
  47.          T O   R U N ,   F O R G E T   A B O U T
  48.          C O M P I L I N G   T H E   P A C K A G E !
  49.  
  50.          L O O K   C A R E F U L L Y   A T   T H E   O U T P U T !
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66. STEP 3   If you get mysterious compile warnings after portable compiled
  67.          successfully, it may very well be that your system doesn't
  68.          like the order in which the files are included. Especially
  69.          bothersome are "nasm.h" and "xosbind.h" try to juggle them
  70.          around 'til it works.
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.     **** IMPORTANT **** IMPORTANT **** IMPORTANT **** IMPORTANT ****
  84.  
  85.     If you port this to another machine make sure that the object files
  86.     produced are compatible with the TOS version!! THIS IS THE MOST
  87.     IMPORTANT THING TO WATCH OUT FOR WHEN PORTING!!
  88.  
  89.     IF YOU CAN'T MAKE IT object file compatible, but you get it working
  90.     THEN YOU MUST SET #define INCOMPATIBLE 1. This will at least tell
  91.     other machinery with correct ports that they can't use your objects.
  92.     File compatible, does not mean file identical. If it looks different
  93.     but it still links with ST produced object files and produces the
  94.     same binary, then that's OK.
  95.  
  96.     **** IMPORTANT **** IMPORTANT **** IMPORTANT **** IMPORTANT ****
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103. /* more random thoughts */
  104. Use GCC, if you are running Unix. The HP cc compiler I know, doesn't
  105. compile anything, beyond "hello world".
  106. Compile and run portable.c on a new system, to see where the
  107. differences between Atari ST and the new machinery lie.
  108. Portable produces "localdef.h" for your defines.h file. If your
  109. system doesn't have <signal.h> set SIGNAL to 0 (it doesn't matter
  110. for NASM65, but you can only guess from crashes, whether WORDs
  111. have to lie on even boundaries). If you know that you don't have
  112. UNIX-like IO, set IOCHECK to 0 as well. If portable crashes set
  113. #define WORD_EVEN 1
  114. in the "localdef.h" file.
  115.  
  116. NASM65 puts heavy strain on the compiler and the preprocessor.
  117. If your preprocessor is apparently NOT up to standards you might
  118. want to use an ANSI cpp to preprocess all .c files and compile those
  119. on your lesser C-compiler.
  120.  
  121. Change the file xosbind.h, to fit your system. Check out the way lseek
  122. operates.
  123.  
  124. Files you may want to change are...
  125. defines.h
  126. xosbind.h
  127. nmalloc.h / nmalloc.sun
  128.  
  129. If you can't set "byte" to 8 bit, "word" to 16 bit or "lword" to 32 bit,
  130. then you need to look into structs.h AND INTO OBJECT.H!!. Also most
  131. probably yylval will need retyping. (struct ??) Some programs like
  132. disasm65 expect 16bit datatypes and will produce unsightly results.
  133. Bottomline: If you don't have 8 and 16bit things FORGET IT!
  134.  
  135. Almost every pointer has a "huge" modifier, which is completely
  136. meaningless except if you are MS-DOS based. In the MS-DOS world
  137. far doesn't give you true 32-bit performance, but huge comes 
  138. much closer.
  139.  
  140. If you do mind the style this is written in, than go port/hack
  141. something else. I do not (repeat: do not) want any improvements in
  142. the visual style this is written in. I also don't think leaving out
  143. the various little jokes makes your port a good port. If you can hack
  144. up something better, GO AHEAD!  (WITHNOISY not required BTW). And
  145. please.. NO FUCKING PROTOTYPING!
  146.  
  147. I'd appreciate if you could #if around the code, that creates problems,
  148. so that the source will still be useable for the ST and other already
  149. ported machinery. (except if your code is definitely more correct, like
  150. f.i. a missing cast or so..) If you have successfully ported please send
  151. me your diffs so that I can update my sources with them. Indicate which
  152. version you hacked on BTW.
  153.  
  154. For development set VERSION to 0, and all revisons to 0 (at first).
  155. This makes things a  lot  easier, and enables debugging for those
  156. w/o a sourcelevel debugger.
  157.  
  158. Improving NASM to handle the C64 or AppleII, ought to involve 'just'
  159. changing the FF FF headers of the executables, and changing |MEMLO to
  160. the right value. If they can't take segmented binary files, it might
  161. be wise to disallow the '-r' flag.
  162.  
  163. Some files are compiled twice, once for the linker and once for
  164. the assembler. Try to keep those as short as possible.
  165.  
  166.  
  167. This is taken from NERD but it is valid nevertheless:
  168.      One more note to the comments, don't trust them if they don't make
  169.      sense to you. Most of them are there just for my entertainment and
  170.      as reminders of historic failures. (Some of them are plain wrong)
  171.      To understand the comments a complete CD-collection of bands mentioned
  172.      below and the books of R.A. Lafferty are essential.
  173.      (-zusammenfassend: Kommentare sind für mich, nicht für dich. Der
  174.      Sinn läßt sich manchmal nur mit einigem Hintergrundswissen er-
  175.      schliessen. Viel Glück trotzdem..)
  176.  
  177. Getting more speed out of NASM:
  178. This program has tought me something about what's really important in
  179. an assembler and what's not. All important is the character get routine!!
  180. Unfortunately due to my efforts in OO-designing the I/O system, this
  181. is one of the slower components. INPUTFST.H & FASTEXPR.H yielded a
  182. speed increase of 10% (difference to VERSION 0)). Needless to say this
  183. is less than satisfactory. (A further rewrite in v1.2 which had the looks
  184. that kill, didn't do anything...)
  185.  
  186. Yacc might be a bit overkill for an assembler. Some code has not seen
  187. any optimization although it should, like the stuff in MACRO.C and
  188. PROCESS.C. With the help of the generic nmalloc and some inline #defines,
  189. creation and handling of all the lists, should be quite speedy, but I
  190. suspect it isn't (More fun ahead).
  191. Strings could be aligned on odd addresses only, which would make hashing
  192. easier since, you'd just need to pick a LONG from &string + 3. This isn't
  193. that good though, cause that means that local labels only get 3 chars for
  194. hashing. The point of having 6 characters is that many labels differ only
  195. at the end (like f.i. COLPL0 COLPF1). On the other hand those aren't local
  196. labels and the hash routine, although written in assembler takes an
  197. estimated 300 cycles ~ 50 microsecs, so may be it WOULD be worthwhile.
  198. There is one thing bugging me still, no matter what find_label does
  199. at least one strcmp must be done, when a matching label is found. Since
  200. the hash values are spread over several characters using HASH alone for
  201. the first 6-7 characters is not conclusive. Maybe use 64 bit for hashing..
  202.  
  203. >version 1.2 has been successfully ported to MSDOS, (thanks to J.Richter
  204. >for lending me his machine for a week and helping me read the
  205. >80xxx ML code, he also pointed out some problems with prototyping).
  206. >One good thing about this affair was that I got access to a profiler.
  207. >The results have been quite pleasant so far, the bottle neck being the
  208. >parser and not my code, as was feared. The find_label routine is quite
  209. >speedy and doesn't warrant further optimization.
  210. v1.2 probably was never a successful port. It just looked that way.
  211.  
  212.  
  213.  
  214. (THIS IS VERY OUTDATED AND JUST KEPT IN HERE FOR HISTORICAL AND AMUSEMENT
  215. VALUE (nat/10/91))
  216. (SKIP UNTIL "<<<HERE>>>" AND IGNORE THIS)
  217. -------------------------------------------------------------------------
  218. Some comments start of with **, this means usually that at this point
  219. in the code some forseeable problems may arise when porting this code.
  220. **-PORT #1-** means:  casting was used just to get rid of warnings. They
  221.                       can be thrown out if needed.
  222.  
  223. **-PORT #2-** means:  Be very careful here. A structural change might
  224.                       lead to imcompatibilites. (This should have been
  225.                       put into more places)
  226.  
  227. **-PORT #3-** means:  Change this value according to your machine.
  228.  
  229. **-PORT #4-** means:  There could be problems here with BITwise BIGENDIAN
  230.                       machinery.
  231.  
  232. **-PORT #5-** means:  This shouldn't be a problem, since $0000 is $0000
  233.                       whether BIGENDIAN or LITTLEENDIAN
  234.  
  235. **-PORT #6-** means:  If this doesn't work, omit it. Note it in the run
  236.                       notice though.
  237.  
  238. **-PORT #7-** means:  This (probably) only works with two's complement.
  239.  
  240.  
  241. Some porting hints:
  242.  
  243. So you've got some bastard machinery that makes life miserable. I can
  244. anticipate some problems and point you into the right directions...
  245.  
  246. Case1:  Bytes are 7 Bit (or less ?). Jeeeeeesus. You really are some
  247.         diehard fanatic. You probably are on some sort of mainframe and
  248.         VERY bored with life. My advice: Forget it.
  249.         If you make it nevertheless PLEASE PLEASE send me the source.
  250.  
  251. Case2:  If you have a 68xxx or 80xxx machine, NASM should compile fine.
  252.         Only the I/O-calls might give you problems.
  253.  
  254. Case3:  Pointer trouble. If unsigned long is too small to pack any kind
  255.         of pointer into, you will have to use a union for yylval in lexer.c
  256.         asm65.y macro.c md_suck.c. I figured a compiler, which can't
  257.         implement unions as register variables (as I fathom some can't)
  258.         would compile better code this way. (Who knows...). The rest
  259.         should be OK, since I ought to have casted every pointer in sight.
  260.  
  261. Case4:  Portable tells you: NO 16-Bits around. This is BAD!! Look around,
  262.         maybe you can construe something out of two chars. If you take a
  263.         look at code.h, you will see that this code is VERY dependent, that
  264.         you can put 2 8-Bits together, calc with them as if they were
  265.         16-Bit (unsigned natch!) and then pull them apart again. If you
  266.         can't make 16-Bits somehow, try for 24 or 32 bit and rewrite
  267.         code.h to calc the new offsets (possibly + 2 bytes).
  268. -------------------------------------------------------------------------
  269. (<<<HERE>>> OK, HERE COMES SOME LESS CRUFTY ASCII)
  270.  
  271. Adding your own directives is EASY. First make up a name. It must
  272. start with a '.'. Check out the way I did it with .undef. First
  273. I put in a line in ASM65.Y in
  274.  
  275. nline:
  276.       ...
  277.       |  T_UNDEF  T_IDENT                 { undefine( $2);          }
  278.       ...
  279.  
  280. this basically means, when a line contains a .undef directive token, which
  281. must be followed by an identifier token, call undefine() with the identifier.
  282. Now register T_UNDEF as a token with
  283.  
  284. %token <u>  ... T_UNDEF     /* line 72 in ASM65.Y or so... */
  285.  
  286. <u> basically means, we don't care about the <value> of T_UNDEF, we DO
  287. care about the value of T_IDENT (--> $2) but T_IDENT is already handled
  288. so we don't need to do anything more in ASM65.Y. If you want to be neat
  289. do a little function definition in NASM.H. Make it:
  290.  
  291. void undefine();
  292.  
  293. Now we need to generate the T_UNDEF token, this is done in md_suck
  294. (M acro & D irective SUCK er). Since there aren't yet any other directives
  295. starting with U, we have to create a du_[] array for ourselves, that
  296. ends with a EOA (end of array) field. If there had been a du_[] array
  297. already we'd just needed to insert our bit { "UNDEF",  T_UNDEF, 0 } at
  298. the lexically correct position. Since du_[] didn't exist before we also
  299. need to update   *d_arr  and insert du_ inbetween  dt_, and  dv_.
  300. Then we also need to update (because we changed d_arr) d_starters.
  301. We locate the free entry for U
  302.    /* A B C D E F G H I J K L M  N  O  P Q  R  S  T U  V  W X Y  Z */
  303.       1,2,3,4,5,6,0,0,7,0,0,8,9,10,11,12,0,13,14,15,0,16,17,0,0,18,
  304. and update the table to
  305.    /* A B C D E F G H I J K L M  N  O  P Q  R  S  T  U  V  W X Y  Z */
  306.       1,2,3,4,5,6,0,0,7,0,0,8,9,10,11,12,0,13,14,15,16,17,18,0,0,19,
  307. (we could have done this a bit faster, by appending du_ to d_arr and
  308. putting a 19 into d_starters, but it would have looked ugly...)
  309. Now we need to update two more files, which are ndebug.c, we just insert
  310.       case T_UNDEF :    x = "T_UNDEF";    break;
  311. anywhere it looks OK (in the large switch statement),
  312. and errorasm.c we insert a
  313.       case T_UNDEF    : return( ".UNDEF");
  314. so that we can create somewhat more readable error messages.
  315.  
  316. And we are done! (Don't forget to write the C-routine.. (har har))
  317.  
  318.  
  319. PROBLEMS THAT I RUN INTO WHENEVER I AM TRYING TO PORT NASM
  320. ----------------------------------------------------------
  321.  
  322. o  Forgot to run portable, when copying over new files and
  323.    thereby clobbering LOCALDEF.H
  324.  
  325. o  Set TEST in nmalloc.h to 1 and expect big macros to be
  326.    swallowed.
  327.  
  328. ----------------------------------------------------------------------
  329. A little bonus for those who read thru this cruft till the end:
  330. (for seasoned readers this is v1.2) of course you never
  331. could put in an AUTO folder, cause GEM isn't running yet...
  332. It's ABE encoded (really obscure)
  333.  
  334. ;ABE ASCII-Binary-Encoding (by Brad Templeton)
  335. ;Use 'sort' and/or 'dabe' to decode
  336. T./z$$filecount=1
  337. T.0N##S1000,1000,1000,ABE1
  338. T.1N$$blocking=false
  339. T.2r$$uname=x.arc
  340. T.3a$$os=gemdos
  341. T.4c$$fname=x.arc
  342. T.55$$date=665419678
  343. T.6d$$perm=0
  344. T.7C$$size=1904
  345. T.8V""%0+_(&,zO=&=:'j(2\B)--<WF&^&AA3I/db%Z%a*0
  346. T.9O""&.]L?)J%&'%()*+0,-./q7123(4567/89v;'<=>?Z
  347. T.AT""'@ABC%DEFG%HIJK1LMNO'PQRS(TUVW;XYZ[V\]^_i
  348. T.Bg""(`abc1defgDhijkGlmno5pqrs,tuvw-xyzukXpGSu
  349. T.CM""))YR*&VDUN8OPl[WqlSZW5-U^3+_tcMx:g>Jfirj2
  350. T.Dp""*;n1v)[e342H`Nzk\FcKZ6s40G@baIZkLM`?9oihZ
  351. T.EH""+r>m8'10w@o?K.g6oxE7*X(EC>,M]mQhk:P>Qq;6W
  352. T.FJ"",TYCWlGV/HY8325Z'%y<oJB&RlTpnfNeDwsi9Qdtu
  353. T.GKd=NFNTL|OAD}.PRG0{D000A"AQu!wqZ+002`40)40|6@j+#F+{-3'xb}7.bk5+BLa
  354. T.HX-NmX:J{NMg1{hB0P{BO0+#*9Lvqm0=0+!mT|,i{=055#+J*f1)[\)0`=.#(()"M)a
  355. T.In0|z8:{1,Xd".>0"Q9q0:a+!ZS!J]|:t\WI{<.0="1))}_]p0-{YY4|12-Qf$QW{HJ
  356. T.JWg|[F{/0P!Mwc{)(0.P#evqwR=.{?g0`W!1K|?u"7FB0[~5wEn0~V,0|,A}kRe($Sj
  357. T.KKe#4,?Cv.h{9:COV{:7ih}+]C@+)]~a.M!y*d{dy3e@7"IC[H5r"y.X{IQb)!FLE}q,`
  358. T.LnmV}lj?N|H2T0d=NFNTL|OAD{.S000|;O00A"Aeu|9-|7\002..%}xSf2}i4o{Q)7|^
  359. T.MEU2/6e{G4P!6(DjHG&~V2C|/\{%4<A?0Y|/M{%9.fVn~FHB{>4cXV./{fod-.4R=_}bN>
  360. T.Nd7lh|,LH}Nx>7!dL|40]'\Z8e?)|xcwoB9"o:}ToZO,{:vt{bR8S'|Zj-TX[}:3MM!W2
  361. T.OC"o.oq}sRSN1aA{1ocW#1i4|*A{+>C!4q{>9i|'t$pY!XE$.^"]V{+Agwx{:9K|8k{-
  362. T.PIg5Ma#ho!G\!ak&{@NJ{I[^":r!n'g{_'h$G'!'HMev.|G)H_m!m,|H.0jwS!08"HZ
  363. T.Qo"kQU1j$CP{M1&|V-J#LV{4QR(n'!e)}p?F*.!89+]"35Zv"U8!@y#3to$kA#*W*!j[
  364. T.Re#I7o|cTA"@3*!;o}Cm/~8T@Z{afQU|BvABr-@:eO!VZx+{RP.}8X>/|n^u}+T<!+t
  365. T.Sl]C-}D;-NA2s,{[&);g<}sJh)^%{A]z=!XX},B[|/%tw~Rp(#DPd"%q<aH{Y+O"-[P
  366. T.Tn{<>DWC^YSj!7JQw/$+(<U!W]:>U{fc))BG:u!eW!Wb)"e*B{)kHDIlAY{&Cew[{CE
  367. T.U3/})p^I|rXY;_+{).Uc!.6z}K0o(&{=HHM{,'/ck.F@,f`ED{O%,B2!.qJw{g*s{GW
  368. T.V0L!2ir_2{FMT}hDO}Usg!jmf|2RP.X)BI{7[rBI}5,,@Ek{nTF/{m?6!^yCgG!Nu"^i
  369. T.W6&Gg|XB}1@z"lL.J={?Xrm"\bO{G@E1{&tSi({5uOdk!`3#D1!E1|AOZ5}S-(\{8*7
  370. T.XSFbpHbX0{??r_/[6|5'bt,$zK/{a[+</{e*5a/.{t<CN|dBt%Jz5)}(20|]`"kK5|,
  371. T.YbP{-Yk!YyU~%(15RE}c&Q{HIl?"a<;h}r2I,}&x3#6`W~DK@!yS!;>so4|<&!Px.|\
  372. T.Zi:~]b?{mO_~ue1![^Z_#)l{s@A|w^~rZ@<{:^>u0{<TU}BB5q+1|9Z-,!&I{hWb}R<P
  373. T.au~6b2"5%#<j~aD=rl!Uix"zED{<sb!&3d$MN!0b{=T){Nt;0|@I{2S7<!;=}n//{@e
  374. T.bMhK|-:3->Bj1!=G1=F}9+_b"BN$gcRyO4AEG^|(D|6S!+E}0P*$&5tbihM{6>QMy#2@
  375. T.cs|9y!u*};c_Y"[8#Km|v[_"B4$'457!C'tED!q4/}8,_q!C,!0Da$-J}7l;9J|`RN",A
  376. T.di}`UT"*nn!Dpd$n?V#=:{YJ?PC-!;W$>%=JX;!/H$ER|\E!XT!z5!+E1!4?@|2.sv-
  377. T.er{@yu#OO!iE"fw!/Px\$wM|+h>T$/,$.Y"SS1)>;}nz*)7;"Lw!8l{o[B{*%)F#Bd`
  378. T.fCKe|.C{N^d&{^W3|\D!6L"=01y{V%VV,#>f!9r?nKg!-J2|%Ws{DQl{Nni>m-{c1W!Jk
  379. T.gWc1?#6=Q0E9Hq}22?!J'}^.*"A1`|_6={O+*B|L]{K'i}yHxQD~4F)Nj)7!6&0M|]'
  380. T.h46{r*8ksT"%T-!/2{O>*^!?*\{X7GB{wK\!T2!Q\L!t6|PL{-(8}B.\pu|F0B!b[L+
  381. T.iV$Wmp"C*?i<}V>(`|a?}W<v.%8{'Y+aB8(#&Gn7$-&!c%qBU#J`!Rf#VuP{V@G,|-y
  382. T.jZ#)sF-~j'?~gVD}%p]$%zI"(Y{Hvh"y3|Bn/xTP{LZk?|0Go*!dv;G0W,AV}(.;{Uf
  383. T.kdP,{rJ>:{I0f!.]z!zA5.OCIm"\&Hm)J.{mElA"%:p{v9pz9}tqZ/;&|H+#'S\5YT}9NK
  384. T.lKKI!QJgO;"h(|jrR$d332$X'I#IU{g;Q!3/!g\{1'N8i|7Ih`!jY!Tc#R^6)!xK~olf
  385. T.mLV>#0O|IU|_s~k70{B2={d/m"in!'cnDL{Rr6$7<~YVS38#W/z=_(4}3\U}KejL|AM
  386. T.ng}MQFRWf?C]~sS8x|J\a}B]0}wD7|`>n})L_f_a{'Zz~&yP$rT]{';7,"fo{p6U~P%b
  387. T.ox|r;o"Z=3Yy$CT"0G#f,3#:@!`w"uNGj#+0$7Y!5L{m8l!W4|3r|jF7!a]4Z"vz}3;F
  388. T.paV{.CK{PXB4I}&Q-@"s/Z}MDE|2<H#lnQ{ee5BvR!>x!h3[|5l!4c|&`{9^k"AaA5$%\
  389. T.q41::!(Q!AR'p_<{l`V.TY:TpY<f@zQ!pz|OUAI|R^0d0
  390. T.rL$$end_file=x.arc
  391. T.sd$$filecrc32=951575977
  392. T.tH##E54348
  393. ;End of ABE encoding
  394.  
  395.  
  396. MS-DOS users:
  397.  
  398. I just spent what was one of the most miserable weekends in my life 
  399. porting NASM to MS-DOS using TC2.0 and TC3.0 (thanks again to 
  400. J. Richter for borrowing me his machine). Well the port may be deemed 
  401. partly successful only since the linker crashes on occasion. The 
  402. TC3.0 problem was due to a definite compiler bug and the TC2.0 failure 
  403. is very much suspected to be a compiler failure too. In the directory 
  404. PCSTUFF I have left the various project files. If you have access to 
  405. a newer version you may give it a try. There's just one thing I must 
  406. get off my chest:
  407.  
  408.    Your PC is huge childraping kludge from hell. Do yourself a favor
  409.    buy a Motorola based product, support the sanity of programmers.
  410.    
  411. P.S. (weeks later) Maybe TC2.0 will do it, with the newest version.
  412.      TC3.1 will not do it. It crashed on me during compilation. Talk
  413.      about quality products...
  414.      
  415. Nevertheless if you wanna try I put some project files into the
  416. kludge directory.
  417.  
  418.