C way to daisychain interrupts

C and PASCAL (or any other high-level languages) in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Arne
Atari Super Hero
Atari Super Hero
Posts: 512
Joined: Thu Nov 01, 2007 10:01 am

Re: C way to daisychain interrupts

Postby Arne » Mon Feb 09, 2015 5:58 pm

simonsunnyboy wrote:If this correctly optimizes to a jump it is exactly what I was looking for :) It basically makes use of a function call being last before the return statement is automatically optimized into a jump statement?

I'd estimate it will be assmbled into bsr/jsr i.e. the return address is put onto the stack - and will never be retrieved again. If that doesn't bother you...
The bootloader doesn't care because the whole start-up code (SP setting, copying DATA segment and erasing BSS) is called with that function call.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5103
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: C way to daisychain interrupts

Postby simonsunnyboy » Mon Feb 09, 2015 6:12 pm

Arne wrote:
simonsunnyboy wrote:If this correctly optimizes to a jump it is exactly what I was looking for :) It basically makes use of a function call being last before the return statement is automatically optimized into a jump statement?

I'd estimate it will be assmbled into bsr/jsr i.e. the return address is put onto the stack - and will never be retrieved again. If that doesn't bother you...
The bootloader doesn't care because the whole start-up code (SP setting, copying DATA segment and erasing BSS) is called with that function call.


For interrupts this would be fatal as the stack would grow to neverland...
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
Arne
Atari Super Hero
Atari Super Hero
Posts: 512
Joined: Thu Nov 01, 2007 10:01 am

Re: C way to daisychain interrupts

Postby Arne » Mon Feb 09, 2015 6:20 pm

Then I don't see a solution for your problem. I never used setjmp/longjmp and will never. That's more dangerous as self-modifing code... :lol:
If your GCC supports the "noreturn" attribute you may try this:

Code: Select all

void handler() __attribute__ ((noreturn));
void handler() __attribute__ ((noreturn))
{
   return;
}

And later overwrite the target address as I wrote before. I don't know if it will even compile...
I guess it will prevent pushing the return address onto the stack but anyway: you should investigate that attribute and disassemble the generated code. Unfortunately: not portable.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 5103
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: C way to daisychain interrupts

Postby simonsunnyboy » Mon Feb 09, 2015 7:32 pm

I'll take a look what gcc will actually produce codewise when I find the time.
Simon Sunnyboy/Paradize - http://paradize.atari.org/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

User avatar
shoggoth
Nature
Nature
Posts: 972
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: C way to daisychain interrupts

Postby shoggoth » Mon Feb 09, 2015 7:42 pm

Arne wrote:In his 1st post ssb wrote he pushes the next handler's address onto the stack and calls RTS - not RTE.
Isn't it satisfactory if the last handler in the chain does the RTE?


True - still, GCC doesn't provide us with this option, at least not for the mint-68k port. So the only way that I'm aware of at least is to write an assembly wrapper which saves A0-A1/D0-D1, pushes the address of some prolog code which restores A0-A1/D0-D1 and returns through RTE, and jump directly to the C function in question. Or something along those lines.
Ain't no space like PeP-space.


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 3 guests