<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:214395620;
mso-list-template-ids:-33793936;}
@list l1
{mso-list-id:1752000389;
mso-list-template-ids:1450068578;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Oh, I wasn’t really thinking about devices without an MMU where the addresses are physically separated. Makes sense.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This reminds me of rwpi on ARM; it has a sort of similar scheme of referring to data indirectly through a pointer, but it also changes the ABI to keep the pointer in a reserved register.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Eli<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Evandro Menezes <evandro.menezes@sifive.com> <br>
<b>Sent:</b> Friday, March 20, 2020 12:28 PM<br>
<b>To:</b> Eli Friedman <efriedma@quicinc.com><br>
<b>Cc:</b> Alex Bradbury <asb@lowrisc.org>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] Re: [llvm-dev] RISC-V LLVM sync-up call 19 Mar 2020<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi, Eli.<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">If I’m following correctly, there are two size-limited areas. One area, limited to 2GB, is the “text” area. This contains all the code. Then there’s a “global” area, limited to 4GB, which is pointed to by the global pointer. This contains
the GOT, plus a flexible area that the object file can stick small bits of data into. And then outside of both of those, additional data is unlimited.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Actually, the global data area, which includes the GOT and any global of local scope, is limited to 4GiB. However, the latter is limited to 2GiB, in order to guarantee addressing the GOT and the small data area, assuming this section order:<o:p></o:p></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
.got<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
.sdata .sbss<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo1">
.ldata .lbss<o:p></o:p></li></ol>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The .data and .bss sections, containing the globals of global scope, may follow these immediately, but can actually be placed anywhere in the memory map.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">It took me multiple times reading through the proposal to parse that out; it might be a good idea to reorganize the proposal so that’s explained somewhere explicitly.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Will do.<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">My big question here is, how much benefit are you really getting from having a global pointer? If you eliminate it and combine the two size-limited areas into one, you end up with essentially the small-PIC code model. The small-PIC code
model supports everything your proposed “compact” model does, with a couple minor differences:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l0 level1 lfo2">
The size-limited areas are limited to 2GB combined, instead of 6GB combined.<o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l0 level1 lfo2">
The relaxations are a little different. Small-PIC always takes two instructions to access a GOT entry; the compact model can do it in one instruction for the first 500 (?) entries in the GOT. Not sure what would end up with smaller codesize in practice.<o:p></o:p></li></ol>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">This code model addresses the cases when code and data reside in different memory devices and at distant addresses. Sometimes, RAM is faster than ROM and it's not desirable to have even read only data in ROM. Besides the obvious case
of addressing, say, a peripheral buffer in a distant memory location. But the scheme above would not allow code and data to reside in different memory devices, if the user so prefers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the other hand, just like we have the code models `medlow` and `medany`, we could have two variations of the compact code model too. One assuming that code and small data and local data are on the same memory device (`cmplow`) and another
assuming no such restriction (`cmpany`).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thank you,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">__ <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Evandro Menezes ◊ SiFive ◊ Austin, TX<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b>From:</b><span class="apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>><span class="apple-converted-space"> </span><b>On Behalf Of<span class="apple-converted-space"> </span></b>Evandro
Menezes via llvm-dev<br>
<b>Sent:</b><span class="apple-converted-space"> </span>Thursday, March 19, 2020 9:19 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>Alex Bradbury <<a href="mailto:asb@lowrisc.org">asb@lowrisc.org</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>[EXT] Re: [llvm-dev] RISC-V LLVM sync-up call 19 Mar 2020<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Here's the draft proposal for the compact code model on RV. I'd appreciate your feedback before I propose it to the foundation and go about updating the psABI.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Thank you,<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">__ <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Evandro Menezes ◊ SiFive ◊ Austin, TX<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Mar 19, 2020, at 8:58, Alex Bradbury via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">For background on these calls, see<br>
<<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html">http://lists.llvm.org/pipermail/llvm-dev/2019-September/135087.html</a>>.<br>
<br>
Reminder: the purpose is to co-ordinate between active contributors.<br>
If you have support questions etc then it's best to post to llvm-dev.<br>
<br>
We have a call each Thursday at 4pm GMT, via<br>
<<a href="https://meet.google.com/ske-zcog-spp">https://meet.google.com/ske-zcog-spp</a>>.<br>
<br>
I've created a shared calendar which may help in keeping track, which<br>
is accessible at:<br>
* <<a href="https://calendar.google.com/calendar/b/1?cid=bG93cmlzYy5vcmdfMG41cGtlc2ZqY25wMGJoNWhwczFwMGJkODBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ">https://calendar.google.com/calendar/b/1?cid=bG93cmlzYy5vcmdfMG41cGtlc2ZqY25wMGJoNWhwczFwMGJkODBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ</a>><br>
* <<a href="https://calendar.google.com/calendar/ical/lowrisc.org_0n5pkesfjcnp0bh5hps1p0bd80%40group.calendar.google.com/public/basic.ics">https://calendar.google.com/calendar/ical/lowrisc.org_0n5pkesfjcnp0bh5hps1p0bd80%40group.calendar.google.com/public/basic.ics</a>><br>
<br>
Issues to discuss today include the following:<br>
* Improving rust code size by not forcing frame pointers<br>
<<a href="https://github.com/rust-lang/rust/pull/69890">https://github.com/rust-lang/rust/pull/69890</a>><br>
* Compact code model (Evandro)<br>
* Update on embedded PIC discussions<br>
* Small data limit <<a href="https://reviews.llvm.org/D57497">https://reviews.llvm.org/D57497</a>><br>
* Bitmanip / experimental extension status<br>
* ELF attribute support close to merging<br>
<<a href="https://reviews.llvm.org/D75833">https://reviews.llvm.org/D75833</a>> <<a href="https://reviews.llvm.org/D74023">https://reviews.llvm.org/D74023</a>><br>
* No other topics were submitted, as always, please do submit things<br>
you'd like to discuss<br>
<br>
Best,<br>
<br>
Alex<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>