From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Passey To: Jesper Skov Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] SH1 port of eCos Date: Mon, 15 Jan 2001 15:49:00 -0000 Message-id: <20010115234901.E4E05CC001@ngwee.ugcs.caltech.edu> References: X-SW-Source: 2001-01/msg00243.html 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