Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!cbmvax!higgin From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom) Newsgroups: net.micro.amiga Subject: Re: Re: Libraries Message-ID: <465@cbmvax.cbmvax.cbm.UUCP> Date: Fri, 27-Jun-86 16:23:24 EDT Article-I.D.: cbmvax.465 Posted: Fri Jun 27 16:23:24 1986 Date-Received: Sun, 29-Jun-86 05:55:15 EDT References: <552@3comvax.UUCP> <452@cbmvax.cbmvax.cbm.UUCP> <559@3comvax.UUCP> Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom) Followup-To: Re: Libraries Organization: Commodore Technology, West Chester, PA Lines: 148 Summary: In article <559@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >In article <452@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >>In article <552@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >>>... >>>These libraries are much more impressive and powerful >>>than the standard libraries, yet it seems near impossible to make use of this >>>power by simply generating new libraries as applications demand it. >> ^^^^^^ >> >> HA HA HA! >What is the laugh about? My apologies, Mike, but I think you misinterpreted me. I was not laughing at the sentence, only the adjective "simply" in regard to generating new libraries, as I have to do it all the time, and it's tedious, despite having written a bunch of runtime library management utilities now. >> >> >>>To me, it seems obvious that a librarian that >>>allowed for the addition, removal, etc., of modules from LOADABLE libraries >>>would radically change the way we develop programs and would not only make >>>Amiga programs smaller (one copy of the library for all programs who use >>>it, instead of each program having it's own copy of the required routines), >>>but would also take more advantage of the Amiga's software design. >> >>Well, it just so happens, that myself and two colleagues >>have written our own loadable-(shared)library to do what you say, and it was >>a REAL PAIN IN THE BEHIND. The idea of loadable libraries certainly isn't >>unique to the Amiga, either. >> >Well, you proved my point, it's a pain in the behind, so getting the machine >to do the work might be a good idea. We agree, we agree! But, I already HAVE a system where I can add, change and remove modules to and from a run-timelibrary, and it's STILL a pain, so I was merely saying that I didn't really know what could be done to make it easier. Changing the library on the FLY (which is NOT what we do, we re-compile/assemble each time) would be good (I assume using the AddLibrary() SetFunction() routines), but if the way a function works changes SIGNIFICANTLY then the programs that use these routines will probably have to be recompiled. I don't see much of a way around that. Additionally, adding and removing modules means the changing of a link-library which is required when linking programs which are to use the functions in the run-time library. This means a re-assembly of the stub library. >Your logic is: loadable libraries isn't >unique to the Amiga, so that means it is not a feature of the Amiga? I didn't say that. It IS a feature. I just thought you were implying that 'unlike other machines that only have link libraries, the Amiga has loadable libraries', and I was merely saying it wasn't unique to the Amiga. I did think you were mixing the two TOTALLY different meanings of the word "library". >>>So, what would such a librarian be used for? Well, let's see, if you put >>>printf() and the rest of the Lattice library into a runnable library, evey >>>'C' program instantly becomes 10K shorter (or is it 15K:)... >> >> We did this. Under Aztec C though, printf( only accouts for about 4K. >> >Some people use lattice, I don't, but 15K is meaningful to those who do. > Of course! But to bring up (yawn) a subject that has been beaten to death, it's not printf that's adding 15K, it's Lattice massive main/exit stuff. Also, if ALL the Lattice routines were put into a run-time library, I think you'd be surprised as to how little memory is left in the machine. Granted a lot of small programs could be made then, but a lot of the functions in any given link library are rarely used. But I don't disagree that putting popular functions in a run-time library is a good idea, and as I say, we did just that to save memory when multiple programs are doing the same thing, and also, by putting routines into a run-time library, you only have to debug them in one place! >I also mentioned other uses for these libraries, like CLI programs that would >save lots of memory with every "newcli" that is run by not having routines >that could be in a library duplicated in every instance of the CLI. I very much doubt if NewCli is a re-entrant routine. There must be global variables in it. Thus, I doubt if it could be put into a library. >>>OK, so what is involved in making such a librarian? >> >> Lots! believe me. Look at appendix K in the Rom Kernel manual volume >>2, and you'll see what Amiga calls a "skeleton" library. There is NO >>EXPLANATION of this anywhere except for the comments in it. Good luck, Mr. >>Phelps. >> >I never said the librarian would be an easy program to write. Give me a >break! You're taking my comment personally. I was merely letting you and others know that they will be in for a bit of a shock if they think they can knock off a quick run-time library easily. If you already knew that, then fine! My reply to your message will [probably] be read by others, too. >The trick is to generate a file similar to what the "skeleton" >generates when assembled. Computers aren't smart, they are pretty stupid... >I hate to break the news to you, but the Amiga will never know that a >library was generated by the Assembler, Manx's assembler, or by the librarian >I suggest. > Well, you know what they say about sarcasm... >> >>>Also, there might need to be more >>>information kept about the library than the library allows for (and still is >>>recognized as a library) - this stuff can be kept in a separate file with >>>a special dot extension or something. >> >>Huh? A library can keep track of whatever it pleases. >> >OK, since I got such a nice lecture about how libraries work (my previous >article got merged with one about the DEVICE maker, so it talked about >BCPL stuff), I guess I gotta tell you about object module librarians... > >When you have a runable library librarian, it must be able to remove >and add subroutines as you recompile them. You don't need to link everything >together all the time to build the library. You keep things like back-patch >lists SOMEWHERE (like how about in a different file, now do you understand) >so that you can cleanly remove/unlink individual functions from a library and >link in new ones. This linkage information is necessary, but is not part >of the library file itself. How can the library keep track of this stuff >itself? 'Tis true, I misunderstood you, I thought you meant that a runtime library needs separate files to keep track of things. Yes, this 'clever' program that will modify the library "in-place" will certainly need to know the 'state' of the library. >>>And when the library maker is done, there is always a device maker to do... >> >>Once you've done one, the other is a piece of cake. >> >Neither is a piece of cake, but either would be very valuble. I don't understand your retort because my comment is still true, because run-time libraries and devices are so similar. Hopefully this time around we understand eachother a little better. Regards, Paul Higginbottom. Disclaimer: I do not work for Commodore, and opinions expressed are my own.