Hi Johnny, Thanks for this - particularly the tip about cfe-dev. I'm currently trying to coerce lldb to debug these type of architectures (our current toolchain already outputs good dwarf info). However, I'm struggling since lldb has just assumes that the size of a byte is universally 8-bits. At some stage, I *think* at some stage we'd like to derive a compiler, from the "same code-base" (i.e. llvm) and I wondered how tricky this would be. Matt On Tue, 9 Sep 2014 11:49:01 +0100 Johnny Val <johnnydval at gmail.com> wrote:> Hi Matthew, > > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I > believe your bigger issue will be the fact that you would need to make > i24's a legal type in your backend, which as far as I know (unless > something has changed recently), is a _big_ job. I briefly looked > into it at one point, and decided to leave it for another day. > > I am also unsure how hard byte=8bits is backed into Clang. You might > want to ask cfe-dev. > > I hope that helps. > > Johnny > > On Tue, Sep 9, 2014 at 7:41 AM, Matthew Gardiner <mg11 at csr.com> wrote: > > > Hi, > > > > We have some DSP architectures (kalimba) which have 24-bits as their > > "minimum addressable unit". So this means that the sizeof a char > > (and an int and a short for that matter) is 24-bits. > > > > I quickly read the posted link WritingAnLLVMBackend.html but did not > > see an obvious answer to the following question: > > > > Is it possible to write a backend that faithfully represents these > > architectures or is sizeof_byte==8 bits baked into to llvm? > > > > Does anyone have any views on the above? > > > > thanks > > Matthew Gardiner > > > > > > On Tue, 9 Sep 2014 18:21:01 +1200 > > Bruce Hoult <bruce at hoult.org> wrote: > > > > > http://llvm.org/docs/WritingAnLLVMBackend.html > > > > > > > > > On Tue, Sep 9, 2014 at 6:09 PM, Prakash Premkumar > > > <prakash.prax at gmail.com> wrote: > > > > > > > How does LLVM generate machine code for different architectures? > > > > For example, the machine code for x86 and amd will vary. > > > > > > > > How does LLVM convert its IR to machine code for different > > > > architectures.Can you please explain the approach? Is it just > > > > write two different programs for two different architectures > > > > and pass a flag to the compiler based on which machine code you > > > > want to generate? > > > > > > > > Thanks a lot for your explanations. > > > > > > > > Thanks > > > > Prakash > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > > > > > > To report this email as spam click > > > https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== . > > > > > > > > Member of the CSR plc group of companies. CSR plc registered in > > England and Wales, registered number 4187346, registered office > > Churchill House, Cambridge Business Park, Cowley Road, Cambridge, > > CB4 0WZ, United Kingdom More information can be found at > > www.csr.com. Keep up to date with CSR on our technical blog, > > www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, > > www.youtube.com/user/CSRplc, Facebook, > > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter > > at www.twitter.com/CSR_plc. New for 2014, you can now access the > > wide range of products powered by aptX at www.aptx.com. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Patrik Hägglund H
2014-Sep-09 18:55 UTC
[LLVMdev] Machine Code for different architectures
Hi Matt, We maintain a set of patches to the LLVM codebase for 16-bit bytes, and non-power-of-2 register sizes. Support for non-power-of-2 register sizes and the addition of new machine value types, such as i24, is a "medium-sized" patch set. Support for 16-bit bytes is a quite large patch set, and it may be even larger after cleanup. (Usually, we just need to parameterize the byte size, or replace a size in bytes with a size in bits, but for a few instances, we currently have switch statements, handling 8-bit and 16-bit byte size separately, and leaving other sizes unimplemented.) We currently don't use the code from any other LLVM project, such as clang or lldb. Our plan is to someday clean up the LLVM patches, and submit them upstream. In the meantime, I can to provide them upon request. /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Matthew Gardiner Sent: den 9 september 2014 14:20 To: Johnny Val Cc: Bruce Hoult; Prakash Premkumar; llvmdev Subject: Re: [LLVMdev] Machine Code for different architectures Hi Johnny, Thanks for this - particularly the tip about cfe-dev. I'm currently trying to coerce lldb to debug these type of architectures (our current toolchain already outputs good dwarf info). However, I'm struggling since lldb has just assumes that the size of a byte is universally 8-bits. At some stage, I *think* at some stage we'd like to derive a compiler, from the "same code-base" (i.e. llvm) and I wondered how tricky this would be. Matt On Tue, 9 Sep 2014 11:49:01 +0100 Johnny Val <johnnydval at gmail.com> wrote:> Hi Matthew, > > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I > believe your bigger issue will be the fact that you would need to make > i24's a legal type in your backend, which as far as I know (unless > something has changed recently), is a _big_ job. I briefly looked > into it at one point, and decided to leave it for another day. > > I am also unsure how hard byte=8bits is backed into Clang. You might > want to ask cfe-dev. > > I hope that helps. > > Johnny > > On Tue, Sep 9, 2014 at 7:41 AM, Matthew Gardiner <mg11 at csr.com> wrote: > > > Hi, > > > > We have some DSP architectures (kalimba) which have 24-bits as their > > "minimum addressable unit". So this means that the sizeof a char > > (and an int and a short for that matter) is 24-bits. > > > > I quickly read the posted link WritingAnLLVMBackend.html but did not > > see an obvious answer to the following question: > > > > Is it possible to write a backend that faithfully represents these > > architectures or is sizeof_byte==8 bits baked into to llvm? > > > > Does anyone have any views on the above? > > > > thanks > > Matthew Gardiner > > > > > > On Tue, 9 Sep 2014 18:21:01 +1200 > > Bruce Hoult <bruce at hoult.org> wrote: > > > > > http://llvm.org/docs/WritingAnLLVMBackend.html > > > > > > > > > On Tue, Sep 9, 2014 at 6:09 PM, Prakash Premkumar > > > <prakash.prax at gmail.com> wrote: > > > > > > > How does LLVM generate machine code for different architectures? > > > > For example, the machine code for x86 and amd will vary. > > > > > > > > How does LLVM convert its IR to machine code for different > > > > architectures.Can you please explain the approach? Is it just > > > > write two different programs for two different architectures > > > > and pass a flag to the compiler based on which machine code you > > > > want to generate? > > > > > > > > Thanks a lot for your explanations. > > > > > > > > Thanks > > > > Prakash > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > > > > > > To report this email as spam click > > > https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== . > > > > > > > > Member of the CSR plc group of companies. CSR plc registered in > > England and Wales, registered number 4187346, registered office > > Churchill House, Cambridge Business Park, Cowley Road, Cambridge, > > CB4 0WZ, United Kingdom More information can be found at > > www.csr.com. Keep up to date with CSR on our technical blog, > > www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, > > www.youtube.com/user/CSRplc, Facebook, > > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter > > at www.twitter.com/CSR_plc. New for 2014, you can now access the > > wide range of products powered by aptX at www.aptx.com. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Patrik Hägglund H
2014-Sep-09 19:31 UTC
[LLVMdev] Machine Code for different architectures
Hi Matt, Another problem, specific for DWARF, is that in some places we want to have "target byte size" (for all target-dependent debug information) and in other places 8-bit byte size (for target-independent encoding of data - DWARF4 chapter 7). This means that, for us, some assembler-emitting functions need to be able to handle _both_ 8-bit bytes and 16-bit bytes. We have solved this by optionally changing some parameters to passing sizes in bits, rather than bytes. However, support of debug information is far from finished for our target. /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Patrik Hägglund H Sent: den 9 september 2014 20:55 To: Matthew Gardiner Cc: Bruce Hoult; Prakash Premkumar; llvmdev Subject: Re: [LLVMdev] Machine Code for different architectures Hi Matt, We maintain a set of patches to the LLVM codebase for 16-bit bytes, and non-power-of-2 register sizes. Support for non-power-of-2 register sizes and the addition of new machine value types, such as i24, is a "medium-sized" patch set. Support for 16-bit bytes is a quite large patch set, and it may be even larger after cleanup. (Usually, we just need to parameterize the byte size, or replace a size in bytes with a size in bits, but for a few instances, we currently have switch statements, handling 8-bit and 16-bit byte size separately, and leaving other sizes unimplemented.) We currently don't use the code from any other LLVM project, such as clang or lldb. Our plan is to someday clean up the LLVM patches, and submit them upstream. In the meantime, I can to provide them upon request. /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Matthew Gardiner Sent: den 9 september 2014 14:20 To: Johnny Val Cc: Bruce Hoult; Prakash Premkumar; llvmdev Subject: Re: [LLVMdev] Machine Code for different architectures Hi Johnny, Thanks for this - particularly the tip about cfe-dev. I'm currently trying to coerce lldb to debug these type of architectures (our current toolchain already outputs good dwarf info). However, I'm struggling since lldb has just assumes that the size of a byte is universally 8-bits. At some stage, I *think* at some stage we'd like to derive a compiler, from the "same code-base" (i.e. llvm) and I wondered how tricky this would be. Matt On Tue, 9 Sep 2014 11:49:01 +0100 Johnny Val <johnnydval at gmail.com> wrote:> Hi Matthew, > > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I > believe your bigger issue will be the fact that you would need to make > i24's a legal type in your backend, which as far as I know (unless > something has changed recently), is a _big_ job. I briefly looked > into it at one point, and decided to leave it for another day. > > I am also unsure how hard byte=8bits is backed into Clang. You might > want to ask cfe-dev. > > I hope that helps. > > Johnny > > On Tue, Sep 9, 2014 at 7:41 AM, Matthew Gardiner <mg11 at csr.com> wrote: > > > Hi, > > > > We have some DSP architectures (kalimba) which have 24-bits as their > > "minimum addressable unit". So this means that the sizeof a char > > (and an int and a short for that matter) is 24-bits. > > > > I quickly read the posted link WritingAnLLVMBackend.html but did not > > see an obvious answer to the following question: > > > > Is it possible to write a backend that faithfully represents these > > architectures or is sizeof_byte==8 bits baked into to llvm? > > > > Does anyone have any views on the above? > > > > thanks > > Matthew Gardiner > > > > > > On Tue, 9 Sep 2014 18:21:01 +1200 > > Bruce Hoult <bruce at hoult.org> wrote: > > > > > http://llvm.org/docs/WritingAnLLVMBackend.html > > > > > > > > > On Tue, Sep 9, 2014 at 6:09 PM, Prakash Premkumar > > > <prakash.prax at gmail.com> wrote: > > > > > > > How does LLVM generate machine code for different architectures? > > > > For example, the machine code for x86 and amd will vary. > > > > > > > > How does LLVM convert its IR to machine code for different > > > > architectures.Can you please explain the approach? Is it just > > > > write two different programs for two different architectures > > > > and pass a flag to the compiler based on which machine code you > > > > want to generate? > > > > > > > > Thanks a lot for your explanations. > > > > > > > > Thanks > > > > Prakash > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > > > > > > To report this email as spam click > > > https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== . > > > > > > > > Member of the CSR plc group of companies. CSR plc registered in > > England and Wales, registered number 4187346, registered office > > Churchill House, Cambridge Business Park, Cowley Road, Cambridge, > > CB4 0WZ, United Kingdom More information can be found at > > www.csr.com. Keep up to date with CSR on our technical blog, > > www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, > > www.youtube.com/user/CSRplc, Facebook, > > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter > > at www.twitter.com/CSR_plc. New for 2014, you can now access the > > wide range of products powered by aptX at www.aptx.com. > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Patrik, Thanks for this note. It's encouraging to read there has been some provision made for non-8-bit bytes. I'm not a compiler/backend expert, (although maybe I'll need to be soon!), so I won't look at the patches right now, however may at some stage in the future myself or colleague may request these patches from yourself. Yes, our 24-bit architectures have non-power-of-2 register sizes. When you mentioned addition of i24 - would that facilitate this architecture to claim that it's bytes are 24-bits in size? (Sorry for being vague, but I'm a debugger person currently...) thanks again for your help, Matt On Tue, 2014-09-09 at 18:55 +0000, Patrik Hägglund H wrote:> Hi Matt, > > We maintain a set of patches to the LLVM codebase for 16-bit bytes, and > non-power-of-2 register sizes. Support for non-power-of-2 register sizes > and the addition of new machine value types, such as i24, is a "medium-sized" > patch set. Support for 16-bit bytes is a quite large patch set, > and it may be even larger after cleanup. (Usually, we just need to > parameterize the byte size, or replace a size in bytes with a size in bits, > but for a few instances, we currently have switch statements, handling 8-bit > and 16-bit byte size separately, and leaving other sizes unimplemented.) > > We currently don't use the code from any other LLVM project, > such as clang or lldb. > > Our plan is to someday clean up the LLVM patches, and submit them upstream. > In the meantime, I can to provide them upon request. > > /Patrik Hägglund > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Matthew Gardiner > Sent: den 9 september 2014 14:20 > To: Johnny Val > Cc: Bruce Hoult; Prakash Premkumar; llvmdev > Subject: Re: [LLVMdev] Machine Code for different architectures > > Hi Johnny, > > Thanks for this - particularly the tip about cfe-dev. I'm currently > trying to coerce lldb to debug these type of architectures (our > current toolchain already outputs good dwarf info). However, I'm > struggling since lldb has just assumes that the size of a byte is > universally 8-bits. At some stage, I *think* at some stage we'd like to > derive a compiler, from the "same code-base" (i.e. llvm) and I > wondered how tricky this would be. > > Matt > > On Tue, 9 Sep 2014 11:49:01 +0100 > Johnny Val <johnnydval at gmail.com> wrote: > > > Hi Matthew, > > > > The byte==8 bits is more of a Clang issue rather than an LLVM issue. I > > believe your bigger issue will be the fact that you would need to make > > i24's a legal type in your backend, which as far as I know (unless > > something has changed recently), is a _big_ job. I briefly looked > > into it at one point, and decided to leave it for another day. > > > > I am also unsure how hard byte=8bits is backed into Clang. You might > > want to ask cfe-dev. > > > > I hope that helps. > > > > Johnny > > > > On Tue, Sep 9, 2014 at 7:41 AM, Matthew Gardiner <mg11 at csr.com> wrote: > > > > > Hi, > > > > > > We have some DSP architectures (kalimba) which have 24-bits as their > > > "minimum addressable unit". So this means that the sizeof a char > > > (and an int and a short for that matter) is 24-bits. > > > > > > I quickly read the posted link WritingAnLLVMBackend.html but did not > > > see an obvious answer to the following question: > > > > > > Is it possible to write a backend that faithfully represents these > > > architectures or is sizeof_byte==8 bits baked into to llvm? > > > > > > Does anyone have any views on the above? > > > > > > thanks > > > Matthew Gardiner > > > > > > > > > On Tue, 9 Sep 2014 18:21:01 +1200 > > > Bruce Hoult <bruce at hoult.org> wrote: > > > > > > > http://llvm.org/docs/WritingAnLLVMBackend.html > > > > > > > > > > > > On Tue, Sep 9, 2014 at 6:09 PM, Prakash Premkumar > > > > <prakash.prax at gmail.com> wrote: > > > > > > > > > How does LLVM generate machine code for different architectures? > > > > > For example, the machine code for x86 and amd will vary. > > > > > > > > > > How does LLVM convert its IR to machine code for different > > > > > architectures.Can you please explain the approach? Is it just > > > > > write two different programs for two different architectures > > > > > and pass a flag to the compiler based on which machine code you > > > > > want to generate? > > > > > > > > > > Thanks a lot for your explanations. > > > > > > > > > > Thanks > > > > > Prakash > > > > > > > > > > _______________________________________________ > > > > > LLVM Developers mailing list > > > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > > > > > > > > > > > To report this email as spam click > > > > https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== . > > > > > > > > > > > > Member of the CSR plc group of companies. CSR plc registered in > > > England and Wales, registered number 4187346, registered office > > > Churchill House, Cambridge Business Park, Cowley Road, Cambridge, > > > CB4 0WZ, United Kingdom More information can be found at > > > www.csr.com. Keep up to date with CSR on our technical blog, > > > www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, > > > www.youtube.com/user/CSRplc, Facebook, > > > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter > > > at www.twitter.com/CSR_plc. New for 2014, you can now access the > > > wide range of products powered by aptX at www.aptx.com. > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev