Ada Interrupt Tasks - ReadList.com

2 msg	Ada standard elaboration order
2 msg	indirect memory op in SSA
1 msg	missing spec?
1 msg	gcc-4.2-20071017 is now available

Ada Interrupt Tasks
\ Joel Sherrill (17 Oct 2007)

51 msg	gomp slowness
3 msg	Static stack analysis
7 msg	va_list and x86_64 possible bug (?)
1 msg	There is a gentleman that.
2 msg	How do I upgrade gcc/g++ on a Mac
7 msg	Bad unwinder data for __kernel_sigtramp_rt64 in...
3 msg	double gimplification in C++ FE
3 msg	Library not loaded
2 msg	Problem with too many virtual operands ( tree-s...
3 msg	Machine dependent Tree optimization?
1 msg	gcc/doc/md.texi buglet?
14 msg	df_insn_refs_record's handling of global_regs[]
2 msg	gcc inline assembly
1 msg	gcc-4.1-20071015 is now available
1 msg	gcc 2.7.2 intrinsics

Subject:	Ada Interrupt Tasks
Group:	Gcc
From:	Joel Sherrill
Date:	17 Oct 2007

Hi,

I have Ada interrupt tasks that are attached
to real hardware interrupts working for RTEMS.
I based the RTEMS code on the existing code
for VxWorks.

I tried to minimize my modifications since I
could tell that the OS functionality used was
very generic. But since the implementation
in s-interr-vxworks.adb binds directly to VxWorks
specific calls, I had to make an s-interr-rtems.adb
to account solely for API differences. If the
VxWorks code had been implemented with a glue
layer to the VxWorks API, I would not have had
to copy the file in its 1147 line entirety.

I would like to suggest that s-osinte.ad?
or (less desirable) a new package have adapter/facades
to the OS specific routines required to implement
Ada tasks attached to hardware interrupt sources.

I have a list of functionality that would have
to be in the adapter set:

+ simple binary semaphore
- create
- delete
- obtain
- release
- flush
+ hardware interrupts
- maximum hardware interrupts
- connect
- get handler
- set handler
- interrupt number to hardware vector

This functionality must be in a common place so
the s-interr-hwint.adb doesn't have to "with VxWorks"
or "with RTEMS". The names of the new elements
shouldn't reflect either RTEMS or VxWorks. They
are just capabilities that the s-interr-hwint.adb
requires.

Comments and suggestions are welcomed.

--joel