I have a target that supports a "push.b x" operation that puts a byte onto
the stack but pre-decrements the stack pointer by 2 to maintain alignment.
I have a machine description that includes these two defines:
(define_insn "*pushqi_pre_mod"
[(set (mem:QI (pre_modify:HI (reg:HI 1)
On Tue, Apr 5, 2011 at 2:35 AM, Andreas Schwab wrote:
> Peter Bigot writes:
>
>> I have a target that supports a "push.b x" operation that puts a byte onto
>> the stack but pre-decrements the stack pointer by 2 to maintain alignment.
>
> That looks li
I'm updating the machine description for a 16-bit microcontroller, and am
trying to eliminate some hand-coded SImode and DImode insns because in
general gcc generates better code automatically. So far, I've found no case
where I seem to need to implement cbranchsi4 or cbranchdi4.
However, gcc doe
On Tue, Jul 26, 2011 at 6:31 PM, joseph at codesourcery dot com
wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858
>
> --- Comment #1 from joseph at codesourcery dot com dot com> 2011-07-26 23:31:27 UTC ---
> On Tue, 26 Jul 2011, bigotp at acm dot org wrote:
>
> > Is there a mechanism b
2011/7/29 Daniel Marjamäki :
> Hello!
>
>> Why doesn't it matter in this case but it matters when the initializer
>> are non-constant?
>
> It doesn't matter because the program will behave the same no matter
> if the initializations are reordered or not. Logically it will behave
> just as the user
On Sun, Aug 21, 2011 at 12:01 PM, Georg-Johann Lay wrote:
>
> Richard Sandiford schrieb:
>>
>> Georg-Johann Lay writes:
>>
>>> Richard Sandiford schrieb:
>>>
I've been working on some patches to make insn_rtx_cost take account
of the cost of SET_DESTs as well as SET_SRCs. But I'm slowl
In the msp430 back end, hard registers 4 through 15 are HImode, with
adjacent register sequences used for SImode and DImode. In preparation for
a library call, I'm emitting RTL that assigns values directly to reg:SI 4.
Despite that, in gcc 4.5.x IRA choses reg:HI 4 as the destination
for a pseudo
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote:
> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>
>> In the msp430 back end, hard registers 4 through 15 are HImode, with
>> adjacent register sequences used for SImode and DImode. In preparation
>> for
>>
On Thu, Sep 15, 2011 at 4:09 PM, Vladimir Makarov wrote:
> On 09/15/2011 03:06 PM, Peter Bigot wrote:
>>
>> On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov
>> wrote:
>>>
>>> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>>>
>>>>
On Thu, Sep 15, 2011 at 10:34 AM, Vladimir Makarov wrote:
> On 09/15/2011 11:16 AM, Peter Bigot wrote:
>>
>> In the msp430 back end, hard registers 4 through 15 are HImode, with
>> adjacent register sequences used for SImode and DImode. In preparation
>> for
>>
On Fri, Oct 21, 2011 at 4:41 PM, Richard Henderson wrote:
> On 10/21/2011 10:15 AM, Paulo J. Matos wrote:
>> So I have implemented the nadd and addc as:
>>
>> (define_insn "negqi2"
>> [(set (match_operand:QI 0 "register_operand" "=c")
>> (neg:QI (match_operand:QI 1 "register_operand" "0"
I'm rewriting a back-end originally based on AVR to eliminate insns for
multi-word operations (output templates like "add\;addc") and to use MODE_CC
instead of an unusual attribute-based approach. The motivation is that I've
mostly found gcc does a better job than the existing back-end if it's sho
On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson wrote:
> On 10/28/2011 06:49 AM, Peter Bigot wrote:
>> I'm inclined to follow sparc's lead, but is one or another of the choices
>> more likely to help combine/reload/etc do a better job?
>
> I don't know.
&
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
> On 10/29/2011 05:41 AM, Peter Bigot wrote:
>> It seems cc0 should probably still be preferred for CISC-style
>> architectures like the MSP430. I'll give that approach a try.
>
> I think that's somewhat un
On Fri, Dec 2, 2011 at 5:46 AM, wrote:
>
> ...
> >> It's never correct to exchange volatile accesses.
> >
> >That's not true. volatile accesses to different memory locations
> >have no special dependence. If it happens that GCC doesn't
> >do this kind of things then this is only because most pas
On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn wrote:
> On 01/12/2011 21:40, Georg-Johann Lay wrote:
>
>> It's not unusual because:
>>
>> * It's not unusual to write down SFRs as violatile memory like
>> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite
>> that reflects the SFRs bit(
I'm enhancing the out-of-tree msp430 back end to support the 20-bit
extended registers of the 430X CPU. I'd like to do this using a
native type rather than special-casing its use in addresses. It seems
the best approach is to use PSImode, since the values are 20 bits when
in a register, and 32 bi
On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt wrote:
> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>> And is there any reason (other than it doesn't seem to have been done
>> before) to believe PSImode is the wrong way to support a
>> general-purpose 20-bit integral
On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt wrote:
> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>> And is there any reason (other than it doesn't seem to have been done
>> before) to believe PSImode is the wrong way to support a
>> general-purpose 20-bit integral
On Wed, Apr 11, 2012 at 11:18 AM, Ian Lance Taylor wrote:
> Andrew Haley writes:
>
>> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>>
>>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>>> which did not cause a warning on older gcc version now gives a
>>> warning. I would no
On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt wrote:
> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>> And is there any reason (other than it doesn't seem to have been done
>> before) to believe PSImode is the wrong way to support a
>> general-purpose 20-bit integral
On Wed, Apr 11, 2012 at 11:55 AM, Bernd Schmidt wrote:
> On 04/11/2012 06:53 PM, Peter Bigot wrote:
>> On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt
>> wrote:
>>> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>>>> And is there any reason (other than it doesn&
(Resent to right list.)
I'm maintaining an out-of-tree back-end (Texas Instruments MSP430)
based on years of contributions from a variety of people, affecting
binutils, gcc, and gdb. Whether it can ever be merged (some of the
original contributors have disappeared), I'd like an assignment form
fo
I've run into another issue supporting a 20-bit integer for which I'd
appreciate a hint. With this code:
typedef long int __attribute__((__a20__)) int20_t;
int20_t xi;
int20_t addit () { xi += 0x54321L; }
xi ends up in mode PSImode, which is a MODE_PARTIAL_INT with 20 bits of
precision and
On Tue, Apr 24, 2012 at 9:01 AM, Richard Guenther
wrote:
> On Tue, Apr 24, 2012 at 3:50 PM, Peter Bigot wrote:
>> I've run into another issue supporting a 20-bit integer for which I'd
>> appreciate a hint. With this code:
>>
>> typedef long int __attribu
On Fri, Apr 27, 2012 at 4:29 AM, Georg-Johann Lay wrote:
> Richard Guenther wrote:
>> [PR c/51527]
>>
>> I think the fix would be sth like
>>
>> Index: gcc/convert.c
>> ===
>> --- gcc/convert.c (revision 186871)
>> +++ gcc/conve
The MSP430's split address space and ISA make it expensive to place
data above the 64 kB boundary, but cheap to place code there. So I'm
looking for a way to use HImode for data pointers, but PSImode for
function pointers. If gcc supports this, it's not obvious how.
I get partway there with FUNC
On Sun, Apr 29, 2012 at 7:51 AM, Georg-Johann Lay wrote:
> Peter Bigot a écrit:
>
>> The MSP430's split address space and ISA make it expensive to place
>> data above the 64 kB boundary, but cheap to place code there. So I'm
>> looking for a way to use HImode
On Mon, Apr 30, 2012 at 4:50 AM, Robert Dewar wrote:
> On 4/30/2012 4:16 AM, Paulo J. Matos wrote:
>>
>> Peter,
>>
>> We have a working backend for an Harvard Architecture chip where
>> function pointer and data pointers have necessarily different sizes. We
>> couldn't do this without changing GCC
On Wed, May 2, 2012 at 8:08 AM, Paulo J. Matos wrote:
> On 30/04/12 13:01, Peter Bigot wrote:
>>
>> I would like to see the technical details, if your code is released
>> somewhere.
>>
>
> Hi Peter,
>
> Sorry for the delay.
> The code is not released,
On Mon, May 7, 2012 at 6:08 AM, Christian Bruel wrote:
>
>
> On 05/07/2012 12:09 PM, Joseph S. Myers wrote:
>> On Mon, 7 May 2012, Christian Bruel wrote:
>>
>>> Making the driver aware about all possible user defined options seems
>>> unpredictable. Was there any justification on removing this
>>>
Over the last couple months I've been updating an out-of-tree back end for
the TI MSP430 to support 20-bit functionality. This is a 16-bit
microcontroller, where certain MCUs support 20-bit address and integer
operations with an extended ISA and registers that can hold slightly more
than one word.
I'm running into issues with the MSP430 and use of PSImode in packed
structures. Here the native word size is HImode, but all general purpose
registers are capable of holding and operating on PSImode (=20 bit) values.
Due to instruction set limitations, on this architecture:
(subreg:HI (reg:PS
33 matches
Mail list logo
