> The ARM Holdings emulator does this; I used it with great success to > profile an Advanced Encryption Standard encryptor a while back.It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or give access to. ________________________________________ From: Don Quixote de la Mancha [quixote at dulcineatech.com] Sent: 13 October 2011 18:47 To: Joe Abbey Cc: Renato Golin; rajav at codeaurora.org; llvmdev at cs.uiuc.edu; James Molloy Subject: Re: [LLVMdev] LLC ARM Backend maintainer On Thu, Oct 13, 2011 at 10:00 AM, Joe Abbey <jabbey at arxan.com> wrote:> However, we don't have testing resources to test both our product and LLVM > on a host of target boards. We have some chumbys, beagleboards, iPhones, > iPod Touches, tables, Android Phones, etc. And most of those are already > booked solid with our own regression tests (most of which are based on > llvm-test-suite) > Could ARM enable us with testing hardware/resources?The ARM-based Raspberry Pi is very close to shipping. The entry-level unit will retail for just $25 with a higher-end model for $35. I don't recall who makes it, but there is an ARM desktop computer that retails for $149, with the same company making an ARM Netbook for $199. I have a Gumstix Overo Fire COM which I'm using mostly to experiment with ARM assembly code and ARM-specific optimizations in C, C++ and Objective-C. When I get it configured reliably I'd be happy to dedicate it as a test machine most of the time. https://www.gumstix.com/store/product_info.php?products_id=227 This has an ARM Cortex A8 with NEON SIMD as well as a Texas Instruments DSP. The DSP isn't programmed yet but could readily be with TI's DSP/BIOS and Code Composer Studio. I just spent days and days and days building all of Anstrom Linux for it, so it has a full GUI desktop environment, development tools and God Almighty Knows What Else installed on it. It is on my home LAN which has a dynamic IP, but I understand there is a way I can set up a tunnel to my web server which has a fixed IP. I can also ask my hosting service for an additional IP so if necessary I could tunnel ALL the ports to my Gumstix board. I also have a first-generation Apple iPhone which has iOS 3.0.6 installed on it. To use it for a testing bot I'd need to prevent it from ever going to sleep; I *think* I can do that by setting Auto-Lock to Never in the General section of the Settings App. I would need to package the tests as some kind of iPhone App which (maybe) I could load on the phone automatically by automating either iTunes or the iPhone Configuration Utility with AppleScript. I'm not sure what ARM CPU my first-gen iPhone has but I think it uses the arm6 instruction set. Finally I have three Oxford Semiconductor FireWire / USB / Parallel IDE storage bridge chip target boards. They all have ARM7TDMI cores with 64 kb to 128 kb of Flash and some microscopic amount of RAM: my OXFW911 chip has 64 kb of 16-bit Flash but only 1800 BYTES - not Megabytes, not Kilobytes, but just BYTES - of RAM. There wouldn't be enough memory in these things to run a shell, but any of the tests that could be packaged as a subroutine with a single entry point could be compiled into the firmware. These all run 16-but Thumb 1 and 32-bit ARM code. My iOS devices - I also have a first-gen iPad and an iPhone 4 - can run Thumb 2. If you'd like me to set these all up to do building and testing I'd be happy to, but I need some handholding. I've been trying to bootstrap llvm-gcc4.2 on Ubuntu 11.04 with the aim of using the CLang analyzer on ZooLIb (http://www.zoolib.org/) but the bootstrap always fails because of bizarre problems with autoconf's configure scripts. I've tried to debug the configure scripts but have yet to have any joy. IMHO autoconf is A Tool of the Devil. ZooLib is even more cross-platform than autoconf is, but does not need shell scripts at all to configure it. I need to catch some ZZZs now, I've been up all night. I'll have another go at configuring my Overo this evening, then will try bootstraping LLVM for x86 again. If that works then I'll bootstrap it for ARM as well. You can also run the tests in a emulator. The timing won't be accurate but you should be able to catch gross speed regressions. There are several emulators available; the ones I know about are Softgun, QEMU, the GNU Debugger GDB and the ARM Holdings development system emulator. There is another one that I came across once whose name I don't recall. Some emulators emulate a full computer with I/O devices so you can run an OS on them. These emulators could then host the build and not just the test. There are other simulators that just execute a single subroutine tree and provide standard input and output. The cool thing about this kind of emulator is that one can count the number of instructions required to go from the beginning to the end of the subroutine, or with the addition of a memory map that gives access times for various kinds of memory (16-bit Flash or Dynamic RAM) you can get cycle counts for the subrouine. The ARM Holdings emulator does this; I used it with great success to profile an Advanced Encryption Standard encryptor a while back. Ever Faithful, Don Quixote -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Thu, Oct 13, 2011 at 11:11 AM, James Molloy <James.Molloy at arm.com> wrote:>> The ARM Holdings emulator does this; I used it with great success to >> profile an Advanced Encryption Standard encryptor a while back. > > It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or give access to.Indeed. My client at the time bought me my copy; it was bundled with the Oxford Semiconductor OXFW911 FireWire/IDE development board. The whole development system, I was told, cost USD $ 4,000.00. Happily, I still have it all, but it might take some time to actually lay my hands on it. Besides the memory mapping, the emulator also supports emulating I/O devices and interactions with other kinds of cores. It's meant to enable programming System-on-Chip designs before one has real hardware available. Cheerfully, Don Quixote -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com
Well how about as a strawman... taking some options from
http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores and
http://en.wikipedia.org/wiki/List_of_applications_of_ARM_cores
LLVM Supports:
ARMv4T -> ARM7TDMI
ARMv5TE -> ARM926EJ-S
-> XScale
ARMv6 -> ARM1136J(F)-S
ARMv6ZK -> ARM1176JZ(F)-S
ARMv7A -> Cortex-A8
Cortex-A9
ARMv7M -> Cortex-M3
Granted there are many many more listed within in ARM.td, but I think we should
start with a small subset and build on it as we begin guaranteeing maintenance.
Once we compile a set of ISAs and implementations, we could start logically
dividing the load and assigning maintainer roles.
Joe Abbey
Software Architect
Arxan Technologies, Inc.
1305 Cumberland Ave, Ste 215
West Lafayette, IN 47906
W: 765-889-4756 x2
C: 765-464-9893
jabbey at arxan.com<mailto:jabbey at arxan.com>
www.arxan.com
On Oct 13, 2011, at 2:11 PM, James Molloy wrote:
The ARM Holdings emulator does this; I used it with great success to
profile an Advanced Encryption Standard encryptor a while back.
It is indeed a useful piece of kit. We do a lot of our internal regression tests
on it, and also run LLVM's regression tests every night on it (as well as
PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can
give away or give access to.
________________________________________
From: Don Quixote de la Mancha [quixote at dulcineatech.com<mailto:quixote at
dulcineatech.com>]
Sent: 13 October 2011 18:47
To: Joe Abbey
Cc: Renato Golin; rajav at codeaurora.org<mailto:rajav at codeaurora.org>;
llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>; James Molloy
Subject: Re: [LLVMdev] LLC ARM Backend maintainer
On Thu, Oct 13, 2011 at 10:00 AM, Joe Abbey <jabbey at
arxan.com<mailto:jabbey at arxan.com>> wrote:
However, we don't have testing resources to test both our product and LLVM
on a host of target boards. We have some chumbys, beagleboards, iPhones,
iPod Touches, tables, Android Phones, etc. And most of those are already
booked solid with our own regression tests (most of which are based on
llvm-test-suite)
Could ARM enable us with testing hardware/resources?
The ARM-based Raspberry Pi is very close to shipping. The entry-level
unit will retail for just $25 with a higher-end model for $35. I
don't recall who makes it, but there is an ARM desktop computer that
retails for $149, with the same company making an ARM Netbook for
$199.
I have a Gumstix Overo Fire COM which I'm using mostly to experiment
with ARM assembly code and ARM-specific optimizations in C, C++ and
Objective-C. When I get it configured reliably I'd be happy to
dedicate it as a test machine most of the time.
https://www.gumstix.com/store/product_info.php?products_id=227
This has an ARM Cortex A8 with NEON SIMD as well as a Texas
Instruments DSP. The DSP isn't programmed yet but could readily be
with TI's DSP/BIOS and Code Composer Studio.
I just spent days and days and days building all of Anstrom Linux for
it, so it has a full GUI desktop environment, development tools and
God Almighty Knows What Else installed on it.
It is on my home LAN which has a dynamic IP, but I understand there is
a way I can set up a tunnel to my web server which has a fixed IP. I
can also ask my hosting service for an additional IP so if necessary I
could tunnel ALL the ports to my Gumstix board.
I also have a first-generation Apple iPhone which has iOS 3.0.6
installed on it.
To use it for a testing bot I'd need to prevent it from ever going to
sleep; I *think* I can do that by setting Auto-Lock to Never in the
General section of the Settings App.
I would need to package the tests as some kind of iPhone App which
(maybe) I could load on the phone automatically by automating either
iTunes or the iPhone Configuration Utility with AppleScript.
I'm not sure what ARM CPU my first-gen iPhone has but I think it uses
the arm6 instruction set.
Finally I have three Oxford Semiconductor FireWire / USB / Parallel
IDE storage bridge chip target boards.
They all have ARM7TDMI cores with 64 kb to 128 kb of Flash and some
microscopic amount of RAM: my OXFW911 chip has 64 kb of 16-bit Flash
but only 1800 BYTES - not Megabytes, not Kilobytes, but just BYTES -
of RAM.
There wouldn't be enough memory in these things to run a shell, but
any of the tests that could be packaged as a subroutine with a single
entry point could be compiled into the firmware.
These all run 16-but Thumb 1 and 32-bit ARM code. My iOS devices - I
also have a first-gen iPad and an iPhone 4 - can run Thumb 2.
If you'd like me to set these all up to do building and testing I'd be
happy to, but I need some handholding.
I've been trying to bootstrap llvm-gcc4.2 on Ubuntu 11.04 with the
aim of using the CLang analyzer on ZooLIb (http://www.zoolib.org/) but
the bootstrap always fails because of bizarre problems with autoconf's
configure scripts.
I've tried to debug the configure scripts but have yet to have any
joy. IMHO autoconf is A Tool of the Devil. ZooLib is even more
cross-platform than autoconf is, but does not need shell scripts at
all to configure it.
I need to catch some ZZZs now, I've been up all night. I'll have
another go at configuring my Overo this evening, then will try
bootstraping LLVM for x86 again. If that works then I'll bootstrap it
for ARM as well.
You can also run the tests in a emulator. The timing won't be
accurate but you should be able to catch gross speed regressions.
There are several emulators available; the ones I know about are
Softgun, QEMU, the GNU Debugger GDB and the ARM Holdings development
system emulator. There is another one that I came across once whose
name I don't recall.
Some emulators emulate a full computer with I/O devices so you can run
an OS on them. These emulators could then host the build and not just
the test.
There are other simulators that just execute a single subroutine tree
and provide standard input and output.
The cool thing about this kind of emulator is that one can count the
number of instructions required to go from the beginning to the end of
the subroutine, or with the addition of a memory map that gives access
times for various kinds of memory (16-bit Flash or Dynamic RAM) you
can get cycle counts for the subrouine.
The ARM Holdings emulator does this; I used it with great success to
profile an Advanced Encryption Standard encryptor a while back.
Ever Faithful,
Don Quixote
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quixote at dulcineatech.com
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111013/64f68551/attachment.html>
On Thu, Oct 13, 2011 at 11:25 AM, Joe Abbey <jabbey at arxan.com> wrote:> LLVM Supports: > ARMv4T -> ARM7TDMI > ARMv5TE -> ARM926EJ-S > -> XScale > ARMv6 -> ARM1136J(F)-S > ARMv6ZK -> ARM1176JZ(F)-S > ARMv7A -> Cortex-A8 > Cortex-A9 > ARMv7M -> Cortex-M3Does the LLVM code generator generate Thumb code in addition to ARM code? For those who don't know ARM, Thumb is a subset of ARM in which each instruction is 16-bits in size. ARM instructions are 32-bits; besides working poorly on 16-bit Flash, compilers have a hard time taking advantage of the ARM ISA's unique advantages, such as every instruction being conditional and most instructions have an optional shift or rotate of one of the register operands. The result is poor code density. Don't confuse the 16-bit instructions with a 16-bit ISA. Thumb can still address 32 bits of memory and has 32 bit registers. In fact when executing Thumb code, a single Thumb instruction is placed in an instruction prefetch buffer, decompressed to a 32-bit ARM instruction and only then is it executed. I read somewhere that the instructions present in the Thumb ISA were chosen to be what most C compilers generate. There is not just the Thumb that the ARM7TDMI executes, but there is also a slightly different and hopefully improved Thumb 2 instruction set that later cores like the Cortex A8 can execute. I'm pretty sure any CPU that can run Thumb 2 code can also run the original Thumb code. One can mix the two ISA through the use of instructions that switch the modes; this is called "Interworking". The regular way to return from an instruction is to put the return address into register 15, but the instruction BX (if I remember correctly) will both return from a subroutine and switch the ISA. I took advantage of this in my AES encryptor, which I wrote in tightly hand-optimized assembly, by writing the less time-critical outer loops in slower but more-compact Thumb code, with the more time-critical inner loops being in the ARM ISA. In some hopeful future day LLVM will be able to do this as well; if you have a compilation unit that is mostly Thumb but you inline some functions or unroll some loops, you should consider interworking to ARM mode there as well. I would expect that we would want profiler-guided optimization to drive that. -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com