dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/10/87)
>The real bugger is mult and divides. Lattice *stupidly* handles >these by function calls, (eg CXM33) which are in lc.lib. The amiga.lib >has IMulU() and IDivU() to multiply and divide 16-bit USHORTS, but >this means you have to explicity convert. For example: > x = a * b; ==> x = IMulU( (USHORT)a, (USHORT)b ); You can still specify LC.LIB at link time. Since your using Astartup.obj and have no stdio references in your code, the only thing that will be included from LC.LIB will be the long multiply/divide routines. >MAJOR DRAWBACKS: Bye, bye portability and maintainence!! It is very >difficult to keep translating the stupid mults/divs, and if AmigaDOS >is ever replaced, your application is dead, whereas if you relied on >stdio all you'd have to do is recompile. Read me previous comment. >*** FLAME ***: Why does so much of lc.lib get included, even if it >is not used? If this was fixed (by BLINK (the official linker, these >days) or Lattice) all would be well. > >CONCLUSION: If you are stuck with Lattice (it is, after all, blessed >by CBM) then if you take some time you can shrink code size down a lot >for applications that are very Amiga specific by getting rid of lc.lib. Previous releases of Lattice caused a huge amount of their library to be included due to bad organization. (i.e. Lstartup.obj made reference to stdio, and this wound up causing the inclusing of almost all of stdio). Of course, I agree with you on most points... that is why I developed MY.LIB, which provides an alternate buffered file interface (I call xstdio), plus memory and string manipulation functions, plus some other little goodies to make life easier. I will be releasing the latest MY.LIB for both Lattice and Manx as soon as my midterms are over! -Matt