llvm dev - Sep 2009 - [LLVMdev] [cfe-dev] thoughts about n-bit bytes for clang/llvm

I am trying to gauge how much interest there is in supporting non-8- 
bit byte targets.

Other than myself, Ken Dyck of ON Semiconductor has a 24-bit machine  
he is trying to support.   We have been working jointly on this but we  
are also both new to Clang and LLVM.    Although both of our  
processors are not mainstream,  Ken points out that Texas Instruments  
the C5000 series is also 16-bit architecture.  I played around with  
TI's development environment today, and sure enough, it is perfectly  
valid to do:

        char foo = 32000;

It would be fairly easy to go through the LLVM/Clang code and change  
8s to 16s, fork it, and be done with it.  But I hoped we could fix it  
in a more general way that would be useful to others.  As Mike Stump  
suggested would be the case, most of the places have been easy and  
straight-forward to fix as we stumbled over them one-by-one.

But some cases are not so easy (for me).  For example, in lib/VMCore/ 
Constants.cpp there are several places where (such as isString() )  
that make implicit assumptions about byte size being 8 bits.  I don't  
see a way of getting the target information in play there.  (If you  
know a way, please let me know!! ;-)  I am guessing, however, there  
might be a design change required to get the TargetData info.  Any  
ideas?  Add another argument?  LLVMContext/LLVMContextImpl does not  
seem to provide what I need.

Assuming all of this gets done, there is the important question about  
how it gets tested.  I have a target, but it probably is not of much  
interest to anyone else.  What would people think of having a dummy  
test target just for this purpose until C5000 or something else with  
non-8-bit-bytes becomes available?

Or, is this topic mostly uninteresting to people?   (In that case the  
private fork is looking better and better.)  The problem with this is  
that it cuts through a big swath of the code base (lots of little  
changes) so probably involves most of the code owners.  I think it is  
useful functionality but it might be because I am just being blinded  
by my own narrow set of requirements.

As always, thanks for your help and your time,

Ray

Hi Ray,

At DiBcom, our application specific processor is using 16-bits byte, and it
would definitely be of interest for us to have the support for n-bit bytes.

By using alignment restrictions, and adjusting the adresses' computations in
a few target specific places, we have been able to have it work in our own
specific case. But this is not clean, and most probably not portable to most
other targets.

Best regards,
--
Arnaud de Grandmaison

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Ray Fix
Sent: Thursday, September 24, 2009 1:16 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] [cfe-dev] thoughts about n-bit bytes for clang/llvm


I am trying to gauge how much interest there is in supporting non-8-
bit byte targets.

Other than myself, Ken Dyck of ON Semiconductor has a 24-bit machine
he is trying to support.   We have been working jointly on this but we
are also both new to Clang and LLVM.    Although both of our
processors are not mainstream,  Ken points out that Texas Instruments
the C5000 series is also 16-bit architecture.  I played around with
TI's development environment today, and sure enough, it is perfectly
valid to do:

        char foo = 32000;

It would be fairly easy to go through the LLVM/Clang code and change
8s to 16s, fork it, and be done with it.  But I hoped we could fix it
in a more general way that would be useful to others.  As Mike Stump
suggested would be the case, most of the places have been easy and
straight-forward to fix as we stumbled over them one-by-one.

But some cases are not so easy (for me).  For example, in lib/VMCore/
Constants.cpp there are several places where (such as isString() )
that make implicit assumptions about byte size being 8 bits.  I don't
see a way of getting the target information in play there.  (If you
know a way, please let me know!! ;-)  I am guessing, however, there
might be a design change required to get the TargetData info.  Any
ideas?  Add another argument?  LLVMContext/LLVMContextImpl does not
seem to provide what I need.

Assuming all of this gets done, there is the important question about
how it gets tested.  I have a target, but it probably is not of much
interest to anyone else.  What would people think of having a dummy
test target just for this purpose until C5000 or something else with
non-8-bit-bytes becomes available?

Or, is this topic mostly uninteresting to people?   (In that case the
private fork is looking better and better.)  The problem with this is
that it cuts through a big swath of the code base (lots of little
changes) so probably involves most of the code owners.  I think it is
useful functionality but it might be because I am just being blinded
by my own narrow set of requirements.

As always, thanks for your help and your time,

Ray
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Ray,
> I am trying to gauge how much interest there is in supporting non-8- 
> bit byte targets.
in LLVM talk, I guess what you are saying is that i8 is not a legal
type for your target?

Ciao,

Duncan.

On Sep 23, 2009, at 4:15 PM, Ray Fix wrote:
> I am trying to gauge how much interest there is in supporting non-8- 
> bit byte targets.
Not much would be my guess.  I'd recommend incrementally just sending  
in the patches.  Start simple (fix a few places) and then work up to  
larger and larger patches.

For example:

   unsigned getCharWidth() const { return 8; } // FIXME

is a great place to start for clang.
> It would be fairly easy to go through the LLVM/Clang code and change
> 8s to 16s, fork it, and be done with it.
Ah, but it hopefully isn't too much more work to change it to  
Target.getCharWidth() instead...
> Assuming all of this gets done, there is the important question about
> how it gets tested.
I wouldn't worry about testing.  In the end, you'll have your target  
and you'll test it.  For others, just don't change 8 to 16 and expect  
people not to pitch fork you.  :-)