Hello Georg, You are right when you estimate my reply to be a gut feeling. I had not thought of the problem Erik described. And I think Erik really tried it to stumble onto it. I still think it could be solved, but it seems more cumbersome than I expected. I guess it will require another intermediate lexical definition. But I don't think it will be implemented by me anytime soon.
Maarten > hi Maarten, hi Erik, > > thanks a lot by your feedback! Below I got 2 contradicting opinions: if I > understand Erik right, there is no easy fix to this problem and I should > just skip the declaration in the interrupt header file (like for > Raisonance). That will do of course, but it would prohibit 100% > compatibility with the examples and libs provided by STM on their > homepage. So, before I go for this option: Maarten, can you confirm or > reject Eriks statement (in contrast to first gut feeling), i.e. this > wonât be supported by SDCC anytime soon? For your feedback thanks a lot > in advance! > > Georg > >> ------------------------------ >> >> Message: 2 >> Date: Fri, 30 Jan 2015 23:10:07 +0100 (CET) >> From: "Maarten Brock" <sourceforge.br...@dse.nl> >> Subject: Re: [Sdcc-user] SDCC preprocessor issue >> To: sdcc-user@lists.sourceforge.net >> Message-ID: <44569.84.24.237.130.1422655807.squir...@www.dse.nl> >> Content-Type: text/plain;charset=iso-8859-1 >> >> Hi Georg, >> >>>> You forgot the option to modify SDCC so it accepts the __interrupt >>>> keyword either before or after the function :) >>> >>> weeeellll I figured that is not really an option - is it??? >> >> Why would this not be an option? I guess it's not even a big change. Of >> course the parser definition needs to be changed. And that is of course >> something else than writing a preprocessor macro. >> >> If you would like it, the first thing is to file a feature request. And >> if you want it fast, it certainly helps if you try to implement it >> yourself. >> >> Maarten > > >> ------------------------------ >> >> Message: 4 >> Date: Sat, 31 Jan 2015 00:33:11 -0600 (CST) >> From: Erik Petrich <epetr...@ivorytower.norman.ok.us> >> Subject: Re: [Sdcc-user] SDCC preprocessor issue >> To: sdcc-user@lists.sourceforge.net >> Message-ID: >> <alpine.lfd.2.02.1501310000450.22...@jeanette.ivorytower.norman.ok.us> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> On Fri, 30 Jan 2015, Georg Icking-Konert wrote: >> >>> hello all, >>> >>> thanks a lot for your feedback! As for your mails see my comments below >>> >>>> You forgot the option to modify SDCC so it accepts the __interrupt >>>> keyword >>>> either before or after the function :) >>> >>> weeeellll I figured that is not really an option - is it??? >> >> I did try this earlier in the week, but it leads to a number of >> ambiguities in the grammar. The main problem seems to be that a function >> can return a function pointer, so if the interrupt keyword can be either >> before or after the function name/parameters it's unclear whether the >> interrupt should be applied to the returned function pointer or the >> function itself. Of course semantically it makes no sense for an >> interrupt >> function to have any return type but void, but it is not easy to resolve >> this as the parsing stage. >> >>> sorry I probably haven?t made myself clear. The macro INTERRUPT_HANDLER >>> you mention is used for the implementation and works just fine with >>> SDCC. I was referring to the macro INTERRUPT (a few lines below) which >>> is only used for declaration in the ISR header file (see stm8s_it.h). >>> Maybe in the end I have to do the same as for Raisonance, which simply >>> skips the declaration: not nice but works >> >> Okay, I see what you are talking about now. I don't think the >> declaration >> of the functions as interrupt handlers without specifying a vector >> number >> in the ISR header file would do anything useful for SDCC. Following the >> same path as for Raisonance seems the most compatible with SDCC's >> existing >> grammar and interrupt function expectations. >> >> Erik ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
