Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu]
Sent: Friday, April 15, 2022 2:59 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
>
> ... it's obvious that if you want
> to rotate right, s
: Friday, April 15, 2022 12:00 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
>
> ... it's obvious that if you want
> to rotate right, say 5 bits, you can instead rotate left 59 bits ...
>
Perfor
On Fri, 15 Apr 2022 at 14:59, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
> >
> > ... it's obvious that if you want
> > to rotate right, say 5 bits, you can instead rotate left 59 bits ...
> >
> Performance?
On Apr 15, 2022, at 12:47:40, Tony Harminc wrote:
>
> ... it's obvious that if you want
> to rotate right, say 5 bits, you can instead rotate left 59 bits ...
>
Performance? Does the timing depend on the distance shifted?
Maybe model-dependedent. How much does it matter?
--
gil
On Fri, 15 Apr 2022 at 03:06, Ian Worthington
<0c9b78d54aea-dmarc-requ...@listserv.uga.edu> wrote:
>
> Thanks Seymour, it had never occurred to me they were totally identical apart
> from CC and sign extension. I'd always had a suspicion that there might be
> something that happened at the
@LISTSERV.UGA.EDU] on behalf
of Ian Worthington [0c9b78d54aea-dmarc-requ...@listserv.uga.edu]
Sent: Friday, April 15, 2022 2:38 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
Is this maybe because the variables are declared as static?
In the case of:
void addStuff(__uint64_t
]
Sent: Friday, April 15, 2022 3:02 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
Both signed and unsigned integer operations are required to either wrap or give
undefined results in C. To my mind this is a horrible problem which gets
kicked down the road
]
Sent: Thursday, April 14, 2022 9:04 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Signed/unsigned operations
I noticed today that GCC generates for:
static __uint32_t sumu32; // unsigned int
static __uint64_t sumu64; // unsigned long
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32
Both signed and unsigned integer operations are required to either wrap or give
undefined results in C. To my mind this is a horrible problem which gets
kicked down the road by the expansion of the size of variable size every few
years, presumably accompanies by the sacrificing of farmyard
, April 14, 2022 08:05
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Signed/unsigned operations
I noticed today that GCC generates for:
static __uint32_t sumu32; // unsigned int static __uint64_t sumu64; //
unsigned long
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32, __uint32_t b32
In situations where reentrancy is not necessary, maintaining code and
data in separate adjacent areas each on cache boundaries and sizes a
multiple of cache line length, these instructions may be very useful.
And perhaps there are enough critical kernel code paths protected by
locks for which
On Thu, 14 Apr 2022 at 12:29, Ngan, Robert (DXC Luxoft)
wrote:
>
> STRL/STGRLl?
> Is the GCC compiler generating non-reentrant code?
I've wondered why these relatively (heh...) recent instructions exist
in the architecture at all. (There is also STHRL.)
Certainly they appeared long after it
, 2022 12:08 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
STRL/STGRLl?
Is the GCC compiler generating non-reentrant code?
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Ian Worthington
Sent: Thursday, April 14
STRL/STGRLl?
Is the GCC compiler generating non-reentrant code?
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Ian Worthington
Sent: Thursday, April 14, 2022 08:05
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Signed/unsigned operations
I
On Apr 14, 2022, at 09:21:28, Robin Vowels wrote:
>
> On 2022-04-15 00:31, Seymour J Metz wrote:
>> The S/360 architecture uses two's complement arithmetic, and that
>> remains the case through z. Accordingly, signed and unsigned
>> arithmetic are the same except for the condition code, except
of Robin Vowels [robi...@dodo.com.au]
Sent: Thursday, April 14, 2022 11:21 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Signed/unsigned operations
On 2022-04-15 00:31, Seymour J Metz wrote:
> The S/360 architecture uses two's complement arithmetic, and that
> remains the case thr
On 2022-04-15 00:31, Seymour J Metz wrote:
The S/360 architecture uses two's complement arithmetic, and that
remains the case through z. Accordingly, signed and unsigned
arithmetic are the same except for the condition code, except when
sign extension is an issue, e.g., adding a word to a grande
Subject: Signed/unsigned operations
I noticed today that GCC generates for:
static __uint32_t sumu32; // unsigned int
static __uint64_t sumu64; // unsigned long
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32, __uint32_t b32 ) {
sumu32 = a32 + b32;
sumu64 = a64 + b64
I noticed today that GCC generates for:
static __uint32_t sumu32; // unsigned int
static __uint64_t sumu64; // unsigned long
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32, __uint32_t b32 ) {
sumu32 = a32 + b32;
sumu64 = a64 + b64;
}
the following:
117: sumu32 =
19 matches
Mail list logo
