<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.im
{mso-style-name:im;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="SV" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Tyro,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">You seems to suggest that one way to avoid the problem of implementing 16-bit bytes at the C level, would be to use 8-bit bytes instead. ;-) If
the target has 16 bits as the addressable unit of storage, then byte pointers would be implemented as “fat pointers”. Yes, this would probably be possible. But we haven’t tried it, both because of backward compatibility concerns (for legacy C code), and because
of the performance implications that you point out. (Our target also have 16-bit registers dedicated for pointers.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/Patrik Hägglund<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Tyro Software [mailto:softwaretyro@gmail.com]
<br>
<b>Sent:</b> den 17 mars 2015 12:11<br>
<b>To:</b> Patrik Hägglund H<br>
<b>Cc:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] n-bit bytes for clang/llvm<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">As an alternative to fixing the "char == 8 bits" presumption would using non-uniform pointer types have been another possible approach, e.g. keep char as 8 bit but have char* encode both the word address and the byte location within it
(i.e. one extra bit in this 16-bit case). Of course this is only a less intrusive (to LLVM) approach if LLVM readily supports such pointers, which may be close to asking "could 8086 small/large/huge pointers be implemented?" <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One obvious drawback to such an approach is that dereferencing char* becomes relatively expensive, though for the sort of code being predominantly run on a DSP that might be acceptable. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Mar 11, 2015 at 9:37 AM, Patrik Hägglund H <<a href="mailto:patrik.h.hagglund@ericsson.com" target="_blank">patrik.h.hagglund@ericsson.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">> It's definitely doable, but I'd be worried about the maintenance burden.<br>
<br>
Yes, that is a problem.<br>
<br>
We are currently not allowed to reveal our target (which has 16-bit bytes, and registers with non-power-of-two bit widths) fully, and therefore not able to submit it upstream. One idea we have toyed with is to create a simple "dummy" version of our target,
just to be able complement patches with tests. For 16-bit byte support we may also pick some existing simple architecture, such as DCPU-16 or TI C54x. One other idea is just to have the changes on a branch upstream.<br>
<br>
/Patrik Hägglund<br>
<br>
From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On Behalf Of Reid Kleckner<br>
Sent: den 10 mars 2015 17:09<br>
To: Tyro Software<br>
Cc: LLVM Developers Mailing List<br>
<span class="im">Subject: Re: [LLVMdev] n-bit bytes for clang/llvm</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">It's definitely doable, but I'd be worried about the maintenance burden. Beyond contributing the initial patches, I'd want to see a maintenance commitment and relatively comprehensive tests that can be run upstream.<br>
<br>
For example, if there were an i24 MVT, how would I test my target independent SDAG change that operates on all integer values? Currently, our answer to that question is "find a backend that uses it and test that". Without such a backend, it's hard for us to
promise that this support will continue to work.<br>
<br>
On Tue, Mar 10, 2015 at 3:12 AM, Tyro Software <<a href="mailto:softwaretyro@gmail.com">softwaretyro@gmail.com</a>> wrote:<br>
Back in 2009 there was some discussion of the practicality of supporting char sizes greater than 8-bit:<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-September/thread.html#6349</a><br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/thread.html#26025</a><br>
<br>
with the consensus seemingly being "quite doable, please get a good patch and submit".<br>
<br>
However the current code appears (to my neophyte eyes) to be explicitly 8-bit, e.g. one instance called out in the mail thread remains:<br>
<br>
/// isString - This method returns true if this is an array of i8.<br>
bool ConstantDataSequential::isString() const {<br>
return isa<ArrayType>(getType()) && getElementType()->isIntegerTy(8);<br>
}<br>
<br>
I didn't find anything related beyond this mail thread such as a discussion of a patch but of course I might be searching too narrowly - perhaps someone here can recall whether it went any further, whether insurmountable barriers do exist, etc?<br>
<br>
Thanks for whatever advice & thread necromancy you can offer,<br>
Tyro<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>