Tim Northover via llvm-dev
2019-May-06 09:43 UTC
[llvm-dev] RFC: On removing magic numbers assuming 8-bit bytes
On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Although the above is mentioning bytes, looking at the "/ 8" and "& 0x7" makes it look like the author meant octets and not bytes. > Bytes can be any size of bits.I don't think you'll have much luck trying to make that stick for a general audience, or even a general compiler-writer audience. Byte is far too strongly associated with 8 bits these days.> Octets are only ever 8 bits.You might be able to convert all uses of byte to octet and abandon byte entirely, but at that point why bother? It feels like a change just for the sake of pedantry. I like the "addressable unit" name, though it's a bit long (AddrUnit seems OK). It at least signals to a reader that there might be something weird going on. Getting someone writing new code to think in those terms is a different matter, of course, but I don't think any of the changes under discussion really help there. BTW, is there an open source backend (in a fork, I assume) that does this? So that we can get some kind of idea of the real scope of the changes needed. Cheers. Tim.
Philip Reames via llvm-dev
2019-May-06 22:56 UTC
[llvm-dev] RFC: On removing magic numbers assuming 8-bit bytes
On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote:> On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Although the above is mentioning bytes, looking at the "/ 8" and "& 0x7" makes it look like the author meant octets and not bytes. >> Bytes can be any size of bits. > I don't think you'll have much luck trying to make that stick for a > general audience, or even a general compiler-writer audience. Byte is > far too strongly associated with 8 bits these days.+1 Please don't try; insisting on a distinction will confuse many new contributors.> >> Octets are only ever 8 bits. > You might be able to convert all uses of byte to octet and abandon > byte entirely, but at that point why bother? It feels like a change > just for the sake of pedantry. > > I like the "addressable unit" name, though it's a bit long (AddrUnit > seems OK). It at least signals to a reader that there might be > something weird going on. Getting someone writing new code to think in > those terms is a different matter, of course, but I don't think any of > the changes under discussion really help there. > > BTW, is there an open source backend (in a fork, I assume) that does > this? So that we can get some kind of idea of the real scope of the > changes needed.Strongly agreed. My personal take is this is an invasive enough change with enough likely ongoing maintenance fall out to require substantial justification before the work was undertaken upstream. A open source backend proposed for inclusion upstream would be one part of that. Active contribution from the sponsors in other areas would also be a key factor.> > Cheers. > > Tim. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Jesper Antonsson via llvm-dev
2019-May-08 08:04 UTC
[llvm-dev] RFC: On removing magic numbers assuming 8-bit bytes
On Mon, 2019-05-06 at 10:43 +0100, Tim Northover wrote:> On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Although the above is mentioning bytes, looking at the "/ 8" and > > "& 0x7" makes it look like the author meant octets and not bytes. > > Bytes can be any size of bits. > > I don't think you'll have much luck trying to make that stick for a > general audience, or even a general compiler-writer audience. Byte is > far too strongly associated with 8 bits these days. > > > Octets are only ever 8 bits. > > You might be able to convert all uses of byte to octet and abandon > byte entirely, but at that point why bother? It feels like a change > just for the sake of pedantry. > > I like the "addressable unit" name, though it's a bit long (AddrUnit > seems OK). It at least signals to a reader that there might be > something weird going on. Getting someone writing new code to think > in > those terms is a different matter, of course, but I don't think any > of > the changes under discussion really help there. > > BTW, is there an open source backend (in a fork, I assume) that does > this? So that we can get some kind of idea of the real scope of the > changes needed.Unfortunately, there is not AFAIK. If you like, we can try to expand on the showcase patch to show more, but the changes are numerous enough to make it difficult to assemble something that will show it all. Thanks, Jesper> > Cheers. > > Tim.
Jesper Antonsson via llvm-dev
2019-May-08 08:25 UTC
[llvm-dev] RFC: On removing magic numbers assuming 8-bit bytes
On Mon, 2019-05-06 at 15:56 -0700, Philip Reames via llvm-dev wrote:> >> On 5/6/19 2:43 AM, Tim Northover via llvm-dev wrote: > > On Mon, 6 May 2019 at 10:13, James Courtier-Dutton via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > Although the above is mentioning bytes, looking at the "/ > > > 8" and "& 0x7" makes it look like the author meant octets and > > > not bytes. > > > Bytes can be any size of bits. > > > > I don't think you'll have much luck trying to make that stick for a > > general audience, or even a general compiler-writer audience. Byte > > is > > far too strongly associated with 8 bits these days. > > +1 Please don't try; insisting on a distinction will confuse many new > contributors.Yes, my interpretation is that the community is leaning toward addressable unit as terminology.> > > Octets are only ever 8 bits. > > > > You might be able to convert all uses of byte to octet and abandon > > byte entirely, but at that point why bother? It feels like a change > > just for the sake of pedantry. > > > > I like the "addressable unit" name, though it's a bit long > > (AddrUnit > > seems OK). It at least signals to a reader that there might be > > something weird going on. Getting someone writing new code to think > > in > > those terms is a different matter, of course, but I don't think any > > of > > the changes under discussion really help there. > > > > BTW, is there an open source backend (in a fork, I assume) that > > does > > this? So that we can get some kind of idea of the real scope of the > > changes needed. > > Strongly agreed. > > My personal take is this is an invasive enough change with enough > likely > ongoing maintenance fall out to require substantial justification > before > the work was undertaken upstream.My hope and belief is that having good names instead of these magical numbers won't be a burden but rather an improvement long-term.> A open source backend proposed for > inclusion upstream would be one part of that.That is not on the table right now. However, as the work required to make such an inclusion happen will be reduced by this cleanup, the likelihood that it happens in the future should increase.> Active contribution from > the sponsors in other areas would also be a key factor.I'm not sure how to interpret that, but our team here at Ericsson is fairly large, we have been working with this out-of-tree backend since 2011 and as a group, we contribute to upstream e.g. by helping out with the fixedpoint upstreaming, by solving and filing TRs (we're pretty good at testing I'd say), improving debug information and more.> > > > > Cheers. > > > > Tim. > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reasonably Related Threads
- RFC: On removing magic numbers assuming 8-bit bytes
- RFC: On removing magic numbers assuming 8-bit bytes
- RFC: On removing magic numbers assuming 8-bit bytes
- RFC: On removing magic numbers assuming 8-bit bytes
- RFC: On removing magic numbers assuming 8-bit bytes