Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Date: Wed, 22 Oct 2014 08:52:49 -0400 Organization: A noiseless patient Spider Lines: 57 Message-ID: References: <6c324a98-b16e-4904-b014-c53fd799cb1b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 22 Oct 2014 12:52:48 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="bd4e1cba8d8592bec5d5ed9e4537fbfd"; logging-data="16824"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+T8aksi+G1VVxTPJ4ByGCP" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: Cancel-Lock: sha1:0TZO9RomaDcoxZ0l89lAaWJpd7Q= Xref: csiph.com comp.lang.java.programmer:30155 On 10/22/2014 2:42 AM, ĵess stone wrote: > In article m25kdv$tou$1@dont-email.me, Eric Sosman said... > >> On 10/21/2014 5:22 AM, ĵess stone wrote: >>> >>> Well, this *is* the language whose designers had the absolutely >>> *brilliant* idea of making the only byte-sized data type signed. And >>> prone to being auto-promoted to int. >> >> I'll agree that making `byte' signed was a regrettable choice, >> but what do you find repugnant about promoting it to `int'? (And do you >> have a similar objection to promoting `short'?) > > The problem is mainly the interaction with that and the signedness of > bytes. So you end up with binary 11001001 turning into > 10000000000000000000000001001001 Um, er, no. > and when you later truncate or mask off > the high bytes you wind up with 01001001, which is wrong. If promotion produced the result you predict, masking would indeed produce the wrong answer you show. But promotion doesn't behave as you say, and the masked value is in fact the original 11001001. > So you have to > watch that you don't lose the high bit when something causes auto- > promotion. And it's tricky, because it can happen even if you have a > computation "entirely in bytes", i.e. nothing but bytes in and assignment > to a parameter or local of byte size. Assignment does not promote, so the trickiness level is zero. > [...] Ultimately, this stems from treating bytes mainly as really small > integers, assuming you'll mainly use them to do arithmetic with wider > types and will want wide output, when in reality bytes are mainly used > for fiddling with binary data at a low level. Ultimately, the need for promotion arises from the inability of most computers nowadays to do arithmetic on narrow integers. CPU's tend to lack 8-bit registers, so loading an 8-bit quantity into a wider register has to do *something* with the rest of the register's bits. The principal choices at the hardware level are to leave the remaining bits alone, to sign-extend, or to zero-extend (I've seen all three, at one time or another), but simply vaporizing the other bits isn't an option. Some machines can do a limited amount of special-purpose arithmetic on memory-resident operands (atomic increment, compare-and-swap, that sort of thing), but the CPU's full repertoire of arithmetic operations is usually only available for register-resident values. If you want to do arithmetic on a `byte' or a `short' with a 32- or 64-bit register, you cannot avoid the need for promotion. -- esosman@comcast-dot-net.invalid