PortAsm and Relogix both port assembler source code to a different architecture. What's the difference, and why does MicroAPL sell both?
PortAsm is an assembler-to-assembler translator, whereas Relogix is an assembler-to-C translator. PortAsm retains the original program flow, acting somewhat like a very sophisticated compiler to generate code for the target architecture from the original assembler source. This means that translation is very automatic, and you don't normally need to change the output by hand. However, only specific target architectures are supported, and you may not want to continue to maintain or develop the original assembler source, so PortAsm is not always the best solution.
In contrast, Relogix makes bigger changes to the structure and flow of the original program, in order to provide a natural C translation. Typically, you use the translated output as a basis for further development and enhancement, so translation is less of a mechanical, repeatable process, and more of a step (albeit a very big one) towards converting your code base entirely to a portable high-level language and throwing away the original assembler source.
You can even combine both approaches, using Relogix to convert specific subroutines to C and PortAsm to translate the rest.
Who should use PortAsm?
Anyone who has a substantial piece of 680x0 assembler source code which needs to be ported to run native on a POWER/PowerPC or 80x86 processor, or who has 80x86 code which needs to run on POWER/PowerPC.
PortAsm can be used for applications written wholly in assembler, as well as for applications written partly in assembler and partly in a high level language such as C or Pascal.
If you have assembly language source code that is written for a different processor please talk to us about your requirements.
Is PortAsm sold as a tool or as a porting service?
Either. PortAsm is easy to use, so many of our customers buy PortAsm and carry out the port themselves. In other cases, they take advantage of MicroAPL's extensive expertise in porting software to different architectures. MicroAPL offers consultancy services varying from help with specific issues right up to complete 'turnkey' porting projects where we handle the whole port.
How efficient is the code that PortAsm produces?
Generally, very efficient, since PortAsm carries out a comprehensive analysis of the original program and generates optimized code for the new architecture. Where necessary, critical parts of the application can be re-coded in assembler (in the original source file), to take advantage of specific features of the new architecture.
Has PortAsm been successfully used to produce reliable, commercial-quality software?
Yes, PortAsm has been proven in commercial use again and again over a period of many years. It has been successfully used by major software houses, by small developers, and by major manufacturers such as Apple Computer and Freescale Semiconductor (now NXP). (As long ago as the mid-nineties, several of the major Macintosh applications - including HyperCard and WordPerfect for Macintosh - were ported to the PowerPC using PortAsm). In the embedded arena, it has proved its worth in a wide variety of different projects and application areas, in fields such as telecommunications, industrial automation, consumer electronics, enterprise storage systems, and many others. See here for a brief summary of recent client projects.
What size of project can PortAsm handle?
PortAsm has been used for porting projects of all sizes, starting from a few thousand lines of assembler. The largest commercial porting project to date involved translating 2,000,000 lines of CISC assembler and linking the result to a further substantial body of C code.
How can I be certain that it will work for my project?
Most code translates very easily, with little manual intervention. If there are any unusual features of your software which you think might cause problems, contact MicroAPL and we will be able to advise.
What about support?
Included with each copy of PortAsm is a free 90-day subscription to MicroAPL's PortAsm Support Service, by fax or E-Mail. We aim to answer queries in 24 hours, and our customers tell us that the standard of our technical support is excellent.
Is translation a one-off exercise?
Most of our customers maintain their code in the original assembler, using PortAsm as part of their normal build process. You can take advantage of specific features of the new architecture by including assembler for the new processor in your original source, or by calling routines written in C or Pascal. However, if you want to do a one-off translation where you make subsequent changes in the new source, then you can do so.
What about debugging? Isn't it rather hard?
Actually, it is very easy, because PortAsm includes a number of features to help you. The most important of these is support for symbolic debugging using your original 680x0 or 80x86 code as 'source' for the debugger, meaning you can step through the original CISC source in your native POWER Architecture or 80x86 debugger!
Here is a screen shot of source level debugging for code translated from 80x86 to POWER Architecture. The translated program is being debugged using the SDS Single Step environment
In the example above a breakpoint has been placed at the label 'sieve2'. The user has chosen 'Mixed' output, ie to display both the original x86 source together with the original comments, and the disassembled POWER Architecture code.
Here is a similar example for 680x0 assembly-language source which has been translated into 80x86 by PortAsm.
In this example, the debugging is taking place under Borland's C++ Builder. The code has been stopped at a breakpoint in the subroutine 'test_0001'. The (partially-obscured) window on the left shows the original 68K source, and the user has chosen to display the mixed source and x86 disassembly in the CPU window. Note that the 68K register names are available as symbols d0-d7/a0-a7, and the user is displaying these in the Watch window.
What about external calls to the operating system and to code we've written in C or Pascal?
PortAsm recognizes external calls, and automatically produces code which passes the correct parameters to the native Application Programming Interface. Where necessary, it will automatically generate 'glue' code to handle differences in the run-time environment. It does this using information contained in a file which you create as part of the porting process. This file describes the external interface in a format which is very similar to a C header file.
Can PortAsm handle in-line floating-point instructions?
The 680x0 to x86 version of PortAsm automatically translates 68881/68030/68040 floating point instructions. At present, other versions of PortAsm do not translate floating-point instructions, but depending on how your application is structured it may be fairly easy to adapt the code to use the target system's float instructions and/or external floating-point libraries.
What about porting system software?
PortAsm can be used to translate system software (such as operating systems and drivers), but it does not automatically handle certain hardware-specific features and special operations like memory management. In practice, this means that the translation requires slightly more manual intervention than is normal for application porting.
Will it work with the other tools we use?
What skills will our engineers need to carry out the translation?
No unusual skills are needed, but engineers carrying out the port will need good knowledge of the original 680x0 or 80x86 assembler. Before carrying out the work, they should acquire a general understanding of the target architecture, instruction set and runtime environment.
Sounds great - how much does it cost and how do I get a copy?
Please refer to our PortAsm Pricing
& Ordering Page.