Georg-Johann Lay <a...@gjlay.de> wrote: > Well, if a Linux programmer comes over and expects anything, ...
That's not my point. My point is that the chosen name bears *neither* any relationship to what a "signal" in a microcontroller environment is (that would be a hardware signal, attaching to an IO pin), *nor* what a seasoned Unix programmer could expect. Consequently, I say it's a misnomer. >> In other words, I think "signal" is a misnomer, and should not have >> existed in the first place. > > It there. It will stay there. We have to live with it. Based on what reasoning? Sometimes it's time to accept something has been a mistake. I'm sure even Marek Michalkiewicz and Denis Chertykov (who introduced the current wording) might agree on it being a misnomer now, 12 years later. > And I still think it's not a misnomer, it's a RTFM. No. Users aren't supposed to use these attributes directly anyway. They are supposed to use the library API provided, and that's what they are doing. (Don't tell me the compiler is usable without the library. Yes, it is, but that's not the typical usage pattern.) Just accusing the users of being too stupid to read the documentation is a lazy path. Please consider the users being our customers, not our enemies, or our students we have to teach good manners. The tools should be a help to them in getting their way through microcontroller- land, rather than teaching them how stupid they are to not grasp the fine-print of the manual. >> Since the invention of the ISR API, users don't seem to have any >> troubles anymore with that. > > I guess this is not because they read the docs, it's just because > they copy-paste ISR and there is no equivalent for INTERRUPT :-/ If they hadn't read the documentation, they would neither have known of the old, dreadful INTERRUPT, nor of the current ISR. So obviously, they *did* read the documentation. The old names have proven to be confusing, and we have to accept this. > I wish I had introduced an error _before_ AVR-LibC started messing > with interrupt+signal... Please get out of your ivory tower, back to the users. They aren't helped by teaching them how to attach half a dozen of attributes to their functions. They are served best by providing them a good and easy to grasp API on interrupt handlers. They don't care whether we implement it with attributes, pragmas, by modifying global variables, whatever, they just want to be able to write the interrupt handlers. The usability of the current ISR implementation has proven to be excellent, and I'm glad Dean Camera crafted the current implementation. > Deprecations are always really inconvenient. Agreed, but sometimes they are worth it. > Why is it interruptible? > Because the user enabler IRQs in the ISR /after/ the prologue)? > Or because there is an SEI emit by the compiler /before/ the prologue? The "interruptible ISR" is meant as a special case where the compiler re-enables interrupts as soon as possible, as part of the prologue (at whatever point appears to be safe to the compiler). The purpose is to be able to gain a few cycles less of interrupt latency to possible other interrupts. Kind of a poor man's way out of the lack of interrupt priorities on classic AVRs. Consequently, on the Xmega, this part of the API is probably not useful anymore. Even for classic AVRs, it's a rare case where it is useful, but there are situations where it counts, and if the compiler doesn't offer it, the only other option for the users would be to resort to assembly. > What if the user wants an atomic prologue but enables interrupts in > the body? This option is always available to the users, without any compiler interaction. The entire point of involving the compiler is to get the SEI out a few cycles before, just in those situations where it is needed. If you don't agree on a better wording of the attribute names, then please, just make "interrupt" being a priority over "signal" in case both are present, so everything will continue the way it used to be. There's more important things to fight than the names of a couple of attributes which are well hidden from the end users anyway. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
