* [ECOS] SH1 port of eCos @ 2001-01-11 13:02 Aaron Passey 2001-01-12 0:42 ` Jesper Skov 0 siblings, 1 reply; 6+ messages in thread From: Aaron Passey @ 2001-01-11 13:02 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] SH1 port of eCos 2001-01-11 13:02 [ECOS] SH1 port of eCos Aaron Passey @ 2001-01-12 0:42 ` Jesper Skov 2001-01-15 15:49 ` Aaron Passey 0 siblings, 1 reply; 6+ messages in thread From: Jesper Skov @ 2001-01-12 0:42 UTC (permalink / raw) To: Aaron Passey; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] SH1 port of eCos 2001-01-12 0:42 ` Jesper Skov @ 2001-01-15 15:49 ` Aaron Passey 2001-01-15 18:40 ` Jonathan Larmour 2001-01-15 23:55 ` Jesper Skov 0 siblings, 2 replies; 6+ messages in thread From: Aaron Passey @ 2001-01-15 15:49 UTC (permalink / raw) To: Jesper Skov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] SH1 port of eCos 2001-01-15 15:49 ` Aaron Passey @ 2001-01-15 18:40 ` Jonathan Larmour 2001-01-15 20:10 ` Aaron Passey 2001-01-15 23:55 ` Jesper Skov 1 sibling, 1 reply; 6+ messages in thread From: Jonathan Larmour @ 2001-01-15 18:40 UTC (permalink / raw) To: Aaron Passey; +Cc: Jesper Skov, ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] SH1 port of eCos 2001-01-15 18:40 ` Jonathan Larmour @ 2001-01-15 20:10 ` Aaron Passey 0 siblings, 0 replies; 6+ messages in thread From: Aaron Passey @ 2001-01-15 20:10 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Jesper Skov, ecos-discuss 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] SH1 port of eCos 2001-01-15 15:49 ` Aaron Passey 2001-01-15 18:40 ` Jonathan Larmour @ 2001-01-15 23:55 ` Jesper Skov 1 sibling, 0 replies; 6+ messages in thread From: Jesper Skov @ 2001-01-15 23:55 UTC (permalink / raw) To: Aaron Passey; +Cc: Jesper Skov, ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-01-15 23:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-11 13:02 [ECOS] SH1 port of eCos Aaron Passey 2001-01-12 0:42 ` Jesper Skov 2001-01-15 15:49 ` Aaron Passey 2001-01-15 18:40 ` Jonathan Larmour 2001-01-15 20:10 ` Aaron Passey 2001-01-15 23:55 ` Jesper Skov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).