Bruno C Lopes » compilers » disassemblers » isca13 » research » wivosca » x86

Category Archives: compilers

compilers disassemblers isca13 research wivosca x86

ISA Aging: A X86 case study

Published by:

Last sunday (23 Jun) in Tel Aviv, Israel, we presented the paper ISA Aging: A X86 case study in the WIVOSCA 2013, the Seventh Annual Workshop on the Interaction amongst Virtualization, Operating Systems and Computer Architecture, inside ISCA’13 – 40th International Symposium on Computer Architecture. The workshop was great, thanks to the organization held by Girish Venkatasubramanian and James Poe. Bellow the abstract:

Microprocessor designers such as Intel and AMD implement old instruction sets at their modern processors to ensure backward compatibility with legacy code. In addition to old back-ward compatibility instructions, new extensions are constantly introduced to add functionalities. In this way, the size of the IA-32 ISA is growing at a fast pace, reaching almost 1300 different instructions in 2013 with the introduction of AVX2 and FMA3 by Haswell. Increasing the size of the ISA impacts both hardware and software: it costs a complex microprocessor front- end design, which requires more silicon area, consumes more energy and demands more hardware debugging efforts; it also hinders software performance, since in IA-32 newer instructions are bigger and take up more space in the instruction cache. In this work, after analyzing x86 code from 3 different Windows versions and its respective contemporary applications plus 3 Linux distributions, from 1995 to 2012, we found that up to 30 classes of instructions get unused with time in these software. Should modern x86 processors sacrifice efficiency to provide strict conformance with old software from 30 years ago? Our results show that many old instructions may be truly retired.

Slides for the presentation can be downloaded here. Besides WIVOSCA, the AMAS-BT workshop on Binary Translation also had great talks. Moving from the workshops to the ISCA conference itself, there was an amazing talk entitled DNA-based Molecular Architecture with Spatially Localized Components, which totally twisted my mind regarding the emerging technologies topic. The conference isn’t over yet and I hope to attend more break-through research talks in the next few days.

arm compilers efikamx llvm

EfikaMX impressions!

Published by:

Hey everyone, it’s being a while since my last post. On 5th March 2009, I submitted a proposal to Power Developers to actually improve the ARM Cortex A8 support into the LLVM Compiler. The proposal was accepted in 24th August 2009, and the board arrived in late December.

Fresh new EfikaMX board

Fresh new Fedex shipment with a EfikaMX board

After opening the Fedex box, this is what we found:

Unpacked efika board

Unpacked efika board

The surprising news here, is that when I received the board all the improvements I had in mind and proposed to the Power Developers had already been implemented by other LLVM developers. Things not always go in the way we want to, but looking into the bright side I had a new shinning board to play with, and compiler backends always have room for small improvements.

So, first of all, lets look how this beautiful toy looks like. The “genesi” name actually reminds me of my good old sega genesis (good old times), but getting back to what matters, here is how it looks attached to an external monitor (using the HDMI port) and booting linux.

Attached to an external monitor

Attached to an external monitor

After booting up and gathering information about the system, I installed gnome and did play with some applications to see how efficient it was. It surprised me, it was faster than I expected, even without the proprietary drivers needed to use the video decoding processor. This is an album with all pictures I took from EfikaMX, they were all taken in the day I received the board back in 9 December 2009.

Before talking about what my current plans are I do have some greetings to do: Thanks very much to Genesi U.S.A., Inc and to Raquel and Bill @ Genesi, to being so kind providing a board and making llvm developers happier. Also I would like to apologize to them by the time I took to give them a feedback, sorry for taking so long 🙂

I’m currently in the USA doing a summer internship and my board is at Brazil right now, so until October I don’t have any way to give it attention, but at the EfikaMX/llvm/ARM side of things, these are future plans:

  • Set-up EfikaMX as a linux ARM backend test machine, so we can run llvm test suite on it and be sure it gets working for linux (we don’t have that for linux in the moment)
  • Consider the possibility to implement random small optimizations aimed to ARM/linux, as for example this gcc bug.
compilers llvm mips

mips and llvm 2.4

Published by:

LLVM 2.4 is now available, and like every very active project, a bunch of new stuff has arrived (see the release notes for a detailed description). The same is true for the Mips back-end. I talked about mips+llvm in old posts, they highlighted some of the ABI issues both from EABI and O32 stuff. A lot has changed since those posts, and here is a summary of what has been accomplished:

  • Little endian support
  • EABI is fully implemented
  • Floating point support
  • Support for allegrex core and its intrinsics
  • Improvements to the O32 ABI.

I’m the creator and current Mips back-end mainteiner, and I implemented those feature as a Google Summer Of Code 2008 project. To a more detailed description, here is the svn commit log for the Mips back-end  –  I filtered out all commits not directly related to mips improvement). Although it has grown a lot since June, it still a experimental back-end and there is much to be done.

compilers llvm mips

Structure return

Published by:

As said in the previous post, some ABI specs are a little confusing, and sometimes there are so many (15 different variations for mips), that you just don’t remember where that rule came from. For the more interested ones there’s a whole history about mips ABIs and why there are some many. I’ll devote my time in the next posts, writing about implementations issues in o32 and eabi ones. llvm mips backend is walking toward full support for both (I already implemented the basic calling convention mechanism for o32 and eabi) I’ll approach some issues giving some llvm view of things.

o32

o32 is the mips old 32 bit ABI specified by Sysv4. It’s easy to find o32 on a linux box or in embedded mips applications, worth having support on a compiler. o32 is known for its bad register usage (it’s very inefficient when compared to eabi for example) and messy spec. So, since it is the most comom llvm should have it.

eabi

As all the other used ABIs, the eabi is implemented in GCC. There is no official documentation about it and the only resource available is a post on binutils mailing list and gcc mips backend sources. Although this is the only doc available, it is very direct and a thousand times better than the sysV one. This ABI is used to generate mips assembly for the psp allegrex core (the pspdev gcc patches from uses eabi by default). Since I’m giving support for the allegrex core, this abi must be implemented in llvm.

Structure return

If a pointer to a struct is returned, then it is considered a normal pointer and nothing special has to be done. But if a function returns the whole aggregate, the space must be allocated on the caller and the aggregate address must be passed as the first argument ($4) to the callee. The callee must fulfill this memory space with the returned value before exiting and must also return the pointer in $2. This mechanism is called sret in llvm, where we use a argument with a pointer to the memory space reserved for the aggregate. To be more specific, if we consider this C function:

The following asm output for function test0 is:

As the code highlights the pointer argument comes in $4, is copied to the return value register $2, and the struct is fulfilled by storing the 2nd argument ($5) into the memory pointed by $4. The eabi has almost the same behavior when dealing with struct passing, the only difference is that it directly returns single element structs and aggregates <= 64 bits, and only uses the shadow mechanism otherwise (eabi always uses registers when it’s possible, that’s why it’s so fast, someday I’ll deserve it a post).

compilers llvm mips

Mips calling convention review

Published by:

Hi! Long days have passed since the last time I wrote here. A Chinese bot stole my domain, and since I havent paid in time, I also lost my old blog stuff. ok, beginning all over again! 😉

I got back to mips llvm work and I’m improving it now to support the psp allegrex core. I improved a lot of minor codegen stuff this month and my next milestone is getting llvm-gcc cross-compiled for Mips, it is breaking now for float stuff, so here we go…

LLVM mips backend currently does only support 32 bit integer arguments (64-bit integer args are not legal and are expanded since 64bit ISAs aren’t supported yet).

I’m currently hacking out the ABI requirements for:

  • Float-point arguments
  • Struct arguments (reference and By Value)
  • Struct returning

Since GCC implementation differs a little from SysV ABI specs (the spec is very bad written) I often get confused if I’m implementing the right thing. To avoid reading this stuff every time I may post some low level info here, so it should be easy to get a reference when needed.

Stay tuned! 😉