Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #30155

Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi]

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 <esosman@comcast-dot-net.invalid>
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 <m289av$gdo$1@dont-email.me> (permalink)
References <6c324a98-b16e-4904-b014-c53fd799cb1b@googlegroups.com> <m23g28$85a$1@speranza.aioe.org> <ccc4a51a-31ee-4099-9c63-0cc2a76c6dbc@googlegroups.com> <m258kt$7t0$1@speranza.aioe.org> <m25kdv$tou$1@dont-email.me> <m27jk3$shk$1@speranza.aioe.org>
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 <m27jk3$shk$1@speranza.aioe.org>
Cancel-Lock sha1:0TZO9RomaDcoxZ0l89lAaWJpd7Q=
Xref csiph.com comp.lang.java.programmer:30155

Show key headers only | View raw


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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-20 01:28 -0700
  Re: Driving 7-Segment LEDs on Raspberry Pi Gordon Levi <gordon@address.invalid> - 2014-10-21 01:42 +1100
    Re: Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-24 05:20 -0700
      Re: Driving 7-Segment LEDs on Raspberry Pi Arne Vajhøj <arne@vajhoej.dk> - 2014-10-24 21:37 -0400
  Re: Driving 7-Segment LEDs on Raspberry Pi ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-20 17:16 +0000
    Re: Driving 7-Segment LEDs on Raspberry Pi javalaurence@gmail.com - 2014-10-21 00:09 -0700
      Re: Driving 7-Segment LEDs on Raspberry Pi ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-21 09:22 +0000
        Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-21 08:43 -0400
          Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 06:42 +0000
            Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-10-22 08:02 +0000
              Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 10:49 +0000
            Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-22 08:52 -0400
              Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] ĵess stone <j3ss.st0n3@gmail.com> - 2014-10-22 14:00 +0000
                Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-22 10:43 -0400
                Re: Bytes [Was: Re: Driving 7-Segment LEDs on Raspberry Pi] thinbluernime <thinbluernime3@gmail.com> - 2014-10-22 16:34 +0000

csiph-web