> What's the problem with the interrupt state? The interrupts are
> unconditionally enabled, but since we're in an interrupt handler, they
> were enabled before. There should be no need to save/restore state.
> Any other reason why __interrupt is not suitable for you?
I wouldn't call it a "problem". I think my use cases simply go outside
the simple models.
There are two reasons I care about it
1. I have code that includes routines sometimes called within critical
sections of other code sometimes not, and those routines may also have
their own critical sections.
2. Because I am multi-tasking I sometimes task switch on an interrupt
between a process that had interrupts on, to one which has interrupts off
but voluntarily gave up the processor. In that case my interrupt entry
and exit are intentionally different.
And for the cases where I have to do stuff like ack an IRQ and enable
interrupts I need to control the interrupt state directly.
What I actually use is the same model is pretty much every Unix ever did
(although I need to add IRQ priorities to it now I'm tackling 68000)
irqflags = di();
[code]
irqrestore(irqflags)
and also a function
ei();
Those are tiny bits of Z80 (except for the NMOS Z80 with the irq erratum)
and I can also implement them trivially in other compilers as I'm
building the same core codebase with gcc, cc65, bcc, sdcc.
Hopefully that explains why - but I really don't see it as an sdcc flaw
or weakness - my usage is a special and unusual case. If I was doing the
typical embedded single target programming then the (minus the Z80 NMOS
bug) sdcc would fit perfectly.
Alan
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
