Two Click disassembly/reassembly
in [ASM]
|
Prev: Check out POASM
Next: Bad habits
From: Charles A. Crayne on 30 Jan 2006 21:43 On 30 Jan 2006 15:36:53 -0800 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: :You're about a decade ahead of me professionally, but the big :difference between us is that I've written several compilers and :assemblers and I've *researched* this problem enough to know that it :doesn't have a trivial (or even easy) solution. I'm doing my best not to play the size game with you, but since you still don't get it, let me tell another 'old war story'. In about 1973, IBM sold Bullocks Department Stores on replacing their aging NCR computer with a new, shiny, IBM 370/45, which was a 'bet your company' decision, not only because of the number of on-line and batch applications which had to be successfully converted in order to keep the stores open, but also because of the significant differences between the two hardware architectures, and their associated operating systems. Of course, all of the on-line systems were written in assembly language. I was assigned as the project manager of IBM's support team, and after many months of hard work by very talented people, we brought the project in "On time, and within budget". Now, if, after this, and many other hardware and software conversions for which I have been responsible, you still think that you can teach me anything about the process, then its time to 'put up or shut up', because doing a little 'research' just won't cut it. -- Chuck
From: randyhyde@earthlink.net on 2 Feb 2006 19:32 Charles A. Crayne wrote: > On 30 Jan 2006 15:36:53 -0800 > "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: > > :You're about a decade ahead of me professionally, but the big > :difference between us is that I've written several compilers and > :assemblers and I've *researched* this problem enough to know that it > :doesn't have a trivial (or even easy) solution. > > I'm doing my best not to play the size game with you, but since you still > don't get it, let me tell another 'old war story'. > > In about 1973, IBM sold Bullocks Department Stores on replacing their > aging NCR computer with a new, shiny, IBM 370/45, which was a 'bet your > company' decision, not only because of the number of on-line and batch > applications which had to be successfully converted in order to keep the > stores open, but also because of the significant differences between the > two hardware architectures, and their associated operating systems. Of > course, all of the on-line systems were written in assembly language. "This Problem" is specifically the conversion of x86 assembly code to other architectures. I, too, have been involved with lots of porting projects over the years. I have my share of "war stories". Now, I'd be willing to bet *big* money that your ports to the IBM were *not* automatic. I'm not saying that people cannot *manually* convert code, I'm not even saying that "helper" utilities (e.g., in PERL) can't be written to aid in the process. I'm not even saying that conversion from *some* machine architectures to others is infeasible. I'm saying that a source code conversion from x86 to one of the typical (RISC) architectures that run WinCE is not practical. Furthermore, knowing a little bit about the way Rene writes code, I can assure you that he is not capable of such a product. Again, in the late 1990s when RISC architectures were still trying to compete with Intel on workstation level boxes, it was a *big* research project to convert (binary) x86 machine code to other CPUs. Ignoring the disassembly issues, none of those projects were particularly successful. Some of my colleages at UC Riverside were involved in this stuff. It was *heavy* work. Again, if it was so simple, why weren't practical programs produced? Almost everything I've seen that attempted to solve this problem required the code to convert to be restricted to a subset of the 80486/Pentium instruction set and absolutely no tricky coding. Alas, even compiler output seemed to stymie these programs. Now I'm sure you can come up with a "helper" program that you can use to help you convert a small set of applications and minimize the amount of manual labor, perhaps doing as much as 50-70% of the grunt work for you, but unless you can guarantee perfection out of the tool, you're going to have to manually review each line of code, add comments, change labels, that sort of stuff. In the end, it just won't save you that much. In your NCR->IBM conversion, I'll bet that's exactly how the conversion was done. Because Bullock's was "betting the company" on the conversion, they were willing to throw a lot of resources at solving the problem. That's a different situation than a promise by Rene that "with two clicks you can compile your x86 code for the ARM processor." Just isn't going to happen. Even if you stick to using the same 20 instructions Rene uses for all his coding. > I was assigned as the project manager of IBM's support team, and after > many months of hard work by very talented people, we brought the project > in "On time, and within budget". Note the "very talented people" versus "a conversion program". I don't doubt for a moment that a team of very talented people could do the conversion. Just as I don't doubt that a team of very talented people could disassemble just about any program out there (despite the undecideability of the problem). But people operate "outside the box" (literally) and aren't subject to the same restrictions a computer program faces (i.e., the "incompleteness theorem"). Inferring that a program can be written to do the same thing as a talented team of people is a mistake on your part. > > Now, if, after this, and many other hardware and software conversions for > which I have been responsible, you still think that you can teach me > anything about the process, then its time to 'put up or shut up', because > doing a little 'research' just won't cut it. I have no question that *you* couldn't do such a conversion yourself. I have doubts that your could write a *program* that does this, and it's pretty much a given that Rene would be unable to do so. Don't take this as a personal insult. I have doubts that *I* would be successful in writing such a program (and if I did manage to write a semantically correct converter, I doubt the results would be that useful; more likely I'd spend several years and wind up with something like Port86 that has very limited practicality). That's why I gave up on it a couple of years back. But as you're so much better than me, feel free to try and do it. Cheers, Randy Hyde
From: o///annabee on 2 Feb 2006 20:25 P? 2 Feb 2006 16:32:28 -0800, skrev randyhyde(a)earthlink.net <randyhyde(a)earthlink.net>: A new slogan for Randall Hyde. > That's why I gave up on it a > couple of years back, > Randy Hyde >
From: Charles A. Crayne on 3 Feb 2006 00:38 On 2 Feb 2006 16:32:28 -0800 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: :Inferring that a :program can be written to do the same thing as a talented team of :people is a mistake on your part. Or at least it would be, if I had ever made such an inference, and an even bigger mistake if I deliberately implied such a thing. But in fact, you missed the point. My umbrage was taken at your claim that having written several compilers and assemblers, and having done some unspecified research, made you an expert on porting computer systems from one platform to another. To begin with, is there anyone with a CS degree who HASN'T done what you did? For my senior project [in EE, not CS], I designed a (trivial) computer, invented a (trivial) language, and wrote a (trivial) compiler. Big deal, NOT! In addition, writing an assembler brings nothing to the table, as this can be done without any ability to program the target architecture. Writing the code generation portion of a compiler is a bit more relevant, but not as valuable as actually writing assembly language programs for that architecture. :I, too, have been involved with lots of porting :projects over the years. I have my share of "war stories". If you wish to share them, describing what went right, what went wrong, and what lessons you learned from them, then we may have a basis for rational discussion, perhaps even as equals. :Now, I'd be willing to bet *big* money that your ports to the IBM were :*not* automatic. Some portions were. Some portions used pre-existing tools. Some news tools were written. Some entire application suites were replaced by existing IBM offerings. Some applications were converted. Others were replaced by new applications, written from scratch. In short, I have been in so many "The difficult we do immediately, the impossible takes a little longer." situations, that I have an almost intuitive feel for what can, and cannot, be done. Which brings us back to what I actually claimed: 1. Given a sufficient quantity of existing x86 code to make it worthwhile, I (at least) could write a tool such that it would take me less time to write the tool and port the code, than it would take me to port the code without the tool. 2. That I postulated the tool as processing the source line by line, and emitting one or more [e.g. PPC] instructions per x86 instruction, or flagging the line as needing attention from a human programmer. 3. That MicroAPL already has products which go beyond what I postulated, in that, like a compiler, they optimize the output code, based on information derived from multiple lines of source code. It was, and still is, my impression, that you denied all three of these assertions. Would you like to take this opportunity to clarify my understanding? -- Chuck
From: Charles A. Crayne on 4 Feb 2006 02:09
On 3 Feb 2006 18:56:39 -0800 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> wrote: :Now let's consider *every* line of RosAsm code ever written. Is that a :sufficient amount? Insufficient data. However, the 250,000 lines that you mentioned previously would certainly qualify. What do you like for a productivity figure for such work? Even at 500 lines/day, the project would take 500 days. Now, if a tool could translate 80% of those lines, the savings would be 400 days. :Download the demo and give it a shot. Impractical, in my case, since I don't do Windows, anymore. However, I did download and read the manual. :No offense, but when the program breaks on something as simple as this, :I think it's fair to forgive me for not having a whole lot of :confidence in the operation of the rest of the program. You didn't think that 'jmp jmpTbl[eax*4-8]' was a simple thing, in your previous posts, when you were using a similar construction as the number one reason why such a tool is impractical. In addition, you should not leap to judgement before trying the jump table hint described in the manual. All they ask is that you tell the tool the beginning and end of the jump table. :IIRC, the documentation claims that the program handles the parity :flag. Nor have you shown any evidence that it doesn't, as the conditional jumps seem to have been generated correctly. It would be interesting to see if a instruction must set hint would clean up the 'unknown register' issue. :I know :nothing about NCR machines, so I have no idea how well NCR instruction :semantics map to IBM 360 instructions. Very poorly. To begin with, where the basic addressability of the IBM 360 was four 8-bit bytes within a 32-bit word, NCR used 12-bit slabs, each of which contained either two 6-bit characters, or three 4-bit binary coded decimal digits. It had no registers, and no floating point instructions. We had to write data conversion programs for each application system, and transfer the data via 7-track tapes, with no tape labels. The list goes on and on. :Was the code checked to make sure that :you got the same results from both programs? The batch systems were run in parallel for a couple of months, but that was not practical for the on-line systems, such as the full positive credit authorization system, which served all of the Bullocks stores in the Los Angles basin. :BTW, I notice that MicroAPL has an assembly->C converter. I wonder how :well it works (not having downloaded anything to try it out). I, too, am very interested in knowing how good it is, as I have always considered such a tool to be quite difficult. Of course, as you know, merely converting it to C does not, by itself, make it portable. -- Chuck |