Opcodes of RM-COBOL 85
in [Cobol]
|
Prev: Decimal versus binary arithmetic was Re: J4 - presentation/discussionon "Future of the COBOL Standard"
Next: Thoughts on teaching OO concepts to COBOL programmers
From: Stephen Boyd on 11 Apr 2008 13:27 Felipe Jos� Angriman wrote: > I would like to rephrase myself. it seems i was not clear. > > I know that when you compile an RM-Cobol 85 source, you a get a file > (tipically in .COB Extension). > When you wish to execute the program (now in an intermediate > representation), > you use the RunCobol Program to interpret the .COB file > > I'm interested in knowing opcodes of the intermediate represetation, > not the opcodes for a particular machine, like the x86 As I said before, that information is proprietary to Liant and you are unlikely to find it documented anywhere.
From: Robert on 11 Apr 2008 19:51 On Fri, 11 Apr 2008 09:27:32 -0700 (PDT), Felipe Jos� Angriman <felipeangriman(a)gmail.com> wrote: >I would like to rephrase myself. it seems i was not clear. > >I know that when you compile an RM-Cobol 85 source, you a get a file >(tipically in .COB Extension). >When you wish to execute the program (now in an intermediate >representation), >you use the RunCobol Program to interpret the .COB file > >I'm interested in knowing opcodes of the intermediate represetation, >not the opcodes for a particular machine, like the x86 > >I again apologize Ryan-McFarland, formerly Digitek, has been producing p-code compilers for Fortran, PL/I and Cobol since the early '60s. Their p-code is sophisticated. Capable people have attempted to reverse engineer the p-code and, to the best of my knowledge, none were successful. In the unlikely event someone did figure it out, you won't find the information on the internet. If you want to be the first, I suggest getting a hard or soft ICE and tracing the interpreter. Don't be surprised to find obfuscation in the p-code, a stack oriented virtual machine and many calls to runtime 'library' code.
From: Felipe José Angriman on 11 Apr 2008 22:22 On Apr 11, 8:51 pm, Robert <n...(a)e.mail> wrote: > On Fri, 11 Apr 2008 09:27:32 -0700 (PDT), Felipe José Angriman <felipeangri...(a)gmail.com> > wrote: > > >I would like to rephrase myself. it seems i was not clear. > > >I know that when you compile an RM-Cobol 85 source, you a get a file > >(tipically in .COB Extension). > >When you wish to execute the program (now in an intermediate > >representation), > >you use the RunCobol Program to interpret the .COB file > > >I'm interested in knowing opcodes of the intermediate represetation, > >not the opcodes for a particular machine, like the x86 > > >I again apologize > > Ryan-McFarland, formerly Digitek, has been producing p-code compilers for Fortran, PL/I > and Cobol since the early '60s. Their p-code is sophisticated. Capable people have > attempted to reverse engineer the p-code and, to the best of my knowledge, none were > successful. In the unlikely event someone did figure it out, you won't find the > information on the internet. > > If you want to be the first, I suggest getting a hard or soft ICE and tracing the > interpreter. Don't be surprised to find obfuscation in the p-code, a stack oriented > virtual machine and many calls to runtime 'library' code. And it seems more unlikely that a newby like me would do such thing, ;-) Thank you all!
From: Michael Mattias on 12 Apr 2008 09:24 "Robert" <no(a)e.mail> wrote in message news:odtvv3578uv16965lp2bmlp4nl1g5lohiu(a)4ax.com... > On Fri, 11 Apr 2008 09:27:32 -0700 (PDT), Felipe Jos� Angriman > <felipeangriman(a)gmail.com> > wrote: >>I'm interested in knowing opcodes of the intermediate represetation, >>not the opcodes for a particular machine, like the x86 >> > If you want to be the first, I suggest getting a hard or soft ICE and > tracing the > interpreter. Don't be surprised to find obfuscation in the p-code, a stack > oriented > virtual machine and many calls to runtime 'library' code. Well, I see Mr. Angriman has succumbed to the dose of reality delivered by your post and decided to abandon this quest . But had that not disabused him of his plan, you could have pulled out the true "ace in the hole:" If he had any plans to build this interpreter for anything other than his personal use.. that is, might have distributed it to anyone with or without consideration (Ok, so 'consideration' is a legal word, real people would say 'compensation' or 'payment'), he faced both civil and criminal actions for copyright and/or patent infringement if he were not totally 'pure' vis-a-vis prior exposure to the RM-COBOL product. You might recall it was a key requirement for the first PC "clone" manufacturers that whomever did the reverse-engineering be totally and absolutely 'virgin' at the outset when replicating the chips and firmware.. any prior exposure 'tainted' the engineers (or should they be called 'reverse engineers?') by automatically making them subject to the terms of the license issued to the party who generated the specifications.. terms which prohibited reverse-engineering. It's of course now moot in this particular case, but I thought I'd throw that in just in case anyone else gets the urge. -- Michael C. Mattias Tal Systems Inc. Racine WI mmattias(a)talsystems.com
From: Robert on 12 Apr 2008 13:16
On Sat, 12 Apr 2008 08:24:32 -0500, "Michael Mattias" <mmattias(a)talsystems.com> wrote: >You might recall it was a key requirement for the first PC "clone" >manufacturers that whomever did the reverse-engineering be totally and >absolutely 'virgin' at the outset when replicating the chips and firmware.. >any prior exposure 'tainted' the engineers (or should they be called >'reverse engineers?') by automatically making them subject to the terms of >the license issued to the party who generated the specifications.. terms >which prohibited reverse-engineering. They used to run job ads like this: BIOS engineer. Must understand BIOS functions but never have laid eyes on a listing of IBM nor Phoenix code, and be able to document that fact. Extra consideration if you can prove you've never been in the same building with said listings, or have never touched a machine with a disassembler installed, including MS-DOS DEBUG. The ideal candidate will be from a country having no computers at all; his or her knowledge gained by divine inspiration. Should have a BSEE. A BSCS might be considered, provided the transcript shows absolutely no programming. Must have 5-10 years experience knowing nothing, and a track record showing increasing responsibility. |