bug handling instructions with multiple delay slots

bug handling instructions with multiple delay slots

[Alan Lehotsky]

I'm still back on 2.8.1 (with some of egcs 1.1.2), and see the following
problems with reorg.

1/ if a DEFINE_DELAY describes an instruction with TWO dissimilar
    delay slots, we don't correctly handle validating the instruction
    that ends up in the N-th delay slot against the "condition" for
    that particular slot.

2/ I have a case where the first of two delay slots gets a CC0 setter
    and the second gets something that will clobber those condition
    codes.  [The setter comes from the branch-target, while the instruction
    that clobbers comes from the fall thru]

I believe that the second problem violates the axiom that the CC0 setter
and CC0 user are required to be adjacent instructions.  [I also suspect
that I have another bug in that I don't abort() detecting this in my
define_insn pattern for conditional branches...]

Before I go off and figure out how to fix these, I'm curious if
anyone else with a N-instruction delay slots has already fixed this
and not submitted the patches yet.

I am aware of the C4X code, and have most of their changes (and they
have some of mine, I think)

Regards,
Al Lehotsky
------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)808-6836 Cellular
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

Re: bug handling instructions with multiple delay slots

[Jeffrey A Law]

  In message < v04220807b4475f1fe483@[192.168.1.254] >you write:
  > 1/ if a DEFINE_DELAY describes an instruction with TWO dissimilar
  >     delay slots, we don't correctly handle validating the instruction
  >     that ends up in the N-th delay slot against the "condition" for
  >     that particular slot.
  > 
  > 2/ I have a case where the first of two delay slots gets a CC0 setter
  >     and the second gets something that will clobber those condition
  >     codes.  [The setter comes from the branch-target, while the instruction
  >     that clobbers comes from the fall thru]
I believe both of these were fixed some time ago.

jeff

bug handling instructions with multiple delay slots

[Alan Lehotsky]

I'm still back on 2.8.1 (with some of egcs 1.1.2), and see the following
problems with reorg.

1/ if a DEFINE_DELAY describes an instruction with TWO dissimilar
    delay slots, we don't correctly handle validating the instruction
    that ends up in the N-th delay slot against the "condition" for
    that particular slot.

2/ I have a case where the first of two delay slots gets a CC0 setter
    and the second gets something that will clobber those condition
    codes.  [The setter comes from the branch-target, while the instruction
    that clobbers comes from the fall thru]

I believe that the second problem violates the axiom that the CC0 setter
and CC0 user are required to be adjacent instructions.  [I also suspect
that I have another bug in that I don't abort() detecting this in my
define_insn pattern for conditional branches...]

Before I go off and figure out how to fix these, I'm curious if
anyone else with a N-instruction delay slots has already fixed this
and not submitted the patches yet.

I am aware of the C4X code, and have most of their changes (and they
have some of mine, I think)

Regards,
Al Lehotsky
------------------------------------------------------------------------

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)808-6836 Cellular
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

Re: bug handling instructions with multiple delay slots

[Jeffrey A Law]

  In message < v04220807b4475f1fe483@[192.168.1.254] >you write:
  > 1/ if a DEFINE_DELAY describes an instruction with TWO dissimilar
  >     delay slots, we don't correctly handle validating the instruction
  >     that ends up in the N-th delay slot against the "condition" for
  >     that particular slot.
  > 
  > 2/ I have a case where the first of two delay slots gets a CC0 setter
  >     and the second gets something that will clobber those condition
  >     codes.  [The setter comes from the branch-target, while the instruction
  >     that clobbers comes from the fall thru]
I believe both of these were fixed some time ago.

jeff