Who should use Relogix?
Anyone who has a substantial piece of assembler source code which needs to be converted to C so that it can be developed and enhanced further, and which is written for one of the architectures which Relogix supports.
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 the software migration 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 produce a natural C translation. Typically, you use the translated output as a basis for further development and enhancement. The translation is less of a mechanical, repeatable process, but instead is likely to be a one-off project to migrate your code base entirely to a portable high-level language.
You can even combine both approaches, using Relogix to port specific assembly-language subroutines to C, and PortAsm to convert the rest.
Isn't it impossible to convert an assembler source file to good-quality C automatically?
No, it is quite possible. Relogix uses a combination of intensive code analysis combined with clever use of clues in the assembler source files to figure out what the program is doing so it can reproduce the results in natural C style. To get a feel for how well this works, see the sample Relogix translations.
But how can the unstructured code flow of an assembler program be converted to natural, structured C?
Relogix uses very advanced code-flow analysis and transformation algorithms to analyse the original assembler constructs (conditional and unconditional branches, indirect jumps, jump tables etc), and convert them to standard C-style constructs such as 'for' loops. Natural function prototypes, based on the actual live data passed into and used by an assembler subroutine, are also generated.
But assembler has no type information, whereas C uses typed variables. Do you simply translate everything using an array of longs to represent the register contents?
No, register-based data in the original program is held in natural, properly typed local variables and function parameters in the translated C. Relogix carries out a comprehensive analysis of register-based and memory-based data use to determine natural types for the variables. This includes automatically determining structure and union types.
But what about variable names? Don't you have to generate meaningless names in the translation?
Relogix uses a combination of advanced techniques to choose meaningful names for local variables and function parameters. This includes seeing how the data is used, what its type is, and how it is referred to in the assembler comments. Memory-based data is usually given a name based on the original assembler name. The results are such that the translated code is usually extremely readable, as in this small sample (see the sample Relogix translations for more complex functions):
long loopback_init (struct lk *lk_ptr)
{
long result; /* [Originally in d7] */
unsigned long link_number; /* [Originally in d0] */
link_number = linkno; /* D0 = link number */
/* Too many LOOPBACK links declared ? */
if (link_number >= MAX_LINKS)
result = -1;
else {
linkno++;
lk_ptr->lk_num = link_number; /* Save link driver number */
linktab [link_number] = lk_ptr; /* Save LCB address */
result = 0; /* No error */
}
return result;
}
What assembler architectures can Relogix handle?
Relogix currently converts 68K family (including CPU32 and ColdFire), x86 family (32-bit flat mode), IBM mainframe, and 8051-family, PIC16/18-family and 65C02 assembler to C. MicroAPL will progressively be supporting other architectures over the coming months - please let us know what your requirements are.
We can often translate assembler code for other processors to C. For more information including an example, see here.
Can Relogix handle in-line floating-point instructions?
Relogix/86, which translates x86-family assembler code to C, includes the ability to translate floating-point instructions.
Other versions of Relogix do not currently handle floating-point instructions.
Is Relogix related to the University of Queensland asm2c tool?
No, they are completely different, although asm2c does some of the same kinds of code transformations which Relogix does. Relogix is much more aimed at translation of hand-written assembler code than asm2c, and it puts much more emphasis on retrieving as much information as possible from the original source text. The asm2c tool seems to put more emphasis on re-targeting binary programs, which may have been originally written in a high-level language rather than assembler.
Is Relogix sold as a tool or as a porting service?
Either. For smaller projects, where the objective is to convert a body of code from assembler to C as a one-off exercise, it is quickest and most cost-effective to take advantage of MicroAPL's Relogix Translation Service. This is normally offered as a fixed-price conversion. First you set up a suitable Non-Disclosure Agreement (click here to download MicroAPL's standard agreement). Then you e-mail the source code to MicroAPL, and our experts will carry out the automatic Relogix translation for you, leaving you to finish any hand-tuning of the translated source.
Alternatively, because Relogix is fairly easy to use, you can purchase a Relogix/68K or Relogix/86 licence and do the conversion in-house. This option may be preferable for larger projects which justify purchase of a Relogix licence, especially where you want to do the conversion in an iterative way in order to tune it to your requirements. Note: Relogix/MF, Relogix/51, Relogix/PIC and Relogix/6502 are only currently available as a porting service only.
You can also take advantage of MicroAPL's unrivalled expertise in cross-architecture porting by engaging MicroAPL's consultants to work with you on specific issues or to carry out the whole conversion including any hand-tuning of the automated Relogix translation.
How can I be certain that it will work for my project?
The best way is to take advantage of the Relogix PortCheckTM Service. After setting up an NDA, you e-mail your source code to MicroAPL and our engineers will check if there are any special porting issues. They will also run it through the Relogix translator and send you back some samples of the translation, as well as a fixed-price quote for converting your code under the Relogix Translation Service.
Relogix has been used successfully on many projects. You can find details of some of them here.
Our company lawyers won't let me send our source code to a third party even if we set up an NDA, so I can't use the Relogix PortCheck Service or the Relogix Translation Service. What can I do?
If you can't persuade them that it is impossible for MicroAPL to port software which it does not have access to, you should get yourself some new lawyers. Alternatively, you can buy a Relogix tool licence and do the translation in-house, or engage MicroAPL's consultants to come to your site and do the translation for you on your company machines.
What are the intellectual property issues when using Relogix?
Usually none, as Relogix is a source-code conversion tool. Intellectual property rights in the translated code remain with the owner of the rights to the original assembler source. Of course, if you do not have full rights to the original source, then you may need to ask permission of the owner before converting it to C. This would probably also be true if you converted it by hand.
I don't have the source to the code I want to convert to C. Can I disassemble it and use Relogix to translate the disassembled code?
Technically, this is possible but it is not what Relogix is primarily designed for. The results will be much inferior to those you would get by starting from assembler source, because valuable information such as global variable names, symbolic equates, and label names will be partially or completely missing, and comments will not be available.
Legally, there may well be a problem in using Relogix in this way, and you would need to check the licence under which you obtained the code which you want to disassemble and translate. It would be unusual for you to have the right to convert code in this way without also having a copy of the original source. For this reason, MicroAPL may require assurances that intellectual property rights are not being violated before permitting Relogix to be used to translate disassembled code.
C code written in our company has to conform to our C Style Guide. Can the output from Relogix handle this?
The final C source output by Relogix is processed by the Relogix Style Manager module, which ensures a consistent style for the generated source in terms of things like spacing, use of new-lines, and variable-naming conventions (for example you can optionally select 'Hungarian notation'). There are a large number of options which can be set to determine the style of the final code (many of these are closely modelled on the command-line options of the Gnu 'indent' program). Thus, it is likely that Relogix will be able to produce code which is consistent with your style guide, or at least is very close.
What about external calls to the operating system and to code we've written in C or Pascal?
Relogix recognizes external calls, and automatically produces C code which passes the correct parameters to the called routine.
My code is written for an IBM mainframe and makes uses the 'packed' and 'zoned' data types. How does Relogix handle these?
Where an instruction which operates on packed or zoned data cannot be translated in-line, Relogix converts it into a call to a support library provided by MicroAPL.
How do you handle the EBCDIC character set used by mainframes?
IBM mainframes use a character encoding known as EBCDIC, whereas most other systems use ASCII. One consequence is that the sorting order of strings is different in the two character sets. 'A1' comes before 'AA' in EBCDIC but the order is reversed in ASCII.
Where the code is being translated from assembler to C but will continue to run on the mainframe, everything will remain in EBCDIC and this is not an issue.
However, for maximum portability the code needs to be able to run on ASCII hosts. There are two ways of achieving this. The first way is to leave the bulk of the application in EBCDIC and translate to and from ASCII at the I/O interface. (For example, an ASCII text file it is converted to EBCDIC as it is read in). The alternative is to convert the whole application to use the natural character convention of the host, and then isolate any EBCDIC dependencies with conditional compilation.
MicroAPL has used both techniques very succesfully, and our engineers will handle EBCDIC issues as part of the porting service.
Sounds great - how much does it cost and how do I order?
Please refer to our Relogix Pricing & Ordering Page.