jms@tardis.Tymnet.COM (Joe Smith) (05/06/91)
In article <1991May5.011748.11595@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >dvljrt@cs.umu.se (Joakim Rosqvist) writes: >> OpenLib=-408 >> Output=-60 >> Write=-48 >> jsr OpenLib(a6) >> jsr Output(a6) >> jmp write(a6) > >You've managed, in a 15 line program, to include 3 "magic numbers" >that are dependent on the release of dos.library, so that your code need >not merely be reassembled for an operating system upgrade, but rewritten. I was about to post an article saying "don't be absurd, Kent. If Commodore were to change the library offsets, existing binaries would stop working, therefore the offsets are engraved in stone; they will never change." But then I remembered that some of them HAVE changed. OpenLibrary used to be -408, now it is -552. Offset -408 is still supported, however, as OldOpenLibrary. Using the old definitions is works, the program won't get the newest features. >Doing the linker's job for it is _not_ a smart move, as the first >three lines clearly demonstrate. Using the most recent *.h or *.i files is just as good as letting the linker get the definitions out of amiga.lib. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/06/91)
In article <1991May4.134045.7550@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >In article <1200@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>In article <1991May2.102554.8679@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>> >>>Ok, assembler strikes back with this: (56 codesize, 92 executable) >> >>Shame on you, you cheated! You do an OpenLib without a CloseLib! >>Perhaps this explains the difference. >> >I did not! It's ok to close a disk-library, but DosLib is in ROM, and >Closing it is the same as adding NOP's to the code. Anyway, with a >closelib it will be 60/96 bytes. Still shorter! >If you don't agree with me, reply in Amiga.programmer... Well, we had a lengthy discussion on this in the German sub.sys.amiga group. We came to the conclusion that it would really be dangerous! Because, if your Amiga runs long enough and runs such programs in a tight loop, the use counter of the library will be increased every time. And, after *some* (:-) time, it will wrap around to zero. And, if it happens that you have a tight memory situation just in this moment and exec flushes all unused libs: POOF! I admit, not an everyday scenario, but sure possible :-). You see, there was a related discussion whether you should check for success of opening dos.library (or which lib was it?) at all, because theoretically you always will succeed. But also there it was concluded that you better use the safe way. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
kilian@cinnet.com (Kilian Jacob) (05/07/91)
From article <1804@tardis.Tymnet.COM>, by jms@tardis.Tymnet.COM (Joe Smith): > In article <1991May5.011748.11595@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>> OpenLib=-408 [deleted] > But then I remembered that some of them HAVE changed. OpenLibrary used to > be -408, now it is -552. Offset -408 is still supported, however, as > OldOpenLibrary. Using the old definitions is works, the program won't get > the newest features. > I think OldOpenLibrary() is used here on purpose. This way you can omit the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific version (or higher) is need in this example using OldOpenLibrary is perfectly ok -- saves 2 bytes!! :-) -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
dvljrt@cs.umu.se (Joakim Rosqvist) (05/07/91)
In article <1205@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991May4.134045.7550@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>In article <1200@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>>In article <1991May2.102554.8679@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>>> >>>>Ok, assembler strikes back with this: (56 codesize, 92 executable) >>> >>>Shame on you, you cheated! You do an OpenLib without a CloseLib! >>>Perhaps this explains the difference. >>> >>I did not! It's ok to close a disk-library, but DosLib is in ROM, and >>Closing it is the same as adding NOP's to the code. Anyway, with a >>closelib it will be 60/96 bytes. Still shorter! >>If you don't agree with me, reply in Amiga.programmer... > >Well, we had a lengthy discussion on this in the German sub.sys.amiga >group. We came to the conclusion that it would really be dangerous! >Because, if your Amiga runs long enough and runs such programs in a >tight loop, the use counter of the library will be increased every time. >And, after *some* (:-) time, it will wrap around to zero. And, if it >happens that you have a tight memory situation just in this moment and >exec flushes all unused libs: POOF! I admit, not an everyday scenario, >but sure possible :-). > > Normally, I would take that as a flame, but my FlameCnt for the "Hello World" posting just wrapped around :-) /$DR.HEX$
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/08/91)
peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991May4.134045.7550@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>In article <1200@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>>In article <1991May2.102554.8679@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>>> >>>>Ok, assembler strikes back with this: (56 codesize, 92 executable) >>> >>>Shame on you, you cheated! You do an OpenLib without a CloseLib! >>>Perhaps this explains the difference. >>> >>I did not! It's ok to close a disk-library, but DosLib is in ROM, and >>Closing it is the same as adding NOP's to the code. Anyway, with a >>closelib it will be 60/96 bytes. Still shorter! >>If you don't agree with me, reply in Amiga.programmer... > >Well, we had a lengthy discussion on this in the German sub.sys.amiga >group. We came to the conclusion that it would really be dangerous! >Because, if your Amiga runs long enough and runs such programs in a >tight loop, the use counter of the library will be increased every time. >And, after *some* (:-) time, it will wrap around to zero. And, if it >happens that you have a tight memory situation just in this moment and >exec flushes all unused libs: POOF! I admit, not an everyday scenario, >but sure possible :-). > >You see, there was a related discussion whether you should check for >success of opening dos.library (or which lib was it?) at all, because >theoretically you always will succeed. But also there it was concluded >that you better use the safe way. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk not to mention that there is SOME RAM overhead for opening a library anyways, if you happen to have all memory allocated and then try to open a library.. it won't succeed, that is a MUCH more common occurance. I think commodore should DEFINATELY squelch this rumor that rom calls will always succeed. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
micja@ida.liu.se (Michael Jansson) (05/08/91)
In article <1205@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: [Stuff deleted about small 'Hello'-programs] >Well, we had a lengthy discussion on this in the German sub.sys.amiga >group. We came to the conclusion that it would really be dangerous! >Because, if your Amiga runs long enough and runs such programs in a >tight loop, the use counter of the library will be increased every time. >And, after *some* (:-) time, it will wrap around to zero. And, if it >happens that you have a tight memory situation just in this moment and >exec flushes all unused libs: POOF! I admit, not an everyday scenario, >but sure possible :-). That is not really true (unless I got it all backwards). A library will stay resident until there is a shortage of memory AND the Expunge function (every library has one), which is called when Exec attempts to remove the un-used library, returns the segment of the library itself. In other words - The library is only flushed if the library admits it, which might not be the case for the ROM-based libraries (my guess is that they are un-removable since they are never loaded with LoadSeg). I have used this feature in a library of mine. The library will eat a lot of memory, which can be returned to the system if needed. I managed to do this by writing a neat little garbage collector and put it where the Expunge function should be. I also bookkeep the number of users of the library separately, i.e. not in the library structure that Exec knows of, so that Exec will be convinced that the library is unused when it is not. So what will this give me? Exec will attempt to remove the library whenever there is a shortage of memory which will result in a call to my new Expunge function, that will return some memory without removing itself, i.e. an automatic GC. It works too! (At least so far ;-). [Other stuff deleted] >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk -- ########################################################## # Michael Jansson | \_/ # Internet: mij@IDA.LIU.SE | V _|_ # UUCP: uunet!liuida!mij | | Absolut Software| # BITNET: mij@SELIUIDA | ~~~
kilian@cinnet.com (Kilian Jacob) (05/09/91)
From article <1205@cbmger.UUCP>, by peterk@cbmger.UUCP (Peter Kittel GERMANY): > In article <1991May4.134045.7550@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>In article <1200@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>>In article <1991May2.102554.8679@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>>> >>>>Ok, assembler strikes back with this: (56 codesize, 92 executable) >>> >>>Shame on you, you cheated! You do an OpenLib without a CloseLib! >>>Perhaps this explains the difference. >>> >>I did not! It's ok to close a disk-library, but DosLib is in ROM, and >>Closing it is the same as adding NOP's to the code. Anyway, with a >>closelib it will be 60/96 bytes. Still shorter! >>If you don't agree with me, reply in Amiga.programmer... > > Well, we had a lengthy discussion on this in the German sub.sys.amiga > group. We came to the conclusion that it would really be dangerous! > Because, if your Amiga runs long enough and runs such programs in a > tight loop, the use counter of the library will be increased every time. > And, after *some* (:-) time, it will wrap around to zero. And, if it > happens that you have a tight memory situation just in this moment and > exec flushes all unused libs: POOF! I admit, not an everyday scenario, > but sure possible :-). > To be exact: You'll have to call that program about 65000 times (Library.OpenCnt is a UWORD.) and then wait for a low memory situation. If you call that program 20 times a day, it'll take at least 10 years. I think my A500 would die before that happenes.. :-) > theoretically you always will succeed. But also there it was concluded > that you better use the safe way. Agreed. -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/09/91)
In article <1205@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991May4.134045.7550@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>In article <1200@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >>>In article <1991May2.102554.8679@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>>> >>>>Ok, assembler strikes back with this: (56 codesize, 92 executable) >>> >>>Shame on you, you cheated! You do an OpenLib without a CloseLib! >>>Perhaps this explains the difference. >>> >>I did not! It's ok to close a disk-library, but DosLib is in ROM, and >>Closing it is the same as adding NOP's to the code. Anyway, with a >>closelib it will be 60/96 bytes. Still shorter! >>If you don't agree with me, reply in Amiga.programmer... > >Well, we had a lengthy discussion on this in the German sub.sys.amiga >group. We came to the conclusion that it would really be dangerous! >Because, if your Amiga runs long enough and runs such programs in a >tight loop, the use counter of the library will be increased every time. >And, after *some* (:-) time, it will wrap around to zero. And, if it >happens that you have a tight memory situation just in this moment and >exec flushes all unused libs: POOF! I admit, not an everyday scenario, >but sure possible :-). > >You see, there was a related discussion whether you should check for >success of opening dos.library (or which lib was it?) at all, because >theoretically you always will succeed. But also there it was concluded >that you better use the safe way. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk Another note: You probably want to also use a specific version number, especially if you want to do 2.0 specific things. For example, the 2.0 Dos library lets you do SetFunction(), while the 1.3 doesn't. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/09/91)
In article <1991May7.001146.1830@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: > >I think OldOpenLibrary() is used here on purpose. This way you can omit >the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific >version (or higher) is need in this example using OldOpenLibrary is perfectly >ok -- saves 2 bytes!! :-) > >-- /<ilian >-- >Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 >UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian Certainly less code ... two bytes, but not faster since OldOpenLibrary() most likely just calls OpenLibrary() after loading a #0 into D0. sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two instructions are both one word long. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/09/91)
kilian@cinnet.com (Kilian Jacob) writes: >From article <1804@tardis.Tymnet.COM>, by jms@tardis.Tymnet.COM (Joe Smith): >> In article <1991May5.011748.11595@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>>dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>>> OpenLib=-408 > >[deleted] > >> But then I remembered that some of them HAVE changed. OpenLibrary used to >> be -408, now it is -552. Offset -408 is still supported, however, as >> OldOpenLibrary. Using the old definitions is works, the program won't get >> the newest features. >> >I think OldOpenLibrary() is used here on purpose. This way you can omit >the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific >version (or higher) is need in this example using OldOpenLibrary is perfectly >ok -- saves 2 bytes!! :-) > >-- /<ilian >-- >Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 >UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian But NOT guaranteed to continue to be supported. they COULD remove OldOpenLibrary in the next OS release. They tell you not to use it. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
dvljrt@cs.umu.se (Joakim Rosqvist) (05/10/91)
> sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two > instructions are both one word long. > > -Matt Actually, it is slower. sub.l d0,d0 takes 8 cycles and moveq #0,d0 takes 4. /$DR.HEX$
baxter_a@wehi.dn.mu.oz (05/11/91)
In article <1991May8.180919.8732@cinnet.com>, kilian@cinnet.com (Kilian Jacob) writes: >> > To be exact: You'll have to call that program about 65000 times > (Library.OpenCnt is a UWORD.) and then wait for a low memory situation. > If you call that program 20 times a day, it'll take at least 10 years. ^^^^^^^^^^^^^^ Lattice C used to always leave the library open and I got the count to 48 in about 1/2 an hour. Many people leave their machines on for extended periods, often running automatic macros than might run a function up to 10 times a second. I think the library should probably be closed. Regards Alan
sschaem@starnet.uucp (Stephan Schaem) (05/11/91)
And to add to sub.l Dn,Dn... Moveq is faster on the 68000 4 compared to 8, 4 compared to 6 on a 68010, and same timing on a 68020... a word size sub on data registers is the same has clr.w... on all above 680x0. Conclusion.Dont use sub.l dn,dn or sub.w dn,dn use moveq #0,dn and clr.w dn.... Stephan.
kilian@cinnet.com (Kilian Jacob) (05/12/91)
Subject: Re: Short Hello World >You miss the point, Kilian; the programs run the same, but if the jump >table changes (another posting noted that the 400 is already a >deprecated address for the old version of a superseded funcion), having >the jump table constants hard coded in your program means you have to >change your code for it to run again; using the ones the manufacturer >supplies in the header files (I shouldn't have said linker, I had my >mind on something Mike Schwartz said earlier), all you need to do is >rerun the assembly, and you're up and running again. >Yes, you're doing exactly the same thing the header file is doing, but >that's just the point; _you_ are doing it, but you are not the one who >controls where those jump points are located, so you should be using >the mechanism that lets the "owner" of those values tell you what they >are, and that is the names as defined in the appropriate include file. > >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> Ok - I see the point: If you use the .i files you would only have to reassemble your program (using the *new* .i files). Well, theoratically, you're right. In reality, though, there is no reason to change (or interchange, to be excact) library vector offsets. The only reason I see why OldOpenLibrary() one day might not have the offset -408 is that Commdore dicided to get rid of it. In that case neither program (the one that uses the .i files nor the one that doesn't) would work by simply reassemblying it. In both cases you would have to insert a sub.l d0,d0 before the function call and use OpenLibrary() instead. This might happen in two case: Either Commodore runs out of space in the Kickstart ROM and thus needs to get rid of obsolete functions (rather small chances that they remove OldOpenLibrary() -- it only takes up a couple of bytes.) or Commodore exceeds the limit of max. 5461 functions per library (2^15 bytes / 6 bytes per offset). Well, howmany functions are there in the current version of the exec.library? :-) -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/13/91)
In article <1991May11.072139.781@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > And to add to sub.l Dn,Dn... Moveq is faster on the 68000 4 compared to > 8, 4 compared to 6 on a 68010, and same timing on a 68020... > a word size sub on data registers is the same has clr.w... on all above > 680x0. > > Conclusion.Dont use sub.l dn,dn or sub.w dn,dn use moveq #0,dn and > clr.w dn.... > > Stephan. Uh, actually, you don't want to use CLR either if you can help it because CLR always *reads* the ea before writing a 0 to it. This true all the way through 020's at least. For word operations it isn't too bad, but take a look at clr.l D0 ... 6 cycles on a 68000. MOVEQ is faster. And on memory CLR.<anything> is horrific since it reads the memory location before writing it. Before people get huffy about CLR, please remember that Motorola has gotten CLR's instruction timings wrong in every other edition of their handbook. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
bart@asgard.pub.uu.oz.au (John Butcher) (05/13/91)
In article <dillon.7447@overload.Berkeley.CA.US>, Matthew Dillon writes: > sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two > instructions are both one word long. What you say is right, but the reasons behind it are worng. Instruction length != instruction timing : sub.l d0,d0 == 6 ( or is it 8 ?? ) moveq.l #0,d0 == 4 > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA ----------------------------------------------------------------------------- John Butcher : bart@asgard.pub.uu.oz.au ..!munnari!eyrie.oz.au!asgard!bart "To understand recursion you must understand recursion" - Andrew Koenig
rbabel@babylon.rmt.sub.org (Ralph Babel) (05/13/91)
In article <dillon.7621@overload.Berkeley.CA.US>, dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > Uh, actually, you don't want to use CLR either if you can help it > because CLR always *reads* the ea before writing a 0 to it. This > true all the way through 020's at least. Only the 68000 and the 68008 are affected. BTW: Does DICE offer an option to avoid the CLR instruction (e.g. on volatile objects)? Ralph
kilian@cinnet.com (Kilian Jacob) (05/14/91)
From article <4872@orbit.cts.com>, by chucks@pnet51.orb.mn.org (Erik Funkenbusch): > kilian@cinnet.com (Kilian Jacob) writes: [deleted] >>I think OldOpenLibrary() is used here on purpose. This way you can omit >>the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific >>version (or higher) is need in this example using OldOpenLibrary is perfectly >>ok -- saves 2 bytes!! :-) > > But NOT guaranteed to continue to be supported. they COULD remove > OldOpenLibrary in the next OS release. They tell you not to use it. > Why why should they remove it? It only takes up a couple of bytes. BTW: Who is 'they' ? Does *Commodore* say OldOpenLibrary should not be used? -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
kilian@cinnet.com (Kilian Jacob) (05/14/91)
From article <dillon.7447@overload.Berkeley.CA.US>, by dillon@overload.Berkeley.CA.US (Matthew Dillon): > In article <1991May7.001146.1830@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: >> >>I think OldOpenLibrary() is used here on purpose. This way you can omit >>the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific >>version (or higher) is need in this example using OldOpenLibrary is perfectly >>ok -- saves 2 bytes!! :-) > > Certainly less code ... two bytes, but not faster since OldOpenLibrary() > most likely just calls OpenLibrary() after loading a #0 into D0. > Yes, that's what I figured. But since you usually open the library just once (within a program), speed isn't an issue. > sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two > instructions are both one word long. > > -Matt Oops. Thanks for pointing that out. -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
brett@visix.com (Brett Bourbin) (05/14/91)
In article <dillon.7621@overload.Berkeley.CA.US>, dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: |> Uh, actually, you don't want to use CLR either if you can help it |> because CLR always *reads* the ea before writing a 0 to it. This |> true all the way through 020's at least. Doesn't this also introduce problems with the custom chips, since you can say something like "clear the COPPER 1 STROBE" with the CLR.W cop1xxx(AX) command. This would read the register before writing the zero. I am not sure about the COPPER STROBE, but I know some write-only registers get very picky when you try to read them. |> Matthew Dillon dillon@Overload.Berkeley.CA.US -- __ Brett Bourbin \ / /(_ /\/ 11440 Commerce Park Drive ..!uunet!visix!brett \/ / __)/ /\ Reston, Virginia 22091 brett@visix.com Software Inc (703) 758-2733
sschaem@starnet.uucp (Stephan Schaem) (05/14/91)
Are you telling me that clr.w d0 dont take 4 cycle?! And If I use clr its when I dont want to modify any register and dont care about speed but size... Stephan.
markv@kuhub.cc.ukans.edu (05/14/91)
>> But NOT guaranteed to continue to be supported. they COULD remove >> OldOpenLibrary in the next OS release. They tell you not to use it. >> > Why why should they remove it? It only takes up a couple of bytes. Ehh, if you've listened to some of the discussion earlier, space in the 512K ROMs is tighter than all getout. So Commodore could very well want to kill it. > BTW: Who is 'they' ? Does *Commodore* say OldOpenLibrary should not be used? Yes, it is officially "obsolete". Besides, if you are happy with any version of a library, just OpenLibrary("foo.library", 0L). *And* since you only open a library once per program, by the time you read the executable off the disk, wait a few bazillion cycles for user interaction, etc. I don't suspect the extra few cycles make one bit of difference. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/15/91)
In article <1991May14.041050.20607@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > > Are you telling me that clr.w d0 dont take 4 cycle?! > And If I use clr its when I dont want to modify any register and dont > care about speed but size... > > > Stephan. clr.w d0 takes 4 cycles, but clr.l d0 takes 6. moveq.l #0,d0 takes 4 cycles. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/15/91)
In article <19216341.ARN0401@asgard.pub.uu.oz.au> bart@asgard.pub.uu.oz.au (John Butcher) writes: >In article <dillon.7447@overload.Berkeley.CA.US>, Matthew Dillon writes: > >> sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two >> instructions are both one word long. > >What you say is right, but the reasons behind it are worng. >Instruction length != instruction timing : >sub.l d0,d0 == 6 ( or is it 8 ?? ) >moveq.l #0,d0 == 4 Huh? I said that sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000 even though they are the same size. I NEVER said that instruction length == instruction timing. In fact, my original statement says the exact reverse. >----------------------------------------------------------------------------- > John Butcher : bart@asgard.pub.uu.oz.au > ..!munnari!eyrie.oz.au!asgard!bart >"To understand recursion you must understand recursion" - Andrew Koenig -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/15/91)
kilian@cinnet.com (Kilian Jacob) writes: >From article <4872@orbit.cts.com>, by chucks@pnet51.orb.mn.org (Erik Funkenbusch): >> kilian@cinnet.com (Kilian Jacob) writes: >[deleted] >>>I think OldOpenLibrary() is used here on purpose. This way you can omit >>>the moveq.l #0,d0 (or sub.l d0,d0 -- faster, I believe). Since no specific >>>version (or higher) is need in this example using OldOpenLibrary is perfectly >>>ok -- saves 2 bytes!! :-) >> >> But NOT guaranteed to continue to be supported. they COULD remove >> OldOpenLibrary in the next OS release. They tell you not to use it. >> >Why why should they remove it? It only takes up a couple of bytes. > >BTW: Who is 'they' ? Does *Commodore* say OldOpenLibrary should not be used? Yes, "they" are commodore, and they have said not to use it for quite some time. ever since 1.2 i think, or was it 1.1? i don't remember, but it is no longer supported and NOT guaranteed to continue to be there. supose they get short on rom space for 3.0.. guess what will probably go, all the unsupported functions. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
sschaem@starnet.uucp (Stephan Schaem) (05/15/91)
Yea, like CBM will KILL all early software written for the amiga do win 8 bytes! (Hope people jok when they talk about CBM replacing/removing a library function ) Oldopenlibrary is 'slower' and how cares about using 2 more byte of code to use OpenLibrary...? Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/15/91)
Maybe I wasn't clear? I said moveq #0,Dn and clr.w dn... (Or sub.w d0,d0, depand if you want to get that X condition code untouched or not).... The above to clear data register in .l and .w 'mode'. For Adress sub.l sub.w... Hope this clarify. Everybody has 680x0 timings! And hopefully know them by heart:-) Stephan.
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/16/91)
In article <07867.AA07867@babylon.rmt.sub.org> rbabel@babylon.rmt.sub.org (Ralph Babel) writes: >In article <dillon.7621@overload.Berkeley.CA.US>, >dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > >> Uh, actually, you don't want to use CLR either if you can help it >> because CLR always *reads* the ea before writing a 0 to it. This >> true all the way through 020's at least. > >Only the 68000 and the 68008 are affected. BTW: Does DICE >offer an option to avoid the CLR instruction (e.g. on >volatile objects)? > >Ralph DICE only uses CLR in a few cases such as when pushing 0 on the stack (as a space optimization). Beyond that, it never uses CLR except on registers sometimes. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/16/91)
In article <1991May14.041050.20607@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > > Are you telling me that clr.w d0 dont take 4 cycle?! > And If I use clr its when I dont want to modify any register and dont > care about speed but size... > > > Stephan. CLR.W D0 ; 4 CLR.L D0 ; 6 MOVEQ #0,D0 ; 4 CLR.W memory ; 4+4+4=12 (not incl. effective addr calc) CLR.L memory ; 4+8+8=20 Remember, the 68000 handbook is *wrong* -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/16/91)
In article <1991May15.103610.12158@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes:
Yea, like CBM will KILL all early software written for the amiga do
win 8 bytes! (Hope people jok when they talk about CBM
replacing/removing a library function )
Nope, we're not joking. With 2.0, there are lots of replacements for
"old" library entries, and CBM is universally telling people not to
use the old version of the call.
Now, go down the road to the next major OS release (3.0?). Judging
from past experience, that's 5+ years away. That means that the only
correctly written software that would be broken by deleting the old
entries (or better - at least at that point - replacing them with an
error return) is five or more years old. That kind of software is
either 1) run by someone who's not fallen for the "have to have the
latest and greatest" trap, and so probably won't upgrade their OS, or
2) been orphaned for at least five years. The latter is part of life.
<mike
--
When logic and proportion have fallen softly dead, Mike Meyer
And the white knight is talking backwards, mwm@pa.dec.com
And the red queen's off her head, decwrl!mwm
Remember what the dormouse said.sschaem@starnet.uucp (Stephan Schaem) (05/16/91)
So should we expect to recompile our code every 5 years?! Because CBM will remove some function we used and dont support anymore! I cant beleive it even if it come from CBM :-) And the size 'excuse' is pretty funny when you think the major part of what is in ROM is written in C. And What 1.x calls CBM said not to use anymore because it might desapear? Dont you think they gave alternate function? Some people might NOT want to do 2.0 softare compatible only... Stephan.
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/16/91)
sschaem@starnet.uucp (Stephan Schaem) writes: > > Yea, like CBM will KILL all early software written for the amiga do > win 8 bytes! (Hope people jok when they talk about CBM > replacing/removing a library function ) > Oldopenlibrary is 'slower' and how cares about using 2 more byte of > code to use OpenLibrary...? > > Stephan. Yes, commodore probably WILL eventually kill most code from early 1.0 days. who runs anything that hasn't been updated to at least 1.1? very few people do and only then for nostalgia reasons, witness a comment made several days ago on this net about Mind Walker. I think it's a good idea personally, they are trying to phase out BCPL as well. on day anything written with BPTR's will not work either. that's part of the reason commodore is pushing 2.0 so hard, and why they AREN"T pushing backward 1.3 compatibility. not just because it's new, but when everyone's moved over to 2.0 they can kill ALOT of old mistakes. I don't think 1.3 compatibility should be an issue for the 3000 since they are now selling them hand over fist, if it doesn't work under 2.0 people won't buy it. developers will quickly learn that they should follow the rules. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
markv@kuhub.cc.ukans.edu (05/16/91)
> So should we expect to recompile our code every 5 years?! Because CBM > will remove some function we used and dont support anymore! Whoa! This all was started in particular by a certain OldOpenLibrary() call. This function was obsolete with 1.2!!!! (How many here remember 1.1? I even remember 1.0, sheese). So OldOpenLibrary() has been obsolete for about 3 years already. And other OSs make certain things eventually obsolete also. How many programs that were written for DOS 1.1 work these days (try not many). OSs evolve, and sometimes you need to leave things behind to move to the future. > I cant beleive it even if it come from CBM :-) > And the size 'excuse' is pretty funny when you think the major part of > what is in ROM is written in C. Well, most of the ROM is actually in assembler because of size. And the specific example is admittidly a bit rediculous. A more realistic one is the support for BCPL in 2.0. The new dos library has no BCPL, but 2.0 still supports it. That support *is* taking a *lot* of code. > And What 1.x calls CBM said not to use anymore because it might > desapear? Well, if you read the Autodocs there are functions that say OBSOLETE, and tell you the new one to use instead. This is pretty obvious to me. For 2.0, you'd should get rid of BCPLisms, and use the new calls for one. Also there are certain internal functions that Commodore has said dont use ever that may go away (AlohaWorkbench() and Intuition() come to mind). > Dont you think they gave alternate function? Some people might NOT > want to do 2.0 softare compatible only... Well, if your using the OS, then it isn't hard to be 2.0 "aware" but still work under 1.3. Some of the things that are hacks under 1.3, but supported under 2.0 are probably better off just done in 2.0, esp. from the programmers point of view (hardware scrolling of Intuition screens for instance). My net thought is, Follow the rules and things will work for a long time. Granted, (esp. pre 2.0) many things weren't possible with the rules, but they are still a hack, so by doing such things, your accepting the possibility that youre on thin ice. Also, if you've ever worked on other micro OSs, you wouldn't complain so much. The Mac OS has already been mentioned, but even DOS is bad. The things you have to do to make TSRs *really* work, the epheremal "List of Lists", hidden fields in the PSP, the elusive DOS data segment pointer (which can be used to make DOS reentrant, suprise!), etc. We have it easy. > Stephan. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/17/91)
In article <1991May13.220559.11706@visix.com> brett@visix.com (Brett Bourbin) writes: >In article <dillon.7621@overload.Berkeley.CA.US>, dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > >|> Uh, actually, you don't want to use CLR either if you can help it >|> because CLR always *reads* the ea before writing a 0 to it. This >|> true all the way through 020's at least. > >Doesn't this also introduce problems with the custom chips, since you can >say something like "clear the COPPER 1 STROBE" with the CLR.W cop1xxx(AX) >command. This would read the register before writing the zero. I am not >sure about the COPPER STROBE, but I know some write-only registers get >very picky when you try to read them. > >|> Matthew Dillon dillon@Overload.Berkeley.CA.US >-- > __ > Brett Bourbin \ / /(_ /\/ 11440 Commerce Park Drive > ..!uunet!visix!brett \/ / __)/ /\ Reston, Virginia 22091 > brett@visix.com Software Inc (703) 758-2733 I've tested clr.w on the copper strobes and it works. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
jsmoller@jsmami.UUCP (Jesper Steen Moller) (05/17/91)
In article <MWM.91May15151039@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > > In article <1991May15.103610.12158@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > Yea, like CBM will KILL all early software written for the amiga do > win 8 bytes! (Hope people jok when they talk about CBM > replacing/removing a library function ) > > Nope, we're not joking. With 2.0, there are lots of replacements for > "old" library entries, and CBM is universally telling people not to > use the old version of the call. I don't think CBM would remove OldOpenLibrary, as programs written for pre-1.2 should continue to work without recompilation if properly designed. Also, as OldOpenLibrary is in the very middle of the exec.library vector table (6 bytes) and probable does: moveq.l #$00,D0 JMP _LVOOpenLibrary(A6) it would be plain silly to remove it - they could win only 6 bytes... > Now, go down the road to the next major OS release (3.0?). Judging > from past experience, that's 5+ years away. That means that the only > correctly written software that would be broken by deleting the old > entries (or better - at least at that point - replacing them with an > error return) is five or more years old. I think deleting or changing functions radically like above is rude and in conflict with the original design. I can tolerate something like GetScreenData() being "crippled" for 2.0 (I can see why, too...) but making correctly written software malfuntion (except because of new hardware, mabye) is more than I can take. I'd rather go back to the C= 64 then - things didn't change back then... > That kind of software is > either 1) run by someone who's not fallen for the "have to have the > latest and greatest" trap, and so probably won't upgrade their OS, or > 2) been orphaned for at least five years. The latter is part of life. Or 3) run by someone who written something really great but somehow deleted the source and forgot the hexadecimal values of the 680x0 instructions (I still what the 6510 opcode $A2 was used for...) > <mike Jesper -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmami!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/17/91)
sschaem@starnet.uucp (Stephan Schaem) writes: > > > So should we expect to recompile our code every 5 years?! Because CBM > will remove some function we used and dont support anymore! > I cant beleive it even if it come from CBM :-) > And the size 'excuse' is pretty funny when you think the major part of > what is in ROM is written in C. > > And What 1.x calls CBM said not to use anymore because it might > desapear? > Dont you think they gave alternate function? Some people might NOT > want to do 2.0 softare compatible only... > > > Stephan. no, OldOpenLibrary was a 1.0 call, in 1.1, or 1.2 it was replaced by OpenLibrary and everyone has been told since to use that and NOT OldOpenLibrary. I think this is a prime example of commodore not effectivly making it's point. I think it will take something as drastic as following up on all it's threats to convice people that there are good reasons why they should follow the rules. It's like a father threatening to spank a kid when the kid KNOWS his father has never laid a hand on him. This is the reason that Most Mac programmers follow the rules closely because apple has all too often pulled the carpet out from under them if they don't, course apple also changes their rules too, but that's another story. back to the point, OpenLibrary is NOT a 2.0 only call. it's perfectly acceptable in 1.2, and 1.3 and 2.0 which is the OS that 99.99999999% of all amiga users use. re-compiling your code every 5 years is called maintainance. you can't expect your programs to run forever, otherwise we're no better than MS-DOS machines. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
Lets hope not! Lets hope they will optimize the rom instead of removing oldfunction.Or go to 1 meg if really needed! And the original OpenLibrary was a mistake from CBM and should have never been without vesion... And removing it or replacing it would be another mistake. Come on how short could they be to remove a function that take them 6 bytes! (+6 for lib jump). Doesn't make ANY sens. What they could do (Without removing/repacing!) is to make function fail with corect FAIL return code. (That would not make OldOpenLibrary shorter!) And from what I heard they have extra code in 2.0 to support earlyer verion function, more easyer to beleive... Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
I dont remember saying clr MEM was faster... AndI will still use clr mem when I dont want to modify register. (Because its still faster). Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
If CBM start to say that they can remove old function its not what I think a 'good' move.What function will be next. I already said the OldOpenLibrary should have never existed, but now its there... I will beleive it when CBM start doing it. I never said exec or other are not in ASM, but I still beleive that most of the OS in from C. (Exec is the best part I have seen, and it would be good if the entire ROM was done this way.) I'm simply against removale of library function, for any reason. Something acceptable would be to leave the function but make then return FAIL code or 'do nothing'. Like making OldOpenLibrary alway return 'FALSE' (Bad example since there is no point doing it.). I have used the SGI graphics library (Very little, and very similare the the amiga :-) and from what I know all machine since the 4D series started there are all binary compatible... But might change from a MAJOR architecture desing change (Like for CBM). Stephan.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/18/91)
In article <jsmoller.5278@jsmami.UUCP> jsmoller@jsmami.UUCP (Jesper Steen Moller) writes: > Nope, we're not joking. With 2.0, there are lots of replacements for > "old" library entries, and CBM is universally telling people not to > use the old version of the call. I don't think CBM would remove OldOpenLibrary, as programs written for pre-1.2 should continue to work without recompilation if properly designed. Also, as OldOpenLibrary is in the very middle of the exec.library vector table (6 bytes) and probable does: moveq.l #$00,D0 JMP _LVOOpenLibrary(A6) it would be plain silly to remove it - they could win only 6 bytes... No, it's _not_ just six bytes. It's ~six bytes for _every_ backwards compatable function. There's also all the code spent on supporting various hacks. There's various things that support BCPL. Any piece of it may be small, and can be justified just like the above. Taken as a whole, it's _not_ small. Pulling any of it will break old code; pulling all but OldOpenLibrary will probably break nearly everything. Why leave in OldOpenLibrary for the small percentage that don't break because of some of the other things? I think deleting or changing functions radically like above is rude and in conflict with the original design. Rude? Yes - but it's not as rude as not doing OS updates because you can't break old programs. In conflict with the original design? Immaterial. There's a new design, and the people who control the code think it's better (I agree, but that's also immaterial). If you like the old design better than the new one, don't run the new version of the OS. That way, _nothing_ breaks. > That kind of software is > either 1) run by someone who's not fallen for the "have to have the > latest and greatest" trap, and so probably won't upgrade their OS, or > 2) been orphaned for at least five years. The latter is part of life. Or 3) run by someone who written something really great but somehow deleted the source and forgot the hexadecimal values of the 680x0 instructions (I still what the 6510 opcode $A2 was used for...) That's orphaned code. Orphaned code is code with nobody who's willing to fix bugs or make enhancements, and that's what you've just described. In article <1991May16.042906.4763@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: So should we expect to recompile our code every 5 years?! Because CBM will remove some function we used and dont support anymore! No, you don't have to recompile your code every 5 years. You can always opt not to upgrade to the new OS. Of course, for anything non-trivial, some time during that five years you should have changed the code to take advantage of the features of the new OS. Me, I recompile with new compiler releases (unless it's in assembler, of course), or when I upgrade processors (Hmm - I guess if you code in largely in assembler, that doesn't win anything without a rewrite anyway...). And the size 'excuse' is pretty funny when you think the major part of what is in ROM is written in C. Yeah - we've just seen it demonstrated that the obvious C code is less than 10% larger than hand-tweaked assembler code (check out the first few notes under this subject) that provides the same functionality, and _much_ smaller than untweaked-assembler. I guess CBM should spend all their time tweaking assembler to make it smaller rather than fixing bugs... BTW, one of my critical applications is an orphan. If it hadn't run under 2.0, I would have lost. If CBM breaks OldOpenLibrary, I may lose (given the code quality, I probably don't, but I should check that). And I'll still be plugging for OldOpenLibrary to go away. If OpenScreen and OpenWindow go away, I'll lose. I'll still be pushing for CBM to do that. I expect that all the people who've been crying for demand paging or resource tracking or a protected environment will also be doing so. Those broken eggs are the cost of the omelette they want. <mike -- I know the world is flat. Mike Meyer Don't try tell me that it's round. mwm@pa.dec.com I know the world stands still. decwrl!mwm Don't try to make it turn around.
bart@asgard.pub.uu.oz.au (John Butcher) (05/18/91)
In article <dillon.7675@overload.Berkeley.CA.US>, Matthew Dillon writes:
Matt> sub.l D0,D0 is not faster than moveq.l #0,D0 on a 68000. The two
Matt> instructions are both one word long.
Me> What you say is right, but the reasons behind it are worng.
( wrong even ;-)
Me> Instruction length != instruction timing :
Me> sub.l d0,d0 == 6 ( or is it 8 ?? )
Me> moveq.l #0,d0 == 4
Matt> Huh? I said that sub.l D0,D0 is not faster than moveq.l #0,D0 on a
Matt> 68000 even though they are the same size.
Matt>
Matt> I NEVER said that instruction length == instruction timing. In fact,
Matt> my original statement says the exact reverse.
Ah ha, now I know what you ware getting at, it's all crytal clear, what I
understood the original 2 lines to mean were something along the lines of
"Instruction 1 is not faster than Instruction 2 because they are both 1 word
long, and hence the same speed", which is not what you meant ! - I dont
agree that your original comment meant exactly the opposite of what I said it
did however - it was not clear what you were saying about timing except that
sub.l is slower than moveq.l
Anyway, it isnt really important, since we both agree that length != time,
and sub.l is slower than moveq.l
-----------------------------------------------------------------------------
John Butcher : bart@asgard.pub.uu.oz.au
..!munnari!eyrie.oz.au!asgard!bart
``Life! Don't talk to me about life.'' - Marvin the Paranoid Android sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
I dont see BPTR has mutch of a problem at ALL! (Well duplicate sructure take some place). Simply have 2 set of Dos routines, simply do the call and change APTR to BPTR... That will cost you a couple of byte ad backward compatability. And if you think that many software (Including part of the rom) are written in C, some LSR and LSL shouldn't be a problem. And if CBM dont support BPTR in dos structure and call, every single programe I use will BREAK! And I dont want that to happen. Same with Rom function, how many software do you think use OpenLibrary instead of OldOpenLibrayr... If all this is serious its a BIG mistake. Another thing about BPTR: I dont think BPTR are that mutch of a problem.Not a speed problem, and a gain if you think of C not a code size problem. Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/18/91)
I will check about that code size... From the C code I ported from the IRIS and them done in assembly they got 1000% smaller. and 400% faster. (Same algorithem in both version.) I was using lattice 4.0, but the C version used Printf... I will try with 5.1 and without printf. From what I saw of Lattice 5.1 I was impressed from the WB interface, but defenetly not from the generated code. Even from all that I will switch to C, not on the amiga but on a R3000 based machine. Stephan
riley@THEORY.TC.CORNELL.EDU (Daniel S. Riley) (05/19/91)
In article <MWM.91May17124038@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >BTW, one of my critical applications is an orphan. If it hadn't run >under 2.0, I would have lost. If CBM breaks OldOpenLibrary, I may lose >(given the code quality, I probably don't, but I should check that). >And I'll still be plugging for OldOpenLibrary to go away. If >OpenScreen and OpenWindow go away, I'll lose. I'll still be pushing >for CBM to do that. I expect that all the people who've been crying >for demand paging or resource tracking or a protected environment will >also be doing so. Those broken eggs are the cost of the omelette they >want. What should CBM do with the LVOs for deleted functions? I'd be in favor of CBM eventually deleting unused functions. I'd be opposed to CBM reusing those LVOs--reassigning LVOs would just lead to massive confusion--in which case deleted functions would continue to take up some space in the jump tables. The obvious advantages are that the deleted functions could all be pointed to a moveq #0,d0/move.l d0,a0/rts somewhere (or an alert routine) so deleted functions would fail instead of invoking some entirely different routine, and anyone who *really* wants to could SetFunction() the routines in question back into some sort of existence (for personal use only). The obvious disadvantages are that it would take up some small amount of space, and anyone who *really* wants to could SetFunction() the routines in question back into some sort of existence (yes, I regard this as an advantage *and* a disadvantage). Comments? -- -Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
sschaem@starnet.uucp (Stephan Schaem) (05/19/91)
This is not just a case of recompiling... The idea of having function deseapear is the problem. Because it doesn't involve recompiling but reprograming. An example would be with openwindow for example. In my libraries All my defined structed have (Like nodes) Type/ID, including structure version... That allow my friend to NEVER recompile his programes when ever I give him a new library version. Of course this is a very diferent environment, but those are the rules I beleive in. Just imagine (For the openwindow) that CBM removed it and put OpenWindowTagList instead! That's what I'm talking about... If This is a improvment and you say it should evolve, removing Openwindow is somthing logical? I cant really speak about that subject since I dont know mutch about those 2.0 function.(I know that taglist are an option, like library version...) I would prefere that CBM create a NEW OS based on the curent 2.0. Shouldn'y hurt more than removing all those function that CBM recomand bot to use anymore, like you say. Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/19/91)
Leaving the 'removed' function on a disk based library is good things. If some have to be removed... But what do you think CBM will do? I still dont think they will do something like that. Stephan.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/19/91)
In article <1991May18.172039.7477@batcomputer.tn.cornell.edu> riley@THEORY.TC.CORNELL.EDU (Daniel S. Riley) writes: What should CBM do with the LVOs for deleted functions? Three phases: 1) Version X.0: Announce "xyzzy is obsolete". It still works, but you shouldn't use it. 2) Version (X+1).0: The Xyzzy enry now behaves as per: The obvious advantages are that the deleted functions could all be pointed to a moveq #0,d0/move.l d0,a0/rts somewhere (or an alert routine) so deleted functions would fail instead of invoking some entirely different routine, and anyone who *really* wants to could SetFunction() the routines in question back into some sort of existence (for personal use only). Actually, you probably need two routines; there are some oddball library entries that fail with -1. But that's the right idea. 3) Version (x+2).0: the LVO for xyzzy is recycled. Remember that version numbers are partially driven by marketing. These are things at 5+ year intervals. The amiga hasn't been around long enough for anything to have reached stage 3. OldOpenLIbrary is pretty much the only thing that's reached stage 2. I can see holding off on it until the stuff from the 1.x->2.0 conversion reaches stage 2, though. In article <1991May18.172039.7477@batcomputer.tn.cornell.edu> riley@THEORY.TC.CORNELL.EDU (Daniel S. Riley) writes: This is not just a case of recompiling... The idea of having function deseapear is the problem. Just imagine (For the openwindow) that CBM removed it and put OpenWindowTagList instead! That's what I'm talking about... Gee, that's just a case of recompiling, assuming it's done right. All CBM needs to do is add the line #define OpenWindow(x) OpenWindowTagList(x, NULL) to intution.h, and I can recompile my code without changing a line. So can anyone else who's followd the rules. If This is a improvment and you say it should evolve, removing Openwindow is somthing logical? Yup; some time during the next century. I would prefere that CBM create a NEW OS based on the curent 2.0. You haven't been paying attention. They did. It's called AmigaDOS 2.0. CBM also went to great lengths to make it backwards compatable with the old OS. Shouldn'y hurt more than removing all those function that CBM recomand bot to use anymore, like you say. No, it'll hurt a lot more. People are complaining about not being able to get 2.0 now. Imagine how they'd feel if 2.0 were a "new" OS that wasn't largely backwards compatable - that could well kill the Amiga. Why should doing it now, rather than five years from now with "NewADOS" of having an AmigaDOS 2.0 change that? In my libraries All my defined structed have (Like nodes) Type/ID, including structure version... That allow my friend to NEVER recompile his programes when ever I give him a new library version. Admirable goal. How long have you been supporting those libraries? And how long do you plan on supporting them? Since you got upset about having to recompile your code every five years, I assume you've been doing it for at least 10 years. That's starting to get almost noticable. Get back to me in another 10, and let me know if the same library is still in use, and whether you've changed it since. Also be interested in knowing wether it's running on 10-year-old hardware or not. <mike -- He was your reason for living Mike Meyer So you once said mwm@pa.dec.com Now your reason for living decwrl!mwm Has left you half dead
jesup@cbmvax.commodore.com (Randell Jesup) (05/20/91)
In article <4852@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >not to mention that there is SOME RAM overhead for opening a library anyways, >if you happen to have all memory allocated and then try to open a library.. it >won't succeed, that is a MUCH more common occurance. I think commodore should >DEFINATELY squelch this rumor that rom calls will always succeed. Some libraries, including ROM libraries I believe, do allocations on open. Some even allocate entire new lib/device bases on open. If you fail to close them, you may lose valuable resources (and they can fail). Even if they don't currently allocate ram, they may tomorrow. Follow the rules and you won't get burned. Work around the rules or try to find loopholes in the rules and you will. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (05/20/91)
kes.2644@amiga0.SF-Bay.ORG> Sender: Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Followup-To: Distribution: Organization: Commodore, West Chester, PA Keywords: In article <mykes.2644@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >In article <1991May13.220559.11706@visix.com> brett@visix.com (Brett Bourbin) writes: >>Doesn't this also introduce problems with the custom chips, since you can >>say something like "clear the COPPER 1 STROBE" with the CLR.W cop1xxx(AX) >>command. This would read the register before writing the zero. I am not >>sure about the COPPER STROBE, but I know some write-only registers get >>very picky when you try to read them. >I've tested clr.w on the copper strobes and it works. Empirical programming, Mike! Just because it works on your machine doesn't mean it'll work on the machine someone down the street just bought, let alone on the next generation of graphics chips. When you read a write- only register on a chip without a R/W line, it will latch a random value from the bus. This value may change from machine to machine, model to model, or chip-rev to chip-rev. Stick to the guidelines - don't use clr on write-only registers. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
sschaem@starnet.uucp (Stephan Schaem) (05/20/91)
WRONG Solution! CBM will save 8 bytes of ROM space will every call you make will be 4 byte bigger.8 Byte once, 4 byte or more for each programe on your disk (and rom?)... What sound more logical? Keeping OpenWindow and save space EVERYWHERE or remove it and recompile every single programe written and making the ROM bigger and using more disk space (Small numbers of course). And speaking of my library, I dont have millions of people using it everyday... And I took the oportunity to trash all the path code for old structure version (The library is used for structure/object oriented programing.). And It might run on a Silicon Graphics before the end of the year, so it might surlly use a diferent hardware configuration. (And from that be able to port GUI programe from both system...) Anyway, this is just an idea that I dont like (Removing absolete library function).I really think it could be avoided with very little code (Like OldOpenLibrary, and the OpenWindow example). The 5 year I mentioned is an exageration:-) The best example I thinking of is CED. Stephan.
jayward@eecs.cs.pdx.edu (Jay Ward) (05/21/91)
riley@THEORY.TC.CORNELL.EDU (Daniel S. Riley) writes: >What should CBM do with the LVOs for deleted functions? >I'd be in favor of CBM eventually deleting unused functions. I'd be >opposed to CBM reusing those LVOs--reassigning LVOs would just lead to >massive confusion--in which case deleted functions would continue to >take up some space in the jump tables. We're missing the point here totally... I've heard it preached up and down here on the net: 'Follow the rules! If you follow the rules you won't get burned'. So now what do we want to do? Trash all of the routines that we shouldn't be using today, but were perfectly legal in yesteryear. Is this the ultimate form of corporate hippocracy, or am I missing something? Someone please enlighten me. >-Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) >-Wilson Lab, Cornell University ---------------------------------------------------------------------------- Jay Ward --> jayward@eecs.cs.pdx.edu | Down : Seattle, Utah Live from the Rip City! | To Go: L.A., Eastern Conf. Champs. ----------------------------------------------------------------------------
kilian@cinnet.com (Kilian Jacob) (05/21/91)
>In article <1991May11.211913.21863@cinnet.com> you write: >>Well, theoratically, you're right. In reality, though, there is no reason to >>change (or interchange, to be excact) library vector offsets. The only >>reason I see why OldOpenLibrary() one day might not have the offset -408 is >>that Commdore dicided to get rid of it. In that case neither program (the >>one that uses the .i files nor the one that doesn't) would work by simply >>reassemblying it. In both cases you would have to insert a sub.l d0,d0 >>before the function call and use OpenLibrary() instead. > >What you say may never happen has already happened the OpenLibrary >vector used to point where OldOpenLibrary now points. (Surprising, Come on! :-) What I ment was changing the vector offset of a function and using its original offset for a different function (or not using it at all). In the case of OpenLibrary, the offset -408 performs the same action in all OS version. (It doesn't matter whether it's called OpenLibrary (v1.0) or OldOpenLibrary (v1.1+).) >but this is where the "Old" comes from!) But it was documented as >doing what the new OpenLibrary does. The new one was added rather >than changing the existing vector so that existing binaries wouldn't >fail. > >So the source for a program compiled into an old binary (where >OpenLibrary pointed to OldOpenLibrary) would fail when OldOpenLibrary >is deleted but would work if recompiled to use the new OpenLibrary >vector. > Well, that depends on the program. The "hello word" program for example would work in neither fashion (includes vs hard coded LVO's), because it doesn't specify any version number.: original short hello world source code: OpenLibrary equ -408 .. move.l $4,a6 move.l #DOSBASE(pc),a1 jsr OpenLibrary(a6) ... DOSBASE dc.b "dos.library",0 This works under any OS version as long as the offset -408 points to the OldOpenLibrary (version 1.0 OpenLibrary) function. short hello world using include files: include "dos/dos.i" ... move.l $4,a6 move.l #DOSBASE(pc),a1 jsr _LVOOpenLibrary(a6) This actually only works properly using the v1.0 include files, since the new (v1.1+) OpenLibrary (-552) requires a version number in d0. (You would have to do a moveq.l #0,d0 [or sub.l d0,d0] before you call OpenLibrary -- re-read my original post. That's what I already wrote.) My point is that you can't substitute OpenLibrary (-552) for OldOpenLibrary (-408) 100%, as you suggest. Thus, compatiblity is no reason to use include files instead of hard coding LVO's. If you could use the new version without modifying your source code (here: having to pass a second parameter), it (new OpenLibrary) would still have the old offset (as it is true for newer versions of other OS functions). In such case, obviously, whether to use includes or hard code LVO's doesn't matter either. >Also ROM space may not be the only reason for removing the >OldOpenLibrary call. > Well, I also mentioned the size limitations of the Library jump table ;-) -- what other reason are there? Later, -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
kilian@cinnet.com (Kilian Jacob) (05/21/91)
From article <1991May17.170132.23862@starnet.uucp>, by sschaem@starnet.uucp (Stephan Schaem): > > Lets hope not! Lets hope they will optimize the rom instead of removing > oldfunction.Or go to 1 meg if really needed! > And the original OpenLibrary was a mistake from CBM and should have > never been without vesion... And removing it or replacing it would be > another mistake. > Come on how short could they be to remove a function that take them 6 > bytes! (+6 for lib jump). > Doesn't make ANY sens. > What they could do (Without removing/repacing!) is to make function > fail with corect FAIL return code. (That would not make OldOpenLibrary > shorter!) > And from what I heard they have extra code in 2.0 to support earlyer > verion function, more easyer to beleive... > > Stephan. -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
kilian@cinnet.com (Kilian Jacob) (05/21/91)
Subject: Re: Short Hello World Newsgroups: comp.sys.amiga.programmer,alt.sources.amiga References: <1991May17.170132.23862@starnet.uucp> From article <1991May17.170132.23862@starnet.uucp>, by sschaem@starnet.uucp (Stephan Schaem): > > Lets hope not! Lets hope they will optimize the rom instead of removing > oldfunction.Or go to 1 meg if really needed! > And the original OpenLibrary was a mistake from CBM and should have > never been without vesion... And removing it or replacing it would be > another mistake. > Come on how short could they be to remove a function that take them 6 > bytes! (+6 for lib jump). > Doesn't make ANY sens. You're absolutely right. If they get rid of OldOpenLibrary they probably save 6 bytes of ROM code and 6 bytes of used RAM. And that's only if they use the offset -408 for a new exec function!! I bet the ROM code of the exec.library looks about like this ... Functions: dc.l Open dc.l Close dc.l Expunge dc.l ExtFunc ... dc.l OldOpenLibrary ; 4 bytes: address of the function in ROM ... dc.l OpenLibrary ... ... OldOpenLibrary: moveq.l #0,d0 ; any version number -- this takes up two bytes OpenLibrary: ... ; just continue using the new OpenLibrary code rts ... Bis dann, -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/21/91)
In article <1991May20.143242.10424@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes:
Sorry, you're wrong. Code written for 2.0 should be using
OpenWindowTagList (or one of the stubs pointing to it), not
OpenWindow. The #define may make the code a few bytes bigger, but it
also makes it follow CBMs recommendations. Not following those
recommendations is what leads to code that breaks on the next release.
The #define is really a compatability hack, and I'd cram it into
something called "compat.h".
So, will your friend run his amiga binaries on the Iris? If not, then
what's the point of preserving the library entries between the two?
After all, you've got to recompile anyway.
<mike
--
The sun is shining slowly. Mike Meyer
The birds are flying so low. mwm@pa.dec.com
Honey, you're my one and only. decwrl!mwm
So pay me what you owe me.peter@cbmvax.commodore.com (Peter Cherna) (05/22/91)
In article <MWM.91May21105143@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <1991May20.143242.10424@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > >Sorry, you're wrong. Code written for 2.0 should be using >OpenWindowTagList (or one of the stubs pointing to it), not >OpenWindow. If you are losing any sleep over whether continuing to call OpenWindow() is wrong now that OpenWindowTagList() exists, you're wasting your time. I would tend to believe that (old) OpenWindow() will continue to exist for a long time to come. Just look, on balance, at what it costs to keep (old) OpenWindow() [or OldOpenLibrary()] for that matter: - code space (these are both tiny routines that call the modern replacements) - code complexity (few ROM routines are this simple) - possibility that an application depends on its existence (guaranteed for OpenWindow(), pretty high for OldOpenLibrary()) Benefit to Commodore for removing OpenWindow() or OldOpenLibrary(): NEARLY NONE Cost to Commodore for removing OpenWindow() or OldOpenLibrary(): PRETTY SIGNIFICANT (wantonly breaking existing apps) It doesn't take much to realize that when stuff is made obsolete, it frequently means the new one is better, not that the old one is going away, unless there's some compelling reason. > <mike Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/22/91)
In article <1991May20.143242.10424@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > WRONG Solution! CBM will save 8 bytes of ROM space will every call > you make will be 4 byte bigger.8 Byte once, 4 byte or more for each > programe on your disk (and rom?)... What sound more logical? > Keeping OpenWindow and save space EVERYWHERE or remove it and recompile > every single programe written and making the ROM bigger and using more > disk space (Small numbers of course). Look everyone, this discussion on OldOpenLibrary() and what Commodore may and may not do is great, but you are all building on rumor. NOBODY at C= has *EVER* said that old LVO's will go away. So nobody get huffy. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dvljrt@cs.umu.se (Joakim Rosqvist) (05/22/91)
In article <1991May21.030058.9972@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: > >Subject: Re: Short Hello World >Newsgroups: comp.sys.amiga.programmer,alt.sources.amiga >References: <1991May17.170132.23862@starnet.uucp> > > >OldOpenLibrary: > moveq.l #0,d0 ; any version number -- this takes up two bytes >OpenLibrary: > ... ; just continue using the new OpenLibrary code > rts > >-- /<ilian Unfortunately, they are not as smart as you. They use: OldOpenLibrary: moveq.l #0,d0 jsr OpenLibrary(a6) rts 6 bytes more than necessary! /$DR.HEX$ -------------------------------------------- Email to: dvljrt@cs.umu.se 2 Windows on the screen? Oh no, not me. I just Logout & Go.
m0154@tnc.UUCP (GUY GARNETT) (05/22/91)
>you can't expect your programs to run forever, otherwise we're no >better than MS-DOS machines. I should probably point out that under v1.xx of Ms-DOS, all disk access was done through "FCB's"; ie: CP/M style File Control Blocks, In general, programming FCB's was barely easier than doing direct BIOS level disk I/O (in other words, a real pain). When MicroSoft released v2.00, the mentioned that programmers should no longer use the FCB based I/O routines, but should use the file-handle oriented routines (which treat a file as a stream of bytes, just like UNIX and AmigaDOS). While I believe that FCB calls are still legal under Ms-DOS, many of the more modern features of that operating system are not available to FCB-based programs (features like subdirectories, for example). Operating systems grow and change; old methods become obsolete as new ways of doing things are developed. An operating system which does not grow and change this way becomes stagnant and then dies. Programs also have to grow and change, or they too will die. Wildstar
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/22/91)
sschaem@starnet.uucp (Stephan Schaem) writes: > > Leaving the 'removed' function on a disk based library is good things. > If some have to be removed... > But what do you think CBM will do? I still dont think they will do > something like that. > > > Stephan. The point isn't weather they will or won't. the point is that the old functions are doing things that commodore doesn't want people doing any more. commodore has flagged them as obsolete and has told EVERYONE not to use them anymore. leaving the old functions in there, will just tell people it's ok to use them. it would be trivial to point all the old functions to a common error return id, and suddenly none of the old code (or new code that people chose to ignore commodore, "they wouldn't do that") works anymore. take your chances, but don't whine when it doesn't work anymore. you've been warned people. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/22/91)
jayward@eecs.cs.pdx.edu (Jay Ward) writes: >riley@THEORY.TC.CORNELL.EDU (Daniel S. Riley) writes: > >>What should CBM do with the LVOs for deleted functions? > >>I'd be in favor of CBM eventually deleting unused functions. I'd be >>opposed to CBM reusing those LVOs--reassigning LVOs would just lead to >>massive confusion--in which case deleted functions would continue to >>take up some space in the jump tables. > >We're missing the point here totally... I've heard it preached up and down >here on the net: 'Follow the rules! If you follow the rules you won't get >burned'. So now what do we want to do? Trash all of the routines that we >shouldn't be using today, but were perfectly legal in yesteryear. Is this >the ultimate form of corporate hippocracy, or am I missing something? >Someone please enlighten me. It's called evolution. you may see it as hipocracy, but the point is not that software won't just suddenly break. if you follow the rules, everything is GUARANTEED to work for at LEAST one OS upgrade. one OS upgrade is all you should need to fix whatever has become obsolete. following the rules is not so that your program will work until the end of time, but it does mean that it won't break on the next release of the os. > >>-Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) >>-Wilson Lab, Cornell University .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs) (05/22/91)
>6 bytes more than necessary!
I wonder how many hundreds of kilobytes have passed through
the net arguing about six bytes. Heck, I was seldom so concerned
even when I was programming 16K boxes!
Lighten up, folks, and heed this warning: MS-DOS.
That's what you wind up with when you become obsessed with
backward compatibility. The 80x86 family is so horrible mostly
because Intel wanted an easy conversion from the 8080. Hence its
segment registers and 64K (let alone 640K) limits.
MS-DOS itself, being no more than a glorified CP/M, has
inherited its own share of warts (and I've discovered a lot of
them the hard way).
It never ceases to amaze me that millions of people spend so
much time kludging their way around such a brain-damaged system.
What amazes me even more, though, is that they discuss such things
with a straight face, while denouncing other things that consume
a fraction of the time they spend on this stuff.
I'd much rather have a couple of sloppily-written pieces of
software break five years from now -- and that only if the authors
don't clean up their act in the meantime -- than to have to carry
along a lot of excess baggage from the past. Come on, guys, let
the Commodore folks continue to do what they're doing. I'd rather
they did it their way then have another IBM/Intel/Microsoft fiasco.
Charlie_Gibbs@mindlink.bc.ca
Intel put the "backward" in "backward compatibility."mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/22/91)
In article <21779@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
If you are losing any sleep over whether continuing to call OpenWindow()
is wrong now that OpenWindowTagList() exists, you're wasting your time.
I would tend to believe that (old) OpenWindow() will continue to exist for
a long time to come.
How long is "a long time to come"? Five years? Ten years? Until
development on the Amiga stops (which could well be shorter than the
previous two)? And why have CBM employees said that those writing 2.0
code shouldn't be shouldn't be using OpenWindow()?
It doesn't take much to realize that when stuff is made obsolete,
it frequently means the new one is better, not that the old one
is going away, unless there's some compelling reason.
On the other hand, realizing what happens to systems that retain
compatability for everything that they ever supported takes looking at
one. I don't really recommend doing that; it's not a pretty sight.
Even trying to stay source-level backwards compatable while adding
modern features leads to odd things over the course of a decade.
Planning for the best implies assuming that some of the backwards
compatability hacks in 2.0 will vanish in the future. Once you assume
any of them will vanish, you might as well assume all of them will
vanish, and code accordingly.
Of course, it may be that you'll have an AmigaDOS with 20 years of
backwards compatability built into it. I won't - I'll have moved on to
a modern OS (one that's less than 15 years old) years before that.
<mike
--
Il brilgue: les toves lubricilleux Mike Meyer
Se gyrent en vrillant dans le guave, mwm@pa.dec.com
Enmimes sont les gougebosqueux, decwrl!mwm
Et le momerade horsgrave.peter@cbmvax.commodore.com (Peter Cherna) (05/23/91)
In article <1991May22.132222.29285@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >Unfortunately, they are not as smart as you. They use: > >OldOpenLibrary: > moveq.l #0,d0 > jsr OpenLibrary(a6) > rts > >6 bytes more than necessary! You think so? What happens if someone SetFunction()s OpenLibrary()? The way that "saves" 6 bytes means that OldOpenLibrary() doesn't go through the SetFunction(). The "wasteful" way works perfectly, and is REQUIRED for proper system operation. I'd be careful who you call smart or not smart. Smart isn't knowing how to save six bytes. Smart is knowing WHEN. >Email to: dvljrt@cs.umu.se Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
darren@cbmvax.commodore.com (Darren Greenwald) (05/23/91)
In article <1991May22.132222.29285@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >In article <1991May21.030058.9972@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: >> >>Subject: Re: Short Hello World >> >>OldOpenLibrary: >> moveq.l #0,d0 ; any version number -- this takes up two bytes >>OpenLibrary: >> ... ; just continue using the new OpenLibrary code >> rts >> >>-- /<ilian > >Unfortunately, they are not as smart as you. They use: > >OldOpenLibrary: > moveq.l #0,d0 > jsr OpenLibrary(a6) > rts > >6 bytes more than necessary! > > >/$DR.HEX$ > What about ramlib which SetFunctions the OpenLibrary() vector so that libraries can be opened off of disk (after dos is up, and running)? It would require far more code to SetFunction both vectors than it does to have OldOpenLibrary() jump through the OpenLibrary() vector.
d88-skl@dront.nada.kth.se (Stellan Klebom) (05/23/91)
In article <1991May22.132222.29285@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >Unfortunately, they are not as smart as you. They use: > >OldOpenLibrary: > moveq.l #0,d0 > jsr OpenLibrary(a6) > rts > >6 bytes more than necessary! > > >/$DR.HEX$ Fortunatly they are smarter than you! ;) If it was done in any other way, then the SetFuction() ability would be lost... Stellan ------------------------------------------------------------------------------- Stellan Klebom E-Mail: d88-skl@nada.kth.se, meLazy@lysator.liu.se
robart@agora.rain.com (Robert Barton) (05/23/91)
> Unfortunately, they are not as smart as you. They use: > OldOpenLibrary: > moveq.l #0,d0 > jsr OpenLibrary(a6) > rts > 6 bytes more than necessary! Actually, it looks like they are smarter than both of you. By using the official function call method (jsr to an offset from a6) they are able to handle the possibility that someone may have done a SetFunction() on the OpenLibrary routine. Having the OldOpenLibrary code just fall through to the ROM OpenLibrary code wouldn't allow this.
peter@cbmvax.commodore.com (Peter Cherna) (05/23/91)
ommodore <MWM.91May22111829@raven.pa.dec.com> Sender: Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Followup-To: Distribution: Organization: Commodore-Amiga, Inc. West Chester, PA. Keywords: In article <MWM.91May22111829@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >How long is "a long time to come"? Five years? Ten years? Until >development on the Amiga stops (which could well be shorter than the >previous two)? And why have CBM employees said that those writing 2.0 >code shouldn't be shouldn't be using OpenWindow()? If you're going to write 2.0-only code, you'll almost certainly want to take advantage of what OpenWindowTags() has to offer. But I'd be surprised if anyone at CBM has recommended against using OpenWindow(). But, there are a lot of people working at CBM, and their words are not policed, but their words are not policy either. I'm not in a position to state policy, but I can tell you that I'd be surprised if OpenWindow() stopped working between now and the next significant upgrade of any major product. >On the other hand, realizing what happens to systems that retain >compatability for everything that they ever supported takes looking at >one. I don't really recommend doing that; it's not a pretty sight. >Even trying to stay source-level backwards compatable while adding >modern features leads to odd things over the course of a decade. You seem to be implying that maintaining compatibility is universally damaging to the integrity of the system. Whenever we consider having to migrate people over to a new method, some thought is given to how expensive it is to support the old method. Plenty of compatibility measures (even some that cover blatant application bugs) do not in any way compromise the integrity, maintainability, or any other aspect of the future of the system. A well designed system such as the Amiga is more resilient in that regard than older computers where things like ROM-jumping was the norm. >Planning for the best implies assuming that some of the backwards >compatability hacks in 2.0 will vanish in the future. Once you assume >any of them will vanish, you might as well assume all of them will >vanish, and code accordingly. Sure, some of the hacks may vanish. However, a good example of a hack that won't need to vanish is one Intuition routine (I forget which) that explicitly preserves A1. Why does it preserve A1? Because it turned out that under 1.3, A1 was unmodified, and some application assumed that. Well, that's a pretty serious application bug. What does it cost the OS to preserve A1? Absolutely nothing (the code even came out to be the same size). I wouldn't bet my life that that kludge will remain in, and I expect the affected developer to correct the mistake for his next release. But I wouldn't be sweating bullets if I owned and used that application. There are hacks in there which are considerably uglier, and have impact on system performance, and those indeed risk vanishing over time. However, support for OpenWindow() in 2.0 is not a hack. OpenWindow() is a well-defined entry point and has been since time immemorial. We certainly have a greater obligation to support defined features than undefined side-effects. And when you consider the implementation of OpenWindow(), it looks something like this: struct Window *OpenWindow( struct NewWindow *nw ) { struct TagItem *tlist = NULL; if ( nw->Flags & NW_EXTENDED ) { tlist = ( ( struct ExtNewWindow * ) nw )->Extension ); } return( OpenWindowTagList( nw, tlist ) ); } Absolutely nothing in there compromises the future of the OS, and the OS will not be left behind in the dust because of things like this. And it's still a viable thing to write code that works under both 1.3 and 2.0. Thus OpenWindow() is still very much a current function. For OldOpenLibrary(), the case is different. Nobody NEEDS to use OldOpenLibrary(), since nobody should still be running AmigaDOS 1.0. So anybody that thinks they really _want_ to use OldOpenLibrary() is just plain silly. But worrying about whether it might vanish any time soon is far sillier. >Of course, it may be that you'll have an AmigaDOS with 20 years of >backwards compatability built into it. I won't - I'll have moved on to >a modern OS (one that's less than 15 years old) years before that. Please trust us to chart a successful future for AmigaDOS. We do have half a clue as to what can stay and what needs to go to keep AmigaDOS up-to-date, fun and efficient to use and program. > <mike Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."
sschaem@starnet.uucp (Stephan Schaem) (05/23/91)
I think I said that I have removed all the 'support' structure code because the library just split and is changing: making it a new librarys... I wont run 680x0 binary file on a MIPS RISCS, but is interested in doing a 68000->R3000 'converter'.(I still want to programe with a macro assembler with motorola instruction set instead of C :-) Only my low level library functions are doing hardware call, and use only exec (Transparent to the software).And after the library is ported and the 68000->R3000 is done (No promesse:-) I should have ZERO problem to port code I write from both machine fully ussing a GUI... Also , for me, not using the GFX library dont let me stuck with the curent 'limitation'. I could write anther set of the GFX function for a 24 bit device, and actually open screens on any video device supported by the library. (CBM could do the same, but will they do it....) Stephan.
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (05/23/91)
In article <21825@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: I'm not in a position to state policy, but I can tell you that I'd be surprised if OpenWindow() stopped working between now and the next significant upgrade of any major product. So would I. I was talking about OpenWindow (and the like) possibly going away in > 5 years time. At this point, unless you're doing 2.0-only software, I'd expect people to use OpenWindow and the appropriate flag bits so they can get tags. However, I also expect that sometime between now and the next major release from CBM this will change, as most software will become "2.0-only". >On the other hand, realizing what happens to systems that retain >compatability for everything that they ever supported takes looking at >one. I don't really recommend doing that; it's not a pretty sight. >Even trying to stay source-level backwards compatable while adding >modern features leads to odd things over the course of a decade. You seem to be implying that maintaining compatibility is universally damaging to the integrity of the system. I don't know about universally. I've just never seen anyone manage to both 1) migrate to a clean implementation of a new design and 2) maintain a high degree of backwards compatibility. AmigaDOS isn't old enough to have real problems yet. I'd rather not see it get into such problems. A well designed system such as the Amiga is more resilient in that regard than older computers where things like ROM-jumping was the norm. Fortunately, I've managed to avoid all those systems where ROM-jumping was anything more than a non-portable hack by people who didn't know better. Even if you protect the OS so people can't read/write it, 20 years of compatability code adds up. In the worst cases, it reverberates through the entire system. In the best, it adds weight to the OS for no other puprose than supporting old code. Given time and a fanatical devotion to backwards compatibility, you get to the point where you breaking binaries causes people to consider someone else's hardware, as the cost of buying new hardware is trivial compared to the cost of upgrading and/or recompiling old applications. Sure, some of the hacks may vanish. However, a good example of a hack that won't need to vanish is one Intuition routine (I forget which) that explicitly preserves A1. Why does it preserve A1? Because it turned out that under 1.3, A1 was unmodified, and some application assumed that. Well, that's a pretty serious application bug. What does it cost the OS to preserve A1? Absolutely nothing (the code even came out to be the same size). In the curernt implementation, it costs absolutely nothing (assuming the source is in assembler; if it's in C, there are probably contortion made to avoid stomping on A1). What happens when you want to replace all the data structures with a spiffy new thing that was published in '95, and discover you really want that extra register. However, support for OpenWindow() in 2.0 is not a hack. OpenWindow() is a well-defined entry point and has been since time immemorial. We certainly have a greater obligation to support defined features than undefined side-effects. I never said it was. I said that it was tagged as obsolete, may go away in the future, and that a CBM employee had recommended that it not be used. For OldOpenLibrary(), the case is different. Nobody NEEDS to use OldOpenLibrary(), since nobody should still be running AmigaDOS 1.0. So anybody that thinks they really _want_ to use OldOpenLibrary() is just plain silly. But worrying about whether it might vanish any time soon is far sillier. Um - why is OldOpenLibrary _now_ any different from OpenWindow in the 1995, or whenever the next major release after that (i.e. - the one with a major design revamp, the latets fad in UIs added, and lots of tools to make programmer easier) comes out? What started this was people saying "OldOpenLibrary will never go away, so it's safe to use." I disagree - CBM has never promised us that old library entries wouldn't go away. I happen to think that making them go away at the right time (see other articles in this thread) is good for the OS. The attitude expressed in that quote will prevent them from going away, by encouraging applications that use them. Please trust us to chart a successful future for AmigaDOS. We do have half a clue as to what can stay and what needs to go to keep AmigaDOS up-to-date, fun and efficient to use and program. As if I had a choice. I either do that, or choose another OS. <mike -- Look at my hopes, Mike Meyer Look at my dreams. mwm@pa.dec.com The currency we've spent, decwrl!mwm I love you. You pay my rent.
dvljrt@cs.umu.se (Joakim Rosqvist) (05/23/91)
>>Unfortunately, they are not as smart as you. They use: >> >>OldOpenLibrary: >> moveq.l #0,d0 >> jsr OpenLibrary(a6) >> rts >> >>6 bytes more than necessary! > >You think so? What happens if someone SetFunction()s OpenLibrary()? >The way that "saves" 6 bytes means that OldOpenLibrary() doesn't >go through the SetFunction(). The "wasteful" way works perfectly, >and is REQUIRED for proper system operation. > >I'd be careful who you call smart or not smart. Smart isn't knowing >how to save six bytes. Smart is knowing WHEN. > Alright, but they could at least use: OldOpenLibrary: moveq #0,d0 jmp OpenLibrary(a6) /$DR.HEX$ -------------------------------------------- Email to: dvljrt@cs.umu.se 2 Windows on the screen? Oh no, not me. I just Logout & Go.
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (05/24/91)
dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <1991May20.143242.10424@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: >> >> WRONG Solution! CBM will save 8 bytes of ROM space will every call >> you make will be 4 byte bigger.8 Byte once, 4 byte or more for each >> programe on your disk (and rom?)... What sound more logical? >> Keeping OpenWindow and save space EVERYWHERE or remove it and recompile >> every single programe written and making the ROM bigger and using more >> disk space (Small numbers of course). > > Look everyone, this discussion on OldOpenLibrary() and what Commodore > may and may not do is great, but you are all building on rumor. NOBODY > at C= has *EVER* said that old LVO's will go away. Right, but the original point being made was that when commodore says you shouldn't use a vector anymore, you shouldn't use it. despite weather you think commodore will or won't take it away, the point being that once they are made obsolete commodore can do anything it wants with them, and nobody who continues to use them has a right to bitch if something DOES happen. Like i said someday cbm probably will remove some things, for instance they've already removed a whole library. the clist.library from 1.0. all programs using that are now broken. the precedent is there, but people still choose to ignore it. "naw, commodore will continue to always support MY code." is the basic thoughts.. > > So nobody get huffy. > > -Matt > >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
jesup@cbmvax.commodore.com (Randell Jesup) (05/24/91)
In article <4969@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >The point isn't weather they will or won't. the point is that the old >functions are doing things that commodore doesn't want people doing any more. >commodore has flagged them as obsolete and has told EVERYONE not to use them >anymore. In some cases this is more true than others. An example of something that may NOT be supported "forever" is Forbid-locking the Dos device list. Forbid-locking of that list is and always has been broken. Under 2.0, the new functions do Forbid/Permits for compatibility, but they include the warning that that may well go away in some future major release. The time from now to then gives everyone a chance to get ready and upgrade. There's no guarantee that we'll remove the Forbid/Permit when we say it's no longer a supported practice, but don't count on that. >you've been warned people. Another idea we've had on the back burner for at least the last 3 years is the infamous "sysmung" version of the system for developers. This would be a version with all the cruelty toys like mungwall built in, extensive parameter error checking, and with all kludges removed and restrictions enforced. Who want's to bet their software will pass it? (actually, with enforcer, mungwall, and memoration probably a LOT more than would have a year ago). This would be way too slow and large for general use, however. If someone has time burning a hole in their pockets, it'd be fairly easy to do subsets of this for specific libraries/etc. -- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. "No matter where you go, there you are." - Buckaroo Banzai
sschaem@starnet.uucp (Stephan Schaem) (05/25/91)
The point is, what is supported now might not be supported in the future... So you follow CBM rules but you still get scewed up. Myself I dont beleive CBM will do it, its to stupid. CBM done something wrong with the original OpenLibrary, ok... And its going nowhere projecting what CBM will do with those kind of library function! Stephan.
sschaem@starnet.uucp (Stephan Schaem) (05/25/91)
Still, jsr follow by an rts is whatever you want to call it:-) Remind me of forth functions... Anyway if CBM dont want to support oldopen they could have done it some time ago, but imagine the mess! Stephan.,
riley@theory.TC.Cornell.EDU (Daniel S. Riley) (05/26/91)
In article <1991May23.055836.8362@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > I wont run 680x0 binary file on a MIPS RISCS, but is interested in > doing a 68000->R3000 'converter'.(I still want to programe with a macro > assembler with motorola instruction set instead of C :-) This should be reallll interesting... If you ever do write this 'converter', I recommend doing a few benchmarks. Unless you spend a lot of time working on optimization, I suspect you'll find that a decent C compiler/optimizer beats your converted 68000 code by a fair margin. The MIPS C compiler knows all about the cpu pipelining, instruction overlaps, register scoreboarding, branch delay slots, and on and on. Will your converter? -- -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
sschaem@starnet.uucp (Stephan Schaem) (05/27/91)
Why not? If I wanted to write in C I wouldn't even think of doing this... I know C is fast, I played with it on a IRIS 4D GT. I think also its something very interesting, I should get a machine around september and see from then. I dont know enought about the IP7 and above to think about multiprocessing, but I wouldn't miss instruction overlap and have plan in the design for concurent code execution. I think of the Motorola instruction/addressing has a language like any other... I hope I will be able the continue on that subject in a few month! Stephan.
m0154@tnc.UUCP (GUY GARNETT) (05/28/91)
>> doing a 68000 -> R3000 'convertor' ... > find that a decent C compiler/optimizer beats your converted 68000 > code by a fair margin. Of course, you could have the convertor emit C code so that the R3000 optimizer could work on it. Not a perfect solution, but it would work. Wildstar
kilian@cinnet.com (Kilian Jacob) (05/29/91)
From article <1991May22.221820.4348@nada.kth.se>, by d88-skl@dront.nada.kth.se (Stellan Klebom): > In article <1991May22.132222.29285@cs.umu.se> dvljrt@cs.umu.se (Joakim Rosqvist) writes: >>Unfortunately, they are not as smart as you. They use: >> >>OldOpenLibrary: >> moveq.l #0,d0 >> jsr OpenLibrary(a6) >> rts >> >>6 bytes more than necessary! >> >> >>/$DR.HEX$ > > Fortunatly they are smarter than you! ;) If it was done in any other way, then > the SetFuction() ability would be lost... > The questions is whether you want OpenLibary changed via SetFunction() affect OldOpenLibrary(), too. I think the answer is no. To me it makes more sense to change OldOpenLibrary itself if you want it to change. -- /<ilian -- Kilian Jacob - Cincinnati, Ohio - VOICE: (513)-489-1891 UUCP: kilian@cinnet.com or {uceng.uc.edu, ukma!spca6, uunet!sdrc}!cinnet!kilian
sschaem@starnet.uucp (Stephan Schaem) (05/29/91)
I'm not doing that for speed :-) A 33mhz R3000 can wait some extra cycle and the heavy stuff will be handle by the GFX engines... Their board work fine on a PC, driven by an intel! YEUK! To bad its not available for the amiga :-( All that I know is, its going to be fun to port my amiga GUI to the SGI series... And thats all my looking for, Fun :-) Stephan.
peter@cbmvax.commodore.com (Peter Cherna) (05/29/91)
In article <1991May29.040700.16292@cinnet.com> kilian@cinnet.com (Kilian Jacob) writes: >The questions is whether you want OpenLibary changed via SetFunction() >affect OldOpenLibrary(), too. I think the answer is no. To me it makes more >sense to change OldOpenLibrary itself if you want it to change. The answer is yes, OldOpenLibrary() needs to be affected by any SetFunction() of OpenLibrary(), because it's supposed to be equivalent to OpenLibrary(library,0L). In every normal Amiga system, OpenLibrary() is SetFunction()ed, because Exec doesn't know about loading disk-based libraries. A module called ramlib comes along after Dos is running and takes care of that extra job by SetFunction()ing OpenLibrary() and OpenDevice(). >-- /<ilian Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "If all you have is a hammer, everything looks like a nail."