The thing inside of us that makes us go up is our attitude.

Random Image

Who's Online

We have 37 guests online


Members : 2
Content : 181
Web Links : 6
Content View Hits : 243380

Career@amiindia (Apr10 to Jul11)

AMI (American Megatrends Inc.) is a products and services company. AMI is well known for AMIBIOS. AMI India is a wholly owned subsidiary of AMI USA. At AMI India, I was with the embedded services division as Technologist. I was involved in the porting of GNU tool chains (gcc, binutils, and glibc) for RISC processors.

Apr10 to Jul11 (Porting GNU tool chain)

Initial Struggle

At AMI, the works I involved were on older versions of GNU tool chain. I.e. gcc of version 2.95.3, binutils of version 2.10.1 and glibc of version 2.2.5.

To be frank, initially I struggled even to build the tool chain from the source. The struggle was because I was not aware of the issues in building the older versions of GNU tool chain.

At acmet, I was working on the latest version (4.4.0) of gcc. And I used the latest compiler installed with the system as the bootstrap compiler for building gcc-4.4.0. Hence till then, I haven't faced any problem on building gcc.

But at AMI, I was working on the older version (2.95.3) of gcc. And on using the latest compiler (gcc-4.4.1) installed with the system as bootstrap compiler, I encountered so many build problems. To overcome the build problem, I had to downgrade the bootstrap compiler installed with the system to the lower version (2.95.4).

Also read: Building earlier versions of GNU Tool Chain

Porting gnu tool chain to a new architecture

I ported the gnu tool chain for a RISC processor (say 'Y'). Actually it was not an entire new port done by me. I just had to port an existing tool chain available for another RISC processor (say 'X') to this new RISC processor 'Y'. This is because, processor 'Y' is the advanced version of the processor 'X'.

Some of the differences between the processor 'X' and processor 'Y' are as follows:

'Y' has bigger pipeline than 'X'. As a result, all branches and jumps in 'Y' have three delay slots. whereas in 'X' all branches and jumps have only two delay slots.
opcodes of around 8 instructions varied between 'X' and 'Y'.
Both 'X' and 'Y' have zero register (register which is hardwired to zero such that it contains '0' anytime). But 'Y' has a bug such that at times, it may contain junk values other than zero.

For this, all the three (gcc, binutils and glibc) needs to ported. Till then, I had some exposure only on gcc. Binutils and glibc are entirely new to me. This task provided me the opportunity to get an intro on binutils and glibc.

Also read: Porting binutils to a new architecture, Internationalization of glibc

For porting gcc, modified the target description files under the folder gcc-2.95.3/gcc/config/<target>. For porting binutils, incorporated the change in opcode of instructions in the file binutils-2.10.1/opcodes/<target>-opc.c. For porting glibc, modified the target dependent files under the folder glibc-2.2.5/sysdeps/<target>.

Thus made gcc port is tested with standard tests. Also it is verified by building the monitor and u-boot from source. The builded executable is loaded into the board containing the processor 'Y'. Monitor and u-boot ran successfully on the board.

Training sessions on GCC

I got the oppurtunity of taking training sessions on GCC (GNU Compiler Collection) for the engineers at AMI who were interested on the same.

Also read: Basics of GCC

Fixing defects in existing tool-chain for RISC processor

I fixed three critical defects in an existing tool-chain for RISC processor.

The first defect was an assembler error "Relocation Overflow". On building the glibc using our ported compiler and assembler, we got "Relocation Overflow" assembler error. The cause for the same is that the RISC architecture has conditional branches that can only address destinations with a depth of 4000 bytes. But those conditional branches were used to address destination that were beyond the 4000 bytes. The compiler didn't take care of this. Successfully fixed the issue in the gcc compiler.

Also read: Support for long branches - GCC

The second one was a kernel crash issue. I.e. The kernel built with our ported gnu toolchain got crashed on loading it on the board for which it was built. Analyzed and fixed the issue in the compiler machine description.

The third one was a problem in handling the floating point operations. Analyzed and fixed the issue in the compiler machine description.

Monitor, u-boot, kernel and busybox were built with the gnu toolchain and the binaries of the same are loaded on the hardware board. All the monitor, u-boot, kernel and busybox functioned properly. Also the ported gnu toolchain were run for the dhrystone and whetstone benchmarks.

Also read: Dhrystone and Whetstone


I tested the gnu tool chains with the gcc testsuite and the perennial testsuite. Major part of the time during this period was spent on testing the ported gnu tool chains. Testing the gnu tool chain with the perennial testsuite (~9610 tests) took more time, as I had to execute the tests on the target board.

Also read: Testsuite for gcc-2.95.3