delayed branches and zero overhead loops

delayed branches and zero overhead loops

[Joern Rennecke]

The ARCompact architecture has delay slots and zero overhead loops.
I see that there is already a cgen simulator with delay slots, for the iq2000.
I've looked at its mloop.in xextract-pbb case, and found that
it might decode one more instruction than max_insns, when the pbb ends with
a delay slot insn.
Is that a bug, or legitimate?

For zero overhead loop processing, I think the pbb handling makes most sense
when a pseudo instruction is inserted at the end of a loop, and when the
loop end is changed, any afected pbb is invalidated.

Like for delay slots, this pseudo instruction will need and extra decoded
insn slot, so again it is important to know if it is allowed to use one extra
slot.
A further problem is that I don't want to have a nonsense encoding for
the pseudo insn which could be triggered by invalid code, and/or cause decoder
conflicts.  Hence, there should be a way to define instruction semantics
without an instruction encoding.
What do you think would the bets way to express this?
No format field?  Treating an empty format field in a special way?
Adding a magic attribute that causes the format field (or its absence) to
be ignored?

Re: delayed branches and zero overhead loops

[Frank Ch. Eigler]

Hi -

> The ARCompact architecture has delay slots and zero overhead loops.
> I see that there is already a cgen simulator with delay slots, for
> the iq2000.  I've looked at its mloop.in xextract-pbb case [...]

For what it's worth, my recollection about how the PBB stuff works is
so hazy that I won't be able to give quick good advice.  Have you
considered using a plain non-pbb kernel, where you can hand-code these
subtleties in plain C/C++ code?

- FChE

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Tue, Feb 13, 2007 at 01:51:19PM -0500, Frank Ch. Eigler wrote:
> Hi -
> 
> > The ARCompact architecture has delay slots and zero overhead loops.
> > I see that there is already a cgen simulator with delay slots, for
> > the iq2000.  I've looked at its mloop.in xextract-pbb case [...]
> 
> For what it's worth, my recollection about how the PBB stuff works is
> so hazy that I won't be able to give quick good advice.  Have you
> considered using a plain non-pbb kernel, where you can hand-code these
> subtleties in plain C/C++ code?

Yes, I have.  In fact I though for a while that pbb was plain impossible,
because I had a part of the instruction length calculation in the
semantics, but that left me uncomfortable because it seemed like I was
only going to write a proof that you can make a slow simulator swith cgen.

The problem is that long immediates are available to a lot of different
instruction formats by using an encoding that looks like 'core register 62'.
Most of the instructions have two fields that can specify that.
Trying to express this with separate formats is not feasible, a this would
only quadruple the number of insn definition (double the number of formats
but awkward decoding), but also cause trouble making the decoder generator
comprehend where the boundaries between the different formats are.

So I originally had the immediate fecth and pc increment in a piece of
semantics.
Now I've figured out I can go pbb by doing the pc increment based on
instruction attributes in the pbb acse of mloop*.in.

Re: delayed branches and zero overhead loops

[Frank Ch. Eigler]

Hi -

> The problem is that long immediates are available to a lot of different
> instruction formats by using an encoding that looks like 'core register 62'.
> Most of the instructions have two fields that can specify that.
> Trying to express this with separate formats is not feasible, a this would
> only quadruple the number of insn definition (double the number of formats
> but awkward decoding), 

This part does not look that scary.  It's milder than m68k addressing
modes.  You can use cgen macros to generate instruction variants like
that.  We have processed ports with hundreds or maybe even thousands
of instructions, and while it ain't fast to run through, it still
works.

> but also cause trouble making the decoder generator comprehend where
> the boundaries between the different formats are.

The decoder generator is fully automatic.  If you represent decodable
bits without cheating, it will do a reasonable job.

- FChE

Re: delayed branches and zero overhead loops

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
> 
> The decoder generator is fully automatic.  If you represent decodable
> bits without cheating, it will do a reasonable job.

I which that were the case.  Try to generate the decoder for the attached
file; it warns about one alledged Decoder ambiguity for j_L_r_r [$RC-noilink]
versus j_L_r_r [$RC-ilink] .  The values for $RC-ilink and $RC-noilink are
disjoint.  I've also tried to use a decode-split on this problem, but to
no avail.

[-- Attachment #2: ARCompact.cpu.bz2 --]
[-- Type: application/x-bzip2, Size: 17466 bytes --]

Re: delayed branches and zero overhead loops

[Dave Brolley]

Joern Rennecke wrote:

>On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
>  
>
>>The decoder generator is fully automatic.  If you represent decodable
>>bits without cheating, it will do a reasonable job.
>>    
>>
>
>I which that were the case.  Try to generate the decoder for the attached
>file; it warns about one alledged Decoder ambiguity for j_L_r_r [$RC-noilink]
>versus j_L_r_r [$RC-ilink] .  The values for $RC-ilink and $RC-noilink are
>disjoint.  I've also tried to use a decode-split on this problem, but to
>no avail.
>  
>
The problem is that RC-ilink and RC-noilink are operands. They do not 
participate in insn decoding. If there are no other differences in the 
fixed fields of the insns (it's hard to tell because of the complexity 
of your pmacros), then there will be an ambiguity. If you add enough 
"-v"s to CGENFLAGS when you run your make, you will get a dump of the 
pmacro-expanded input.

Dave

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Wed, Feb 14, 2007 at 12:08:21PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> 
> >On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
> > 
> >
> >>The decoder generator is fully automatic.  If you represent decodable
> >>bits without cheating, it will do a reasonable job.
> >>   
> >>
> >
> >I which that were the case.  Try to generate the decoder for the attached
> >file; it warns about one alledged Decoder ambiguity for j_L_r_r 
> >[$RC-noilink]
> >versus j_L_r_r [$RC-ilink] .  The values for $RC-ilink and $RC-noilink are
> >disjoint.  I've also tried to use a decode-split on this problem, but to
> >no avail.
> > 
> >
> The problem is that RC-ilink and RC-noilink are operands. They do not 
> participate in insn decoding. If there are no other differences in the 
> fixed fields of the insns (it's hard to tell because of the complexity 
> of your pmacros),

That is indeed the case.  The only format differences are in the
RC-ilink / RC-noilink operand and in the F0 / F1F operand.

> then there will be an ambiguity.

It's the same situation with long immediates.  They are indicated by a
special value in any one of three operand fields.

> If you add enough 
> "-v"s to CGENFLAGS when you run your make, you will get a dump of the 
> pmacro-expanded input.

The debug output without any -v is already too much to be read, unless
it is captured with script and then searched for specific items.
If I want to know the expansion of a single macro, I find it more useful
to use pmacro-expand interactively - the latency is also much lower than
to rm -rf the entire build tree and then rebuilding.

Speaking of which, is there a better way?  I've tried deleting individual
generated files or stamps, and some clean targets, but make always
floundered.

Re: delayed branches and zero overhead loops

[Dave Brolley]

Joern Rennecke wrote:

>On Wed, Feb 14, 2007 at 12:08:21PM -0500, Dave Brolley wrote:
>  
>
>>Joern Rennecke wrote:
>>
>>    
>>
>>>I which that were the case.  Try to generate the decoder for the attached
>>>file; it warns about one alledged Decoder ambiguity for j_L_r_r 
>>>[$RC-noilink]
>>>versus j_L_r_r [$RC-ilink] .  The values for $RC-ilink and $RC-noilink are
>>>disjoint.  I've also tried to use a decode-split on this problem, but to
>>>no avail.
>>>
>>>      
>>>
>>The problem is that RC-ilink and RC-noilink are operands. They do not 
>>participate in insn decoding. If there are no other differences in the 
>>fixed fields of the insns (it's hard to tell because of the complexity 
>>of your pmacros),
>>    
>>
>
>That is indeed the case.  The only format differences are in the
>RC-ilink / RC-noilink operand and in the F0 / F1F operand.
>  
>
If so, then there must be more bits which are constant in each of the 
two forms of the insn, otherwise, how does the hardware decode them?

>It's the same situation with long immediates.  They are indicated by a
>special value in any one of three operand fields.
>  
>
Then this special value should be part of the fixed bits in the insn 
description

>If I want to know the expansion of a single macro, I find it more useful
>to use pmacro-expand interactively - the latency is also much lower than
>to rm -rf the entire build tree and then rebuilding.
>
>Speaking of which, is there a better way?  I've tried deleting individual
>generated files or stamps, and some clean targets, but make always
>floundered.
>  
>
Usualy deleting the stamp-* files does the trick for me.

Dave

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> >That is indeed the case.  The only format differences are in the
> >RC-ilink / RC-noilink operand and in the F0 / F1F operand.
> > 
> >
> If so, then there must be more bits which are constant in each of the 
> two forms of the insn, otherwise, how does the hardware decode them?

ilink1 is core register 29, ilink2 is core register 30 .
Thus, you could describe the upper four bits of RC-ilink as 7,
but that would still not disambiguate it from RC-noilink for core registers
28 and 31.

> >It's the same situation with long immediates.  They are indicated by a
> >special value in any one of three operand fields.
> > 
> >
> Then this special value should be part of the fixed bits in the insn 
> description

But won't that require also fixed bits for the variant were there is a
register encoded in the register field?  With the general operations
form taking two operands that may or may not be a long immediate, encoding
each of the 61 core registers, long immediate and program counter read
encoded with constant bit patterns, that would explode the insn count by
a factor of 3969.

> >Speaking of which, is there a better way?  I've tried deleting individual
> >generated files or stamps, and some clean targets, but make always
> >floundered.
> > 
> >
> Usualy deleting the stamp-* files does the trick for me.

Which ones?

Re: delayed branches and zero overhead loops

[Dave Brolley]

Joern Rennecke wrote:
> On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote:
>   
>> Joern Rennecke wrote:
>>     
>>> That is indeed the case.  The only format differences are in the
>>> RC-ilink / RC-noilink operand and in the F0 / F1F operand.
>>>
>>>
>>>       
>> If so, then there must be more bits which are constant in each of the 
>> two forms of the insn, otherwise, how does the hardware decode them?
>>     
>
> ilink1 is core register 29, ilink2 is core register 30 .
> Thus, you could describe the upper four bits of RC-ilink as 7,
> but that would still not disambiguate it from RC-noilink for core registers
> 28 and 31.
>   
I would merge the two insns into one and handle the difference in the 
semantic code by checking (index-of <operand>)
>   
>>> It's the same situation with long immediates.  They are indicated by a
>>> special value in any one of three operand fields.
>>>       
This could be handled in the same way by checking the values of the 
immediate operands.

Dave

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Fri, Feb 16, 2007 at 03:53:49PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> >On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote:
> >  
> >>Joern Rennecke wrote:
> >>    
> >>>That is indeed the case.  The only format differences are in the
> >>>RC-ilink / RC-noilink operand and in the F0 / F1F operand.
> >>>
> >>>
> >>>      
> >>If so, then there must be more bits which are constant in each of the 
> >>two forms of the insn, otherwise, how does the hardware decode them?
> >>    
> >
> >ilink1 is core register 29, ilink2 is core register 30 .
> >Thus, you could describe the upper four bits of RC-ilink as 7,
> >but that would still not disambiguate it from RC-noilink for core registers
> >28 and 31.
> >  
> I would merge the two insns into one and handle the difference in the 
> semantic code by checking (index-of <operand>)

These insns have different syntax.
I.e. the RC-ilink variant has an optional operand which the RC-noilink version
hasn't.  AFAIK this can not be expressed in cgen with a single insn.

> >>>It's the same situation with long immediates.  They are indicated by a
> >>>special value in any one of three operand fields.
> >>>      
> This could be handled in the same way by checking the values of the 
> immediate operands.

You don't seem to quite understand the situation.  I have to check the
value of zero, one or two register fields in order to determine if the
long immediate field exists.

Therefore, I had to put part of the instruction fetch (the reading of the
long immediate) in the semantics of the instruction.

The knowledge about the instruction length is no longer in format field
of insn patterns in the .cpu file, but in mloop*.in .

With the length information already broken, I've also worked around the
decoder generator problem with generating negative shifts by pretending
that every instruction is 32 bit long; mloop*.in knowshaw to calculate that
actual lengths and how to fetch 16 and 32 bit opcodes, and represent them
as 32 bit opcodes.

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Mon, Feb 19, 2007 at 10:21:14AM -0500, Dave Brolley wrote:
> It's difficult to help you when this information comes out in bits and pieces as we suggest solutions which fit the information we already have. How about posting the complete spec of both insns?

I've already posted the cgen description - here:
http://www.sourceware.org/ml/cgen/2007-q1/msg00047.html

If you want the ARCompact-ISA Programmer's Reference, you can download
it from www.arc.com .   When you go there to Download/Product Briefs,
you find it there under the heading 'Reference Manuals'
(registration required).

Re: delayed branches and zero overhead loops

[Frank Ch. Eigler]

Hi -

> [...]  If you want the ARCompact-ISA Programmer's Reference, you can
> download it from www.arc.com .  When you go there to
> Download/Product Briefs, you find it there under the heading
> 'Reference Manuals' (registration required).

One form of appreciating the effort of those who volunteer
to help you is by minimizing obstacles like registration.

- FChE

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Mon, Feb 19, 2007 at 11:07:35AM -0500, Frank Ch. Eigler wrote:
> 
> One form of appreciating the effort of those who volunteer
> to help you is by minimizing obstacles like registration.

Would you like me to email you a copy?
It's a 2133323 bytes .pdf file, 1498223 bytes if compressed with gzip -9,
1479888 bytes if compressed with bzip2.

Re: delayed branches and zero overhead loops

[Dave Brolley]

Joern Rennecke wrote:
> On Mon, Feb 19, 2007 at 11:07:35AM -0500, Frank Ch. Eigler wrote:
>   
>> One form of appreciating the effort of those who volunteer
>> to help you is by minimizing obstacles like registration.
>>     
>
> Would you like me to email you a copy?
> It's a 2133323 bytes .pdf file, 1498223 bytes if compressed with gzip -9,
> 1479888 bytes if compressed with bzip2.
>   
No --- please just provide the spec for the insns you're having trouble 
with.

Just like providing support for a problem in the field, it's easier for 
people to help you if you can narrow the problem down to the bits that 
matter.

Thanks,
Dave

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Mon, Feb 19, 2007 at 01:19:36PM -0500, Dave Brolley wrote:
> No --- please just provide the spec for the insns you're having trouble 
> with.

I've sent you the relevant pages as bzip2-ed postscript, while I
sent Frank Ch. Eigler the full reference.  I hope that this arrived, even
just a few pages in postscript make a largish email.

insert evaluation for multi-ifields broken

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

When I want to put a constant into a multi-ifield, the
exact instructions how to set the subfields are apparently ignored, and the
total value is copied into the subfields.
I have found this while working on my machine desscription,
and I could reproduce this with a small synthetic testcase, attached as
foo.cpu.  I've put tis file into the cgen/cpu directory, and
then with the cgen directory as the cwd, invoked guile and evaluated:
(load "dev.scm")
(load-sim)
(cload #:arch "foo" #:machs "foo")
(cgen-decode.c)

note that the expected value to check entire_insn against is 0x1324,
but generated test is:
        if ((entire_insn & 0xffff) == 0x12424)

[-- Attachment #2: foo.cpu --]
[-- Type: text/plain, Size: 1324 bytes --]

(include "simplify.inc")

(define-arch
  (name foo) ; name of cpu family
  (comment "")
  (default-alignment aligned)
  (insn-lsb0? #f)
  (machs foo)
  (isas foo)
)

(define-isa
  (name foo)

  ; The default size of an instruction in bits
  (default-insn-bitsize 16)

  (base-insn-bitsize 16)

  (default-insn-word-bitsize 16)
)

(define-cpu
  (name foo)
  (comment "")
  (endian either)
  (word-bitsize 16)
  ; Generated files have an "f" suffix.
  (file-transform "f")
)

(define-mach
  (name foo)
  (comment "")
  (cpu foo)
)

(dnf  f-a "op a" ()  0 4)
(dnf  f-b "op a" ()  4 4)
(dnf  f-c "op a" ()  8 4)
(dnf  f-d "op a" () 12 4)
(dnmf f-ac "op ac" () UINT
  (f-a f-c)
  (sequence () ; insert
    (set (ifield f-c) (and (ifield f-ac) (const 15)))
    (set (ifield f-a) (srl (ifield f-ac) (const  4)))
  )
  (sequence () ; extract
    (set (ifield f-ac) (or (ifield f-c) (sll (ifield f-a) 4)))
  )
)

(define-pmacro (dni xname xcomment xsyntax xformat xattrs xsemantics)
  (define-insn
    (name xname)
    (comment xcomment)
    (.splice attrs (.unsplice xattrs))
    (syntax xsyntax)
    (format xformat)
    (semantics xsemantics)
    )
)

(dnh h-pc "program counter" (PC PROFILE) (pc) () () ())

(dni
  swi
  ""
  "swi"
  (+ (f-ac 18) (f-b 3) (f-d 4))
  ()
  (sequence ()
    (set pc (c-call SI "foo_trap" pc 0)))
)

Re: insert evaluation for multi-ifields broken

[Dave Brolley]

Joern Rennecke wrote:

>When I want to put a constant into a multi-ifield, the
>exact instructions how to set the subfields are apparently ignored, and the
>total value is copied into the subfields.
>  
>
This does appear to be broken. This is probably the first time someone 
has attempted this, since you could use f-a and f-c directly.

(dni
  swi
  ""
  "swi"
  (+ (f-a 1) (f-b 3) (f-c 2) (f-d 4))
  ()
  (sequence ()
    (set pc (c-call SI "foo_trap" pc 0)))
)

Multi-ifields are generally used in conjuction with an operand. I'm not 
saying you shouldn't be able to do what you're attempting, just that no 
one has likely tried it before.

Dave

>I have found this while working on my machine desscription,
>and I could reproduce this with a small synthetic testcase, attached as
>foo.cpu.  I've put tis file into the cgen/cpu directory, and
>then with the cgen directory as the cwd, invoked guile and evaluated:
>(load "dev.scm")
>(load-sim)
>(cload #:arch "foo" #:machs "foo")
>(cgen-decode.c)
>
>note that the expected value to check entire_insn against is 0x1324,
>but generated test is:
>        if ((entire_insn & 0xffff) == 0x12424)
>  
>
>------------------------------------------------------------------------
>
>(include "simplify.inc")
>
>(define-arch
>  (name foo) ; name of cpu family
>  (comment "")
>  (default-alignment aligned)
>  (insn-lsb0? #f)
>  (machs foo)
>  (isas foo)
>)
>
>(define-isa
>  (name foo)
>
>  ; The default size of an instruction in bits
>  (default-insn-bitsize 16)
>
>  (base-insn-bitsize 16)
>
>  (default-insn-word-bitsize 16)
>)
>
>(define-cpu
>  (name foo)
>  (comment "")
>  (endian either)
>  (word-bitsize 16)
>  ; Generated files have an "f" suffix.
>  (file-transform "f")
>)
>
>(define-mach
>  (name foo)
>  (comment "")
>  (cpu foo)
>)
>
>(dnf  f-a "op a" ()  0 4)
>(dnf  f-b "op a" ()  4 4)
>(dnf  f-c "op a" ()  8 4)
>(dnf  f-d "op a" () 12 4)
>(dnmf f-ac "op ac" () UINT
>  (f-a f-c)
>  (sequence () ; insert
>    (set (ifield f-c) (and (ifield f-ac) (const 15)))
>    (set (ifield f-a) (srl (ifield f-ac) (const  4)))
>  )
>  (sequence () ; extract
>    (set (ifield f-ac) (or (ifield f-c) (sll (ifield f-a) 4)))
>  )
>)
>
>(define-pmacro (dni xname xcomment xsyntax xformat xattrs xsemantics)
>  (define-insn
>    (name xname)
>    (comment xcomment)
>    (.splice attrs (.unsplice xattrs))
>    (syntax xsyntax)
>    (format xformat)
>    (semantics xsemantics)
>    )
>)
>
>(dnh h-pc "program counter" (PC PROFILE) (pc) () () ())
>
>(dni
>  swi
>  ""
>  "swi"
>  (+ (f-ac 18) (f-b 3) (f-d 4))
>  ()
>  (sequence ()
>    (set pc (c-call SI "foo_trap" pc 0)))
>)
>
>  
>

Re: insert evaluation for multi-ifields broken

[Joern Rennecke]

On Thu, Feb 22, 2007 at 11:55:57AM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> 
> >When I want to put a constant into a multi-ifield, the
> >exact instructions how to set the subfields are apparently ignored, and the
> >total value is copied into the subfields.
> > 
> >
> This does appear to be broken. This is probably the first time someone 
> has attempted this, since you could use f-a and f-c directly.

The real code is much more complex (80 KB .cpu file, generating - among
other things - three decode*.c files in excess of 700 KB each).
The multi-ifield is usually used for a register operand.  However, there
are some special instructions where this operand is not needed, so a
bunch of them can be encoded by using different values in this field  -
I implemented this with a normal-insn-enum, which uses the multi-ifield.
Individual values of this enum are then placed in the format of the
the separate insns, whcih is equivalent to putting a constant into the
field.

Re: insert evaluation for multi-ifields broken

[Dave Brolley]

Joern Rennecke wrote:
> The real code is much more complex (80 KB .cpu file, generating - among
> other things - three decode*.c files in excess of 700 KB each).
> The multi-ifield is usually used for a register operand.  However, there
> are some special instructions where this operand is not needed, so a
> bunch of them can be encoded by using different values in this field  -
> I implemented this with a normal-insn-enum, which uses the multi-ifield.
> Individual values of this enum are then placed in the format of the
> the separate insns, whcih is equivalent to putting a constant into the
> field.
>   
Understood and quite reasonable, but unfortunately broken. Your choices 
would seem to be to fix the bug or try the workaround.

Dave

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Wed, Feb 14, 2007 at 02:51:50PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
> >Speaking of which, is there a better way?  I've tried deleting individual
> >generated files or stamps, and some clean targets, but make always
> >floundered.
> > 
> >
> Usualy deleting the stamp-* files does the trick for me.

P.S.: When I do:
find sim opcodes -name '*stamp*'|xargs rm
make all-sim CFLAGS=-g

this is how the rebuild attempt ends:
make[2]: Entering directory `/scratch/srcw/bld-arc/sim/arc'
CONFIG_FILES= CONFIG_HEADERS=config.h:config.in /bin/sh ./config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: linking ../../../src/sim/arc/tconfig.in to tconfig.h
config.status: linking ../../../src/sim/arc/../common/nltvals.def to targ-vals.def
config.status: executing Makefile commands
Merging Makefile.sim+Make-common.sim into Makefile ...
./config.status: line 1261: Make-common.sim: No such file or directory
./config.status: line 1262: Make-common.sim: No such file or directory
./config.status: line 1263: Makefile.sim: No such file or directory
config.status: executing stamp-h commands
rm -f tmp-tvals.h tmp-tmap.c
./gentmap -h >tmp-tvals.h
/bin/sh ../../../src/sim/arc/../../move-if-change tmp-tvals.h targ-vals.h
./gentmap -c >tmp-tmap.c
/bin/sh ../../../src/sim/arc/../../move-if-change tmp-tmap.c targ-map.c
touch stamp-tvals
make cgen-arch CGEN='"`if [ -f ../../guile/libguile/guile ]; then echo ../../guile/libguile/guile; else echo guile ; fi` -l ../../../src/sim/arc/../../cgen/guile.scm -s"' CGENFLAGS="-v" mach=all \
  archfile=../../../src/sim/arc/../../cgen/cpu/arc.cpu \
  FLAGS="with-scache with-profile=fn"
make[3]: Entering directory `/scratch/srcw/bld-arc/sim/arc'
make[3]: *** No rule to make target `cgen-arch'.  Stop.
make[3]: Leaving directory `/scratch/srcw/bld-arc/sim/arc'
make[2]: *** [stamp-arch] Error 2
make[2]: Leaving directory `/scratch/srcw/bld-arc/sim/arc'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/scratch/srcw/bld-arc/sim'
make: *** [all-sim] Error 2

decode-bitsize (Was: Re: delayed branches and zero overhead loops)

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
> The decoder generator is fully automatic.  If you represent decodable
> bits without cheating, it will do a reasonable job.

Actually, I realize now that I have a much bigger problem with the decoder
generator.
Originally, I set out to set default-insn-bitsize, base-insn-bitsize and
default-insn-word-bitsize all to 16, because that's what I should do according
to the documentation.  However, that gave me tons of ambiguity warnings.
from previous postings on the cgen mailing list and the xstormy port I've
gathered that I have to set base-insn-bitsize to 32.  Apart from the
ilink / noilink thing, that got rid of the spurious ambiguity warnings.
However, when compiling the decoder, I got tons of warnings about neative
shifts.  Declaring base-insn-bitsize as 32 does not make it so: it still
stays 16 once you have 16 bit instructions.
And the second level decoding tables are also generated using base-insn.
As bits from beyond the first 16 bits are needed, this results in a negative
shift.
I had though that I had solved this porblem by declaring bit fields in the
second word using a word offset, but i've found now that the effect is that
the decoder generator will completely mask out these bits from the insn -
even in the final comparisons against entire_insn to check if there is a
match.
It won't mask it out in the constant value to compare against, though,
so any insn that requires a bit in the second 16 bits to be set is decoded as
@CPU@_INSN_X_INVALID.

When I put the fields back to use no word offsets, the matching tests
are OK, but as the decoding switch statements also use bits from
beyond the first 16, they again end up with negative shifts.
I've tried hacking -gen-decoder-switch so that it always fetches the required
bits, but all I get is a re-fetch of the first 16 bits.
So, the decode-bitsize in the table-guts somehow is 16, even though that
is insufficient to cover all the included bits.

I have appended a copy of ARCompact.cpu version that get translated to a
decoder with negative shifts.

[-- Attachment #2: ARCompact.cpu.bz2 --]
[-- Type: application/x-bzip2, Size: 17542 bytes --]

delayed branches and zero overhead loops

[Doug Evans]

Joern Rennecke writes:
 > Like for delay slots, this pseudo instruction will need and extra decoded
 > insn slot, so again it is important to know if it is allowed to use one extra
 > slot.
 > A further problem is that I don't want to have a nonsense encoding for
 > the pseudo insn which could be triggered by invalid code, and/or cause decoder
 > conflicts.  Hence, there should be a way to define instruction semantics
 > without an instruction encoding.
 > What do you think would the bets way to express this?
 > No format field?  Treating an empty format field in a special way?
 > Adding a magic attribute that causes the format field (or its absence) to
 > be ignored?

fwiw,

It sounds like you want to add an application specific entry to the
cpu description file.  For me that's an ipso-facto wrong way to go.

Having said that, I can imagine partitioning the description file
into multiple files such that these pseudo-insns are only seen by
the application in question.

And then having said that, the degrees of freedom for how to
implement this are much more open.

If I were to choose from the options you suggest, and I'm not sure
I would, but if I were, I'd go with something explicit.
The absence of something shouldn't denote special behaviour.
What if a later developer forgets to add something?
Did he really forget, or is he trying to denote this special behaviour?
Thus of the choices mentioned, an attribute is the preferable one.

fwiw, I think the partitioning of problems into application
independent and application dependent parts is fundamental to cgen.
Clearly zero overhead loops are part of the architecture, but
as I understand the plan of attack, it sounds like you're going
for an application specific solution - what if a different
simulator wants to do things differently?
Thus question: Is there a way to express the zero-overhead
loops in an a way that is more faithful to being just a
description of the architecture, and not an application specific hack.

Which leads to me next question:
Is ARCompact a variant of the ARC for which I did a port ages ago?
[I didn't do a simulator port for it though, I had to use the one given me.]
I forget if/how it handled zero overhead loops.
Can you refresh my memory?  That might help in coming up with
a reasonable solution.

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Tue, Feb 13, 2007 at 11:24:53AM -0800, Doug Evans wrote:
> It sounds like you want to add an application specific entry to the
> cpu description file.  For me that's an ipso-facto wrong way to go.

This is something only of concern to applications that care about the
semantics of the insns.  Thus, gas does not need to know about this.
If you wanted to generate a gcc machine description, than this is
in principle relevant - except that expressing this all in generic rtl
would likely lead the machine description generator to give up,
since it won't be able to find any basic arithmetic instructions -
every instruction will be flagged as having conditional flow control.

> Having said that, I can imagine partitioning the description file
> into multiple files such that these pseudo-insns are only seen by
> the application in question.

Why does it have to be yet another file?  There is already a syntax-only
attribute that specifies that some information is only for applications that
care about syntax.
Not that I am fundamentally opposed to doing it with separate files,
but it appears to me that it makes things core complicated rather than
simpler.

If you want it to frame it in terms that give universal meaning to the
instruction semantics, you can express it in three pieces:
- A piece of rtl that might need to be appeded to the semantics of 
  every instruction.
- A condition that tests if this piece of rtl should actually be
  executed, for use in a simple interpreter.
- In the mloop.in:xextract-pbb code, code that computes at decode time
  when to append the pseudo insn to a pbb
  (or if you have some other use for a pseudo insn that doesn't end
   a pbb, you might also stick it into the middle).

> Thus question: Is there a way to express the zero-overhead
> loops in an a way that is more faithful to being just a
> description of the architecture, and not an application specific hack.

As I said above, you can do it by adding rtl to every instruction that makes
every instruction COND_CTI.

> Which leads to me next question:
> Is ARCompact a variant of the ARC for which I did a port ages ago?

Unfortunately, the sourceware.org cvs history is a bit patchy - e.g. the
bfd cvs history only goes back to 1999 - so I'm not sure which part(s)
of the toolchain you ported, and to what ARC variant.

ARCompact is the instruction set architecture used by the ARCtangent-A5,
ARC 600 and ARC 700 cores.  It has 16 and 32 bit opcodes.
The ARCtangent-A4 had only 32 bit opcodes, but I have been told that
for user code, ARCcompact is mostly backwards ompatible to ARCtangent-A4
code.

> I forget if/how it handled zero overhead loops.
> Can you refresh my memory?  That might help in coming up with
> a reasonable solution.

The loop counter register lp_count is a core register, which
means you can do with it most of the things you can do with a general
purpose register.

lp_start and lp_end are auxilary registers, which are usually set
up with the lp / lpcc instruction althou they can also be read
and written to with the lr and sr (load / store auxilary register)
instructions.

The lp instruction set lp_start to the sucessor instruction,
and lp_end to the instruction specified by the offset embedded in the
isntruction.
likewise for lpcc if the condition is true.  If the condition is false,
lpcc will instead jump to the loop end (that is the same address that
would otherwise be laoded int lp_end).

lp_end points to the first instruction after the loop.

When the program counter is incremented to match lp_end,
lp_count is decremented; if lp_count was not 1 (i.e. it is not
decremented to zero), a jump to lp_start is performed.

The ARC 700 also as a loop inhibit bit in its status register that
gets set on interrupt, and cleared by the lp / lpcc instruction.

Re: delayed branches and zero overhead loops

[Doug Evans]

Joern Rennecke writes:
 > On Tue, Feb 13, 2007 at 11:24:53AM -0800, Doug Evans wrote:
 > > It sounds like you want to add an application specific entry to the
 > > cpu description file.  For me that's an ipso-facto wrong way to go.
 > 
 > This is something only of concern to applications that care about the
 > semantics of the insns.  Thus, gas does not need to know about this.

Clearly. [And the chosen implementation is specific to the
particular simulator you're writing.]

 > If you wanted to generate a gcc machine description, than this is
 > in principle relevant - except that expressing this all in generic rtl
 > would likely lead the machine description generator to give up,
 > since it won't be able to find any basic arithmetic instructions -
 > every instruction will be flagged as having conditional flow control.

I wouldn't add this specification to the insns.  Blech.
I would add it to the same place where "condition" and "setup-semantics" is.
No claim is made that new fields that are reasonable can't be added here.

 > > Having said that, I can imagine partitioning the description file
 > > into multiple files such that these pseudo-insns are only seen by
 > > the application in question.
 > 
 > Why does it have to be yet another file?  There is already a syntax-only
 > attribute that specifies that some information is only for applications that
 > care about syntax.
 > Not that I am fundamentally opposed to doing it with separate files,
 > but it appears to me that it makes things core complicated rather than
 > simpler.

There's no basic limit on the number of applications that can use cgen.
I would argue against a modus operandi that had the default behaviour
of adding such (obvious) application specific stuff to the basic
cpu description file.  When working with libraries, programmers don't
think of modifying the library in their first pass at using it.
Same reasoning applies here.

Having said that, I can envision providing the necessary specification
along side setup-semantics, and then having the simulator make use of it.
If done this way, the specification is of the architecture in a (hopefully)
reasonably useful way and any app that wants to make use of the data can.

 > If you want it to frame it in terms that give universal meaning to the
 > instruction semantics, you can express it in three pieces:
 > - A piece of rtl that might need to be appeded to the semantics of 
 >   every instruction.
 > - A condition that tests if this piece of rtl should actually be
 >   executed, for use in a simple interpreter.
 > - In the mloop.in:xextract-pbb code, code that computes at decode time
 >   when to append the pseudo insn to a pbb
 >   (or if you have some other use for a pseudo insn that doesn't end
 >    a pbb, you might also stick it into the middle).

Right, setting aside the last part.  I'm not sure I'd do it that way,
but I haven't been in that particular code for awhile.

 > > Thus question: Is there a way to express the zero-overhead
 > > loops in an a way that is more faithful to being just a
 > > description of the architecture, and not an application specific hack.
 > 
 > As I said above, you can do it by adding rtl to every instruction that makes
 > every instruction COND_CTI.

And (I think) we both agree this isn't the best way to go.

 > > Which leads to me next question:
 > > Is ARCompact a variant of the ARC for which I did a port ages ago?
 > 
 > Unfortunately, the sourceware.org cvs history is a bit patchy - e.g. the
 > bfd cvs history only goes back to 1999 - so I'm not sure which part(s)
 > of the toolchain you ported, and to what ARC variant.

lp_start, lp_end, lp_count sound very familiar,
as does special casing of r62.

Re: delayed branches and zero overhead loops

[Joern Rennecke]

On Wed, Feb 14, 2007 at 10:29:45AM -0800, Doug Evans wrote:
> Joern Rennecke writes:
> 
>  > If you wanted to generate a gcc machine description, than this is
>  > in principle relevant - except that expressing this all in generic rtl
>  > would likely lead the machine description generator to give up,
>  > since it won't be able to find any basic arithmetic instructions -
>  > every instruction will be flagged as having conditional flow control.
> 
> I wouldn't add this specification to the insns.  Blech.
> I would add it to the same place where "condition" and "setup-semantics" is.

Yes, that's a reasonable place to put the specification for the semantics
when you are executing one insn at a time.  Still, there should also
be a way to streamline this with the pbb simulator.
Note that trying to do this fully automatic would require a combination of
profiling and artificial intelligence; you need to realize that, although
loop_end can be changed at runtime, it is not likely to change all too often,
so it makese sense to to the comparison at decode time, and invalidate
any decoded pbb if a new loop end is placed inside it.

FWIW, the condition part of the isa form is actually not usable for ARC,
since not all instruction take the canonical condition.
lpcc takes it, but it has a no-noop 'else' operation.  A number of
instructions take a different condition, or none at all.

> No claim is made that new fields that are reasonable can't be added here.
> 
>  > > Having said that, I can imagine partitioning the description file
>  > > into multiple files such that these pseudo-insns are only seen by
>  > > the application in question.
>  > 
>  > Why does it have to be yet another file?  There is already a syntax-only
>  > attribute that specifies that some information is only for applications that
>  > care about syntax.
>  > Not that I am fundamentally opposed to doing it with separate files,
>  > but it appears to me that it makes things core complicated rather than
>  > simpler.
> 
> There's no basic limit on the number of applications that can use cgen.
> I would argue against a modus operandi that had the default behaviour
> of adding such (obvious) application specific stuff to the basic
> cpu description file.  When working with libraries, programmers don't
> think of modifying the library in their first pass at using it.
> Same reasoning applies here.

Then we'd need some mechanism to allow sem*switch.c to be built using
application-specific fragments, so that the required pseudo instruction
can be included in the switch.

Would you also want to re-design the way the sh.cpu deals with the different
delay slot mechanisms of sim and sid?
It seems rather strange that delay slots have to be described in two
languages at once.