|
Hi Will, on the issue of speed, you are not going to get the best results in MI vs an ILE/wcode language. This is because of the instruction piping/parellel processing of the power pc risc chip. MI code cannot be optimized like ILE code due to the way exceptions are handled in MI vs ILE. Think of what happens when instructions are executing in parellel and a divide by zero error occurs in one of the instructions. In MI, exception handler code is called and basically the program continues on its way depending on what the excp handling code does. But if instructions were running in parellel, that is instructions /0001 thru /0004 were running at the same time, when insn /0002 bombs the excp handler expects that instructions /0003 and /0004 have not been executed. But they might have been, so there are going to be problems in the program. In an ILE stack based pgm model this guarantee-ing of instruction exec sequence is not an issue when the exception is thrown thrown from one function call level back to its caller. All the results of the parellel instructions in the function that bombed are on the stack ( automatic storage variables of the function ) and throwing the exception back to the caller pops that stack and makes those results disappear. Now if MI variables could be coded as "mutable" or something to indicate to the optimizer that a variable does not need its value guaranteed at exception time ( the MI program implements its own stack ), then the optimizer could optimize those instructions that have such a variable as an lvalue ( left, update side of the expression ). If you are patching the code at the power pc/ risc level then that sounds pretty interesting just as an academic exercise. Some people on this list have done that, but I dont know much myself. You should look thru the MI mailing list archives. Something else to consider is to get the PowerPc assembler compiler that runs on the other power pc lines of computers that ibm sells. I dont know if such a thing is obtainable, but if it is it would be interesting to see if its code could be made to run on the iSeries. Good luck and post as much of what you find out as you can. Steve Richter -----Original Message----- From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On Behalf Of Will Richards Sent: Thursday, December 19, 2002 10:31 AM To: mi400@midrange.com Subject: [MI400] RISC instruction stream hash value Hi Kurt, Thanks for your reply. I'm writing a MI program which is suppose to replace an old and very slow C/400 that solves an ordinary differential equation. MI program works fine and A LOT MORE FASTER that C, :-). Looking for ways to improve speed and being familiar with RISC, I've patched the MI program and made it even faster. Now, the problem is how to deploy it to all our systems without being flagged as altered by the restore operation. My guess is, and please correct me if I'm wrong, if we recalculate the RISC instructions hash (Procedure table, offset X'009C' ) everything will be OK. Thanks again, Will -- WillDRichards@netscape.net __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ _______________________________________________ This is the MI Programming on the AS400 / iSeries (MI400) mailing list To post a message email: MI400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/mi400 or email: MI400-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/mi400.
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.