lbg@gitpyr.UUCP (Lee B Grey, Programmer Extraordinaire) (10/08/85)
I think I have discovered why I was unable to resolve the external reference to __pow. It was not something I could do in the linker. What was missing was a call to OpenLibrary() to get at the math routines. I learned this by going through some examples in the Intuition manual, but the actual reference info on this is found in the ROM Kernal manual. I haven't tried it yet, but I am sure that this is the answer. By the way, to the person asking if ALINK was the way to transfer files... No. ALINK is the AmigaDOS linker. For file transfer, there are the programs READ and DOWNLOAD, which I believe are on the Lattice C, Assembler, and Wack disks (all 3). I haven't got a modem at this time, so I haven't tried them. By the way, I got no responses, so let me ask again. Does anyone think it is possible for me to transfer files from my PC to my Amiga in the following way? I was thinking I could "print" the files from the PC, through the parallel port, thru the printer cable, and into the Amiga parallel port. The Amiga documentation claims that it accepts input as serial or parallel. Whaddaya think? Lee
gary@cirl.UUCP (Gary Girzon) (10/08/85)
> By the way, I got no responses, so let me ask again. Does anyone > think it is possible for me to transfer files from my PC to my > Amiga in the following way? I was thinking I could "print" the > files from the PC, through the parallel port, thru the printer cable, > and into the Amiga parallel port. The Amiga documentation claims > that it accepts input as serial or parallel. Whaddaya think? > > Lee Yes, you should be able to do this. The READ command implements some sort of loading scheme, however, I believe you must convert your files on the PC into hex-character format. That is each ASCII byte must be represented by two hex ASCII bytes. This is documented in the DOS Developers Manual. On the other hand, if you send output to the PC parallel port, and then instruct the AMIGA 1> copy par: to filename that whould work, although I wonder what the EOF (end of file) is. How does the AMIGA know when to stop? UUCP: ...{ihnp4,harvard}!think!cirl!gary
johnbl@tekig5.UUCP (John Blankenagel) (10/09/85)
> > By the way, I got no responses, so let me ask again. Does anyone > think it is possible for me to transfer files from my PC to my > Amiga in the following way? I was thinking I could "print" the > files from the PC, through the parallel port, thru the printer cable, > and into the Amiga parallel port. The Amiga documentation claims > that it accepts input as serial or parallel. Whaddaya think? > > Lee No reason it shouldn't work. It will work on other computers I have used, why not the amiga. Give it a try and let us know how well it does work. John Blankenagel
mykes@3comvax.UUCP (06/23/86)
Here is a suggestion for a product that I haven't seen yet for the Amiga, in case someone out there has the time to do it. Everyone typically thinks of a "library manager" as a program that builds/extracts/adds binary object modules to a collection of modules (the Library), which the linker can use to link with. However, the Amiga supports a different kind of library, which can be loaded and used by many programs at the same time (i.e. translator.library). 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. The problem is that these libraries are not 'C' oriented and have a lot of BCPL type of things in them. 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. 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:), which is significant when we all realize how short memory really is. Matt Dillon's CLI shell could do NEWCLI's as well, without requiring 30K+ (or however big it is now) for each copy. OK, so what is involved in making such a librarian? Well, at least there is the BCPL environment stuff that must be maintained (why not have a machine do this tedious work), as well as jump tables, linking in new modules, removing old modules, etc. Then there is the problem of letting the ROM Kernel know that there is a new library. 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. And when the library maker is done, there is always a device maker to do...
kim@mips.UUCP (06/25/86)
[ "Send lawyers, guns, and money ..." ] > Here is a suggestion for a product that I haven't seen yet for the Amiga, > > [ ... discussion of runtime libs ... ] > > OK, so what is involved in making such a librarian? Well, at least there > is the BCPL environment stuff that must be maintained (why not have a machine > do this tedious work), as well as jump tables, linking in new modules, > removing old modules, etc. Then there is the problem of letting the ROM > Kernel know that there is a new library. 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. Seems like a VERY good idea, Mike. One other requirement on any runtime library code is that it MUST be fully reentrent ... I dunno if printf or other standard functions qualify on this point. /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 408-720-1700 x231 USPS: MIPS Computer Systems Inc, 930 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (06/25/86)
In article <552@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >... Everyone typically thinks >of a "library manager" as a program that builds/extracts/adds binary object >modules to a collection of modules (the Library), which the linker can use >to link with. However, the Amiga supports a different kind of library, which >can be loaded and used by many programs at the same time (i.e. >translator.library). 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! >The problem is that these libraries are not 'C' oriented and have a lot of >BCPL type of things in them. WRONG. >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. Ya don't say? Well, it just so happens, the 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. >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. >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. >Well, at least there is the BCPL environment stuff that must be maintained >as well as jump tables, linking in new modules, >removing old modules, etc. I'm not sure that you're clear on how PROGRAMS call library routines. When you link your C programs together, your calls to RK routines are actually calls to "stubs" extracted from the link-library (e.g. lc.lib, or c.lib, whatever). These stubs use the pointer you initialize when you open a library (e.g, IntuitionBase) and offset from there to call the appropriate routine indirectly through a vector table. You may have wondered why when you open a library, you HAVE to use the variables in the examples. That's because they're referenced by the stubs. Also, that's why they HAVE to be global to your program. >Then there is the problem of letting the ROM >Kernel know that there is a new library. This happens automatically when a program tries to open the library. If it already open, Exec's OpenLibrary() simply returns a pointer to the RAM resident copy. >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. >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. Here speaketh a weary man of experience in this department, Paul Higginbottom Disclaimer: I do not work for Commodore, and opinions expressed are my own.
mykes@3comvax.UUCP (Mike Schwartz) (06/26/86)
In article <452@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >In article <552@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >>... Everyone typically thinks >>of a "library manager" as a program that builds/extracts/adds binary object >>modules to a collection of modules (the Library), which the linker can use >>to link with. However, the Amiga supports a different kind of library, which >>can be loaded and used by many programs at the same time (i.e. >>translator.library). 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? Read the sentence, it says it seems near impossible to make use of the libraries... Maybe for Paul's sake, I should duplicate all my lines, maybe he'll read what I wrote:) > > >>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. > > Ya don't say? Well, it just so happens, the 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. Your logic is: loadable libraries isn't unique to the Amiga, so that means it is not a feature of the Amiga? Using them does take more advantage of the Amiga's software design. You criticize without reading, chum. >>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. 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. >>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! 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. > >>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? >>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. > Here speaketh a weary man of experience in this department, > > Paul Higginbottom Way to be man of experience... >Disclaimer: I do not work for Commodore, and opinions expressed are my own.
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (06/27/86)
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.
rico@oscvax.UUCP (06/28/86)
In article <552@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >Here is a suggestion for a product that I haven't seen yet for the Amiga, >in case someone out there has the time to do it. Everyone typically thinks >of a "library manager" as a program that builds/extracts/adds binary object >modules to a collection of modules (the Library), which the linker can use >to link with. However, the Amiga supports a different kind of library, which >can be loaded and used by many programs at the same time (i.e. >translator.library). >... etc... This seems like a top notch idea to me. Not only would this reduce the size of executables, but it would also enable you to change many aspects of the program without having the source. I hope someone with time on their hands takes a likeing to this idea. It would be real nice if this became a standard thing. I think it should be done ala the Macintosh's resource editor 'ResEdit' (or something like that). Are you listening Lattice? Aztec? -Rico