|
It'will be very interesting. Here is to learn ... I have 2 questions: 1. How I can any object : for example *pgm, *file on system with MI instructions. 2. What the pointer PTRDO? If anyone have any examples - please show me ... Sincerely, Andrew. >From: "Steve Richter" <srichter@AutoCoder.com> >Reply-To: MI400@midrange.com >To: "mi mail list" <MI400@midrange.com> >Subject: 11 reasons for PowerPc assembler collaboration project >Date: Wed, 27 Jun 2001 12:37:45 -0400 > >Here are 11 reasons in favor of a web based collaborative project to write >an iSeries PowerPc compiler. > >The compiler would translate MI code into PowerPc assembler code. The >resulting code would somehow be placed in a collection of spaces that are >somehow made to look like a pgm object. The code in this pgm looking object >would be run just like any other pgm on the system. > >I dont know if this is technically possible and my interest in the idea is >simply to learn more about the system internals. > >Here are the reasons: > > >1. Excellent way to learn more about system internals. Even if a PowerPc >compiler is technically not possible, learning the reasons why would >increase the knowledge of the internals of the system. > >2. Chance to learn the power pc assembler language. The power pc is used on >other platforms and is a modern processor. So learning it has portable >value. > >3. Makes MI more interesting. Mi is interesting, but IBM has made it a >dead end. This limits its usefulness and the level of interest of its >adherents. Adding a Power Pc compiler to the mix would juice things up a >bit. > >4. Could implement the sls external module concept. The iseries has this >outstanding sls architecture that enables code in external modules to be >quickly resolved to and then jumped to as efficiently as an indirect jump >within a pgm. Its full capabilities are being wasted by the powers that be. > A power pc compiler could enable such a call to an external module. > >5. Other mi extension possiblities. User defined os400 objects, a machine >supported string data type, 8 byte integers, UniCode data type, non static >instruction pointers, parallel processing ... > >6. More feasible than it might seem. Many mi opcodes such as LOCKSL, >MATPTRL, RSLVSP could be implemented as jumps to module code that have been >pre compiled to run the mi opcode with arguments passed to the module. ( >exception handling might be tough though ) > >7. Low resistance to collaboration. The non commecial value of a power pc >compiler removes an inpediment to collaboration. That is, people would be >willing to share knowledge and code because they have nothing to lose. > >8. The ability to collaborate. The web provides the ability for dispersed >people to collaborate. The connectivity of the web is an ideal medium for a >voluntary, collaborative project. > >9. Web accessed shared system would be a good thing. The project would work >best if there was an as400 on the web that all participants could telnet >and ftp to. This would be good to have for sharing code of all kinds. > >10. Not a risc <g> to system security and integrity. The compiler would not >be for commercial use. It would not provide any ability to challenge the >system that an mi pgmr using sst already has. ( especially if the pgm >validation value cannot be cracked ). A charter could even state that >participants agree not to add any feature to the assembler that could be >used in such a way. > >11. Only talk is needed to start the project. The first phase of the >project is discussion based. How could a pgm object be constructed by an mi >pgm? How could the code ( data ) of a shell pgm be copied into the >constructed object? How could the pgm object header be set to enable the >constructed pgm to be runable? Who has an as400 they could put on the web? >... > > >Steve Richter > > > > > > > _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.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.