Path: utzoo!attcan!uunet!mcsun!ukc!inmos!nathan@elberton.inmos.co.uk
From: nathan@elberton.inmos.co.uk (Nathan Sidwell)
Newsgroups: comp.sys.transputer
Subject: Re: 16-bit Integers
Message-ID: <9807@ganymede.inmos.co.uk>
Date: 20 Aug 90 11:01:23 GMT
References: <9008161656.AA09519@devvax.TN.CORNELL.EDU>
Sender: news@inmos.co.uk
Reply-To: nathan@inmos.co.uk (Nathan Sidwell)
Organization: INMOS Limited, Bristol, UK.
Lines: 31

In article <9008161656.AA09519@devvax.TN.CORNELL.EDU> koontz%capvax.decnet@CAPSRV.JHUAPL.EDU ("CAPVAX::KOONTZ") writes:
>You could also use it to access 16-bit values:
>     the lower 16-bits of data:  data.w BITAND #0xFFFF
>     the upper 16-bits of data:  (data.w BITAND #0xFFFF0000) >> 16
>                      OR
>                                 data.b[2] BITOR (data.b[3] << 8)
>
>The 16-bit accesses show the problem: using the higher 16-bits of data for
>storage requires logical operations and shifts.  The transputer is slow on 
>shifting (overhead time + 1 shift per clock cycle).  Also, getting that large 
>32-bit mask into the machine will require 7 prefix ops.  The individual byte 
>method only requires 8 shifts and an OR, but it will require 2 memory fetches.

If you're using OCCAM, (which I assume that you are from the syntax of the
examples) the upper 16 bits may be extracted by just a shift op, ie

upper.16 := data.w >> 16

as >> is a bitwise SHIFT (not rotate) operator,
it does not propagate the sign bit.

In c you could code it as

upper_16 = (unsigned)datw_w >> 16

I suppose you could argue that the compiler should spot this, but who knows
what they do?

Nathan Sidwell, INMOS Ltd, UK         JANET:    nathan@uk.co.inmos
Generic disclaimer applies            UUCP:     ukc!inmos!nathan
My indicision is final (I think)      INTERNET: nathan@inmos.com