[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Reducing opcode permutations

From: Sandro Magi
Subject: Re: [Lightning] Reducing opcode permutations
Date: Fri, 28 Mar 2008 12:16:55 -0400

On Wed, Mar 26, 2008 at 10:07 AM, Sandro Magi <address@hidden> wrote:
>  I'm looking at a "Synonyms" section now, and it says this:
>   For example, adding two unsigned integers is exactly the same as
>   adding two signed integers (assuming a two's complement
>   representation of negative numbers); yet, gnu lightning provides
>   both jit_addr_i and jit_addr_ui macros.
>  Two points:
>  1. This is the type of duplication I'd like to avoid, as it adds
>  unnecessary bloat to the C library (and to my cramped fingers!). This
>  isn't a problem for Lightning because macros have no runtime footprint
>  for unused instructions. The "Synonyms—don't define them" section is
>  quite long.
>  2. Something doesn't seem right about the above description. For
>  instance, a signed 32-bit number overflows at 2^31, not 2^32, so
>  addc_i and addc_ui should have different semantics. Also, 64-bit
>  systems which define a 32-bit int, but a 64-bit long int, similarly
>  overflow at different values for addc. Is this the actual behaviour?

>From my reading, the x86 'add' instruction provides overflow modes for
8/16/32 signed and unsigned integers [1]. Unless I'm reading it wrong,
PowerPC doesn't have the same semantics [2]. Given this instruction

// assumptions: 1. we're working on a 32-bit machine, 2. int is 32-bits
#include <limits.h>

jit_movi_i(JIT_R1, INT_MAX)     // R1 = 2^31
jit_addci_i(JIT_R0, JIT_R1, 1)   // R0 = R1 + 1, set carry
jit_addxi_i(JIT_R2, JIT_R0, 0)   // R2 = R0 + 0 + carry

So, does R2=1, or does R2=0? When using _ui, it should be 0. If it
were really signed arithmetic, it should be 1. How does Lightning
behave when this instruction sequence is executed on x86 and PPC?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]