|
Hans wrote: > >It depends upon what you're trying to accomplish. Imagine if MULT always > >failed on overflow. How many programs are out there that used MULT 100.0001 > >or MULT 10000.01 to flip a date around? In one sense, any opcode is "unsafe" > >if you don't understand what it's doing. I remember waaaay back when > >learning RPG after knowing COBOL, and expecting MOVE to MOVEL with Padding! > > Ah, another FAQ! A long time ago, I did a comparison > comparing the performance of the old MULT 100.0001 trick. > I found that using MULT was about 100 to 150 times slower > than doing the date conversion using a couple of moves. > > I have yet to find a good example where using the decimal > truncation behavior of the old opcodes provides any > advantage. Since numeric overflow is almost always a > programming error, to me it makes little sense compiling > without TRUNCNBR(*NO). I'm sure that the old MULT 100.0001 trick is much slower, but I see it used all over the place, and yes, I use it myself. Advantage? Since you have the temerity to throw the word "any" in front of it, I feel compelled to come up with some <G>. Let's see -- being in some ways a lazy programmer, I could say it's an advantage to only have to type one line of source code as opposed to the several required to do the same thing with a couple of moves. And there are issues of program length - source length - where using one line of code when two would do might be an advantage. As far as speed, well, having a couple of MULT's in an interactive program to reformat dates for output is probably not going to be noticeable to anyone except someone who has a dedicated machine with nothing else running on it and a very accurate clock. Even in a batch program I doubt that you'd think the performance increase was worth the effort to go back through every program that uses MULT and modify it to use MOVE's simply based on performance. This isn't really relevant, but I remember a discussion once about whether MOVE 1 X was slower than Z-ADD 1 X, so some guy wrote a program to test it. He had a 10,000 iteration loop for each statement, and running it on a S/38, couldn't see any difference. So he upped it to 1,000,000 and managed to see zero seconds difference. I think he finally dumped the MI and found that they both used the same instruction. We all got a good chuckle out of that. Regards, Peter Dow Dow Software Services, Inc. 909 425-0194 voice/fax > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
