[ECOS] SH1 port of eCos

[ECOS] SH1 port of eCos

[Aaron Passey]

Hi,

I just thought I would let everybody know that I have started working on an
SH1 port of eCos.  If anybody else is working on such a port, please let me
know and we can hopefully work together.  Assuming my port works, I have no
problem contributing it back.

Now to the meat of the issue.  hal/sh/arch/current/src/vector.S seems to
contain a lot of SH3 specific assembly which does not apply to the SH1 (or
SH2).  It has code in there dealing with the SH3's banked registers which
the SH1 and SH2 don't have, for example.  What's the best way to deal with
this?  Should all this code get moved to sh[34]/current/src/variant.S?

For the curious, my project is entirely for fun.  I am building "Laser
Tetris".  The plan is to play Tetris (or astroids or anything else that can
be reasonably done with vector graphics) on the wall using a couple of
galvos and a laser.  It's based around a board I designed that has a
Hitachi SH7032 SH1 processor, the usual RAM and ROM, and a couple of 16bit
DACs that drive the galvos (through a couple driver boards, of course).
All the hardware is built and tested (including drawing basic shapes on the
wall with the laser) and now I need to write the software.  Actually, all
my original software got wiped out in a harddrive crash so I thought I
would do it right this time and put a real OS on it (and maybe backup my
work by contributing it back to eCos!).

Oh, I'm not currently subscribed to eCos-discuss so I would appreciate
being cc'd on any replies.

Thanks,

Aaron

Re: [ECOS] SH1 port of eCos

[Jesper Skov]

>>>>> "Aaron" == Aaron Passey <aaronp@ngwee.ugcs.caltech.edu> writes:

(thanks, Aaron!)

Aaron> Now to the meat of the issue.  hal/sh/arch/current/src/vector.S
Aaron> seems to contain a lot of SH3 specific assembly which does not
Aaron> apply to the SH1 (or SH2).  It has code in there dealing with
Aaron> the SH3's banked registers which the SH1 and SH2 don't have,
Aaron> for example.  What's the best way to deal with this?  Should
Aaron> all this code get moved to sh[34]/current/src/variant.S?

We don't want to move the functions to the variants. Instead we want
to make some macros that take care of register save/restore. Or
rather, that's the way I'd go - using macros we get the entire program
flow listed in one file, vectors.S.

Presumably the SH1 has some spare registers that can be used in the
early exception handling - otherwise you'd be trashing user code's
state.

So if possible, I suggest rewriting the exception entry functions to
be generic for SH1/SH3/SH4. That is, __exception, __tlb_miss,
and __interrupt. Again assuming the SH1 has these. [if this is not
possible, we can macro'ize that part of the code as well]


Then make the cyg_hal_default_exception_vsr and
cyg_hal_default_interrupt_vsr functions use 

 hal_cpu_save

which the variants provide in the variant.inc file. This macro should
handle everything from entry of those functions to the _vsr_bp_safe
labels.


Same in restore_state, except the code would go in the macro

 hal_cpu_load


On the SH4 we'll eventually get hal_fpu_save/load macros as
well, so entry exit would look something like this:

_vsr:
 hal_cpu_save
 hal_fpu_save sp
_vsr_bp_safe:
 ...
restore_state:
 hal_fpu_load sp
 hal_cpu_load
 rte
  nop


Note that the _cpu_ macros do not take the sp argument since they have
to (depending on config) set up the stack pointer.


If you want to look at some HAL where this has been sort-of-made, see
the MIPS HAL which uses many many macros (but only the fpu macros in
the vsr code).

Think that should do it? Happy with this? Let me know if there are
some things you disagree with - I've never looked at the SH1 and it
may take more magic than the above.



Aaron> Oh, I'm not currently subscribed to eCos-discuss so I would
Aaron> appreciate being cc'd on any replies.

You don't know what you're missing! :)

Jesper

Re: [ECOS] SH1 port of eCos

[Aaron Passey]

Sorry, I was pretty busy this weekend.

> Aaron> Now to the meat of the issue.  hal/sh/arch/current/src/vector.S
> Aaron> seems to contain a lot of SH3 specific assembly which does not
> Aaron> apply to the SH1 (or SH2).  It has code in there dealing with
> Aaron> the SH3's banked registers which the SH1 and SH2 don't have,
> Aaron> for example.  What's the best way to deal with this?  Should
> Aaron> all this code get moved to sh[34]/current/src/variant.S?
> 
> We don't want to move the functions to the variants. Instead we want
> to make some macros that take care of register save/restore. Or
> rather, that's the way I'd go - using macros we get the entire program
> flow listed in one file, vectors.S.

Yeah, that's certainly one way to do it.  This is actually one of my
biggest complaints about eCos.  There are so many macros everywhere that
it's very difficult to follow program flow.  I realize this is done mostly
for making everything generic and portable but it doesn't make it easy to
read.

There seems to be a reset function, exception handling, TLB miss handling,
an interrupt entry, interrupt stack, boot stack and a few other various
items.  The only thing that looks "cross platform" is complete_startup
which looks like it could mostly be done in C anyway.

> Presumably the SH1 has some spare registers that can be used in the
> early exception handling - otherwise you'd be trashing user code's
> state.
> 
> So if possible, I suggest rewriting the exception entry functions to
> be generic for SH1/SH3/SH4. That is, __exception, __tlb_miss,
> and __interrupt. Again assuming the SH1 has these. [if this is not
> possible, we can macro'ize that part of the code as well]

The problem is that the interrupt/exception structure is significantly
different on the SH1.  First of all, there are 256 vectors, one for each
hardware interrupt and and few for exceptions.  There are no priviledge
levels, no banked registers, no MMU, and no cache.

You have one nice interrupt routine and another exception routine.  I need
potentially 256 copies of this routine.  I could do this with a bunch of
macros and a lot of code duplication (not pretty) or possibly have a macro
that saves a little bit of state, calls another routine to save the rest,
and then jumps to the right ISR.  I have to think about this a little bit
more.

> _vsr:
>  hal_cpu_save
>  hal_fpu_save sp
> _vsr_bp_safe:
>  ...
> restore_state:
>  hal_fpu_load sp
>  hal_cpu_load
>  rte
>   nop
> 
> Think that should do it? Happy with this? Let me know if there are
> some things you disagree with - I've never looked at the SH1 and it
> may take more magic than the above.

I think the exception handling on the two different processors are
sufficiently different that this won't work well.  I think we'll end up
with a pile of ifdefs and almost no common code.  The unfortunate thing is
that SH1 and SH2 are pretty much the same and SH3, SH3e, and SH4 are the
same but the two sets are very different from each other.  Maybe we could
have two files: sh1-2vects.S and sh3-4vects.S under arch/common/src and
avoid a bunch of the ifdefs and a code duplication.  Opinions?

Also, If I make a bunch of changes to vectors.S and the sh3 and sh4
specific files, I won't be able to test them.  Can you try it out on
hardware if I send you a diff?  I'm going to try to come up with something
that looks good in the next couple days I hope people can comment on.

Aaron

Re: [ECOS] SH1 port of eCos

[Jonathan Larmour]

Aaron Passey wrote:
> You have one nice interrupt routine and another exception routine.  I need
> potentially 256 copies of this routine.  I could do this with a bunch of
> macros and a lot of code duplication (not pretty) or possibly have a macro
> that saves a little bit of state, calls another routine to save the rest,
> and then jumps to the right ISR.  I have to think about this a little bit
> more.

I don't know the details here, but I think certain GAS constructs may be
useful in this, e.g. paraphrased from the v850 vectors.S

	.macro INTERRUPT
        .org    reset_vector+(0x0010*VECTOR)
        addi    -CYGARC_EXCEPTION_FRAME_SIZE,sp,sp
        st.w    r1,CYGARC_REG_R1[sp]
        movea   VECTOR,r0,r1
        jr      exception
 	.set VECTOR, VECTOR+1
	.endm

and then later:

	.set VECTOR, 8
	.rept CYGNUM_HAL_ISR_COUNT
	INTERRUPT
	.endr

Do you see what this does and how it does it? A small preamble that
identifies the vector in a register, followed by a jump. And all contained
in a macro in a way that is clean, even though CYGNUM_HAL_ISR_COUNT is very
large on the v850, like the SH1.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] SH1 port of eCos

[Aaron Passey]

Yes, this is exactly what I was thinking when I mentioned saving a little
bit of state then jumping to the main interrupt handler.  There is a
problem with the current organization of the SH saved registers if I want
to do this.  The general purpose regs are the last things saved on entry to
an interrupt.  If I change the order, I could reduce the amount of code in
each instantiation of the "INTERRUPT" macro.

On the SH1, an interrupt entry would look something like (this is
completely off the top of my head):

.macro INTERRUPT
	// SR and PC already saved on the stack
	.org	vectors + (12*VECTOR)
	add     #-4, r15	// save a spot for r15(SP)
	mov.l   r14,@-r15	// save a scratch register
	bra	interrupt
	mov	$vec_ ## VECTOR,r14	// store vector for exception handler
	$vec_ ## VECTOR:	// how do you concatenate?
		.long exception_table + (VECTOR << 2)
  	.set VECTOR, VECTOR+1
.endm

FUNC_START(interrupt)
	mov.l   r13,@-r15	// save rest of regs
	// ...
	mov.l   r0,@-r15
	sts.l   pr,@-r15
	sts.l   mach,@-r15
	sts.l   macl,@-r15
	// fixup saved stack pointer here
	// do all the rest of the interrupt code here

	mov.l	$restore_state, r0
	lds	r0,pr
	jmp	r14	// jump to C exception handler
	nop
$restore_state:
	.long restore_state


The stack frame would now look like:
cyg_uint32   mach;                  // Multiply and accumulate - high
cyg_uint32   macl;                  // Multiply and accumulate - low
cyg_uint32   pr;                    // Procedure Reg
cyg_uint32   r[16];                 // Data regs
cyg_uint32   pc;                    // Program Counter
cyg_uint32   sr;                    // Status Reg

And each "INTERRUPT" entry is 12 bytes.  If instead, I did the easy save
everything macro that jumps directly to the C ISR, I'd probably use maybe
100 or so bytes for each and they'd end up a slight bit faster.

All of this, unfortunately, is much messier than what is currently there
for the SH3.  I don't see any way to do this nicely.

Aaron


> Aaron Passey wrote:
> > You have one nice interrupt routine and another exception routine.  I need
> > potentially 256 copies of this routine.  I could do this with a bunch of
> > macros and a lot of code duplication (not pretty) or possibly have a macro
> > that saves a little bit of state, calls another routine to save the rest,
> > and then jumps to the right ISR.  I have to think about this a little bit
> > more.
> 
> I don't know the details here, but I think certain GAS constructs may be
> useful in this, e.g. paraphrased from the v850 vectors.S
> 
> 	.macro INTERRUPT
>         .org    reset_vector+(0x0010*VECTOR)
>         addi    -CYGARC_EXCEPTION_FRAME_SIZE,sp,sp
>         st.w    r1,CYGARC_REG_R1[sp]
>         movea   VECTOR,r0,r1
>         jr      exception
>  	.set VECTOR, VECTOR+1
> 	.endm
> 
> and then later:
> 
> 	.set VECTOR, 8
> 	.rept CYGNUM_HAL_ISR_COUNT
> 	INTERRUPT
> 	.endr
> 
> Do you see what this does and how it does it? A small preamble that
> identifies the vector in a register, followed by a jump. And all contained
> in a macro in a way that is clean, even though CYGNUM_HAL_ISR_COUNT is very
> large on the v850, like the SH1.
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] SH1 port of eCos

[Jesper Skov]

>>>>> "Aaron" == Aaron Passey <aaronp@ngwee.ugcs.caltech.edu> writes:
Aaron> Yeah, that's certainly one way to do it.  This is actually one
Aaron> of my biggest complaints about eCos.  There are so many macros
Aaron> everywhere that it's very difficult to follow program flow.  I
Aaron> realize this is done mostly for making everything generic and
Aaron> portable but it doesn't make it easy to read.

Agree. Makes the learning curve steeper - but it makes for easier
maintainment. And we obviously prefer the latter over the former.

Aaron> There seems to be a reset function, exception handling, TLB
Aaron> miss handling, an interrupt entry, interrupt stack, boot stack
Aaron> and a few other various items.  The only thing that looks
Aaron> "cross platform" is complete_startup which looks like it could
Aaron> mostly be done in C anyway.

The reason it looks the way it does is because it was written for the
SH3. 

But it's no problem to move the exception/interrupt entry points into
the variant HALs. default_vsr handlers should remain in the main code,
but rely on macros for saving away registers as suggested before.

Aaron> I think the exception handling on the two different processors
Aaron> are sufficiently different that this won't work well.  I think
Aaron> we'll end up with a pile of ifdefs and almost no common code.
Aaron> The unfortunate thing is that SH1 and SH2 are pretty much the
Aaron> same and SH3, SH3e, and SH4 are the same but the two sets are
Aaron> very different from each other.  Maybe we could have two files:
Aaron> sh1-2vects.S and sh3-4vects.S under arch/common/src and avoid a
Aaron> bunch of the ifdefs and a code duplication.  Opinions?

Other than the above, I don't see anything but possibly the
CYGARC_SH_SOFTWARE_IP_UPDATE code which needs to be macro'ized.

Yes, this does reduce vectors.S to basically user level ABI code -
which is fine. I don't want two files with the same ABI code.

Aaron> Also, If I make a bunch of changes to vectors.S and the sh3 and
Aaron> sh4 specific files, I won't be able to test them.  Can you try
Aaron> it out on hardware if I send you a diff?  I'm going to try to
Aaron> come up with something that looks good in the next couple days
Aaron> I hope people can comment on.

Sure.

Jesper