Hans-Peter Nilsson wrote:
> On Thu, 16 Feb 2006, Sylvain Munaut wrote:
>
>>Move/Load/Store without flag is no problem. But for add, to allow
>>multiword add, carry is needed and I can't make it optionnal.
>
>
> As I hinted, perhaps you can have the multiword carry a separate
> one from the flags
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> Move/Load/Store without flag is no problem. But for add, to allow
> multiword add, carry is needed and I can't make it optionnal.
As I hinted, perhaps you can have the multiword carry a separate
one from the flags carry, perhaps moved over with a separa
Hans-Peter Nilsson wrote:
> On Wed, 15 Feb 2006, DJ Delorie wrote:
> I wrote:
>
>>>Anyway, at least keep a way to add reg+reg and reg+integer, load and
>>>store of memory and load of integer and address without condition
>>>code effects and your port has a chance to avoid the related bloat.
>>
>
On Wed, 15 Feb 2006, DJ Delorie wrote:
I wrote:
> > Anyway, at least keep a way to add reg+reg and reg+integer, load and
> > store of memory and load of integer and address without condition
> > code effects and your port has a chance to avoid the related bloat.
>
> At least, move/load/store shou
> I see, in the code in svn trunk the compares aren't optimized away
> yet. You must be having a lot of fun right now. ;-)
*That* is an understatement. Unfortunately, reload hates me (see
archives for that thread) so I can't commit anything yet.
> Unless I'm delirious (it's way past bedtime) I see a m32c port
> and it's cc0-free. Is there a problem?
m32c has a separate $flg register defined, not a cc0 port.
Hence, this pattern:
(define_insn_and_split "cbranch4"
[(set (pc) (if_then_else
(match_operator 0 "m32c_cmp_operat
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> Unless I'm delirious (it's way past bedtime) I see a m32c port
> and it's cc0-free. Is there a problem?
I see, in the code in svn trunk the compares aren't optimized
away yet. You must be having a lot of fun right now. ;-)
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> I hope I can stick with my cmp/jmp model and manage them myself still,
> though, because there's a LOT of patterns in m32c where the set of
> flags affected depends on which alternative you select, and most
> patterns affect the flags in some (usually nonort
> ...and cbranch (cc setter + user in one combined insn) which are
> split after reload.
I have the cbranch and split, but allow it before reload. So far that
hasn't been a problem, although I split it only to delete the cmp if I
can.
> No "unless" here. You either have a clobber or a set in a parallel
> with the main feature, and you lose out on all the
> single_set-directed optimizations if you put in a "set" early.
"Oh, crap"
I hope I can stick with my cmp/jmp model and manage them myself still,
though, because there's a
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote:
> FWIW, I use
> peephole2s and condition code modes in CRIS w.i.p.
...and cbranch (cc setter + user in one combined insn) which
are split after reload.
brgds, H-P
On Wed, 15 Feb 2006, DJ Delorie wrote:
> > BTW, carry-out from shifts is very rarely used in compiled code.)
> Unless you've expanded SI shifts into a pair of HI shifts.
>
> > Besides what DJ said about performance (both pros and cons
> > there), the problem is as I said with port complexity, becau
> BTW, carry-out from shifts is very rarely used in compiled code.)
Unless you've expanded SI shifts into a pair of HI shifts.
> Besides what DJ said about performance (both pros and cons
> there), the problem is as I said with port complexity, because
> of the way you have to handle condition c
On Thu, 16 Feb 2006, Sylvain Munaut wrote:
> What I was thinking for the moment was to have :
> - sign is always the msb of the last ALU output
> - add/sub to modify all flags
> - move/xor/and/not/or only affect zero (and sign)
> - shift operations always affect carry and zero
> - Have some sp
> What's so bad about have the flag as side-effects ?
You can't put any other insn between the compare and the jump. Like,
if you wanted to move an address into a register to do the jump, you'd
lose the condition bits.
The advantage of having most insns set flags, is you can sometimes
avoid the
Hans-Peter Nilsson wrote:
> On Wed, 15 Feb 2006, Sylvain Munaut wrote:
>
>> * 2 flags Carry & Zero for testing.
>
>
> I think most of your questions have been answered, so let me
> just add that if nothing else, the port will be much simplified
> if you make sure that only specific compare
Hans-Peter Nilsson wrote:
On Wed, 15 Feb 2006, Sylvain Munaut wrote:
* 2 flags Carry & Zero for testing.
BTW, it depends on the compare (and branch) instructions whether
just two flags are sufficient.
That's true. MIPS for example seems to get by with no flags, although
it makes
On Wed, 15 Feb 2006, Sylvain Munaut wrote:
> * 2 flags Carry & Zero for testing.
I think most of your questions have been answered, so let me
just add that if nothing else, the port will be much simplified
if you make sure that only specific compare instructions set
condition codes, i.e. not
> > Well, cmpsi2 for example. and divsi2.
>
> You mean divsi3? Many targets don't have div at all.
Er, right. divsi3.
On Wednesday 15 February 2006 20:06, DJ Delorie wrote:
> > > Note that there are some operations that gcc assumes you have 32-bit
> > > opcodes for, though. Or at least insns that emulate it.
> >
> > Like what ?
>
> Well, cmpsi2 for example. and divsi2.
You mean divsi3? Many targets don't have d
> > Note that there are some operations that gcc assumes you have 32-bit
> > opcodes for, though. Or at least insns that emulate it.
>
> Like what ?
Well, cmpsi2 for example. and divsi2.
DJ Delorie wrote:
>>So If I use 16 bits registers, do I have to handle pairs of them to form
>>32 bits ?
>
>
> Well, you don't *have* to if your word size is only 16 bits. GCC will
> still pair them, but you'll need to tell gcc how to split them back up
> for the opcodes you have available.
>
>
> The final reason are immediates. I can't have 16 bits immediates in my
> opecode,
Not a problem; gcc knows how to use two insns to load immediates like
that. MIPS does it. Actually, most RISC processors end up doing
that. What you *would* want, though is a "load sign-extended
immediate" for
DJ Delorie wrote:
>> * 8 bit RISC microcontroller
>
> Not 16?
Well, at first it was to save space in the FPGA (basically, the regs and
ALU takes twice the space) and because many 16 bits ops can be done with
8 bits regs and lots of the code I do can live with that.
But I had a quick glance
> * 8 bit RISC microcontroller
Not 16?
> * 16 general purpose registers
> * 16 level deep hardware call stack
If you have RAM, why not use it? Model calls like the PPC - put
current $pc in a register and jump. The caller saves the old $pc in
the regular stack. GCC is going
Hello,
I'm currently considering writing my own microcontroller to use on
a FPGA. Since I'd like to be able to use C to write
"non-timing-critical" parts of my code, I thought I'd include a gcc port
as part of the design considerations.
I've read the online manual about gcc backend and googled
26 matches
Mail list logo
