* Elaboration code, aggregates
@ 2021-03-28 19:41 1% Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2021-03-28 19:41 UTC (permalink / raw)
In June 2020, Luke A. Guest was having trouble with getting the compiler
to place constant data into the data section without elaboration code.
https://groups.google.com/g/comp.lang.ada/c/B2NA-qjCJuM/m/4ykywZWZAgAJ
During preliminary work for FSF GCC 11, I found that this ARM interrupt
vector (which used to compile happily without needing elaboration code)
no longer would:
https://github.com/simonjwright/cortex-gnat-rts/blob/master/stm32f4/adainclude/startup.adb#L231
Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
(-9 .. -6 | -4 .. -3 => null, -- reserved
-14 => Dummy_Handler'Access, -- NMI
-13 => HardFault_Handler'Access, -- HardFault
-12 => Dummy_Handler'Access, -- MemManagement
-11 => Dummy_Handler'Access, -- BusFault
-10 => Dummy_Handler'Access, -- UsageFault
-5 => SVC_Handler'Access, -- SVCall
-2 => PendSV_Handler'Access, -- PendSV
-1 => SysTick_Handler'Access, -- SysTick
others => IRQ_Handler'Access)
with
Export,
Convention => Ada,
External_Name => "isr_vector";
pragma Linker_Section (Vectors, ".isr_vector");
and Arduino Due clock startup ddn't:
https://github.com/simonjwright/cortex-gnat-rts/blob/master/arduino-due/adainclude/startup-set_up_clock.adb#L48
PMC_Periph.CKGR_MOR := (KEY => 16#37#,
MOSCXTEN => 1, -- main crystal oscillator enable
MOSCRCEN => 1, -- main on-chip rc osc. enable
MOSCXTST => 8, -- startup time
others => <>);
On investigating, it turns out that FSF GCC 11 **AND** GNAT CE 2020 have
lost the ability to assign aggregates as a whole; instead, they assign
the record components one-by-one.
The reason for the Arduino Due failure is that the PMC hardware requires
that each write to the CKGR_MOR register contain that value of KEY! so
the sequence is
read the register (KEY is always returned as 0)
overwrite the KEY field
write the register back
read the register, KEY is 0
overwrite the MOSCXTEN field
write the register back, KEY is 0 so inoperative
etc (including the 'others => <>' components).
Bug report raised:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802
^ permalink raw reply [relevance 1%]
* Re: How to emulate multiple exports
2020-04-20 6:52 2% ` Jeffrey R. Carter
@ 2020-04-20 20:51 0% ` Jere
0 siblings, 0 replies; 133+ results
From: Jere @ 2020-04-20 20:51 UTC (permalink / raw)
On Monday, April 20, 2020 at 2:52:55 AM UTC-4, Jeffrey R. Carter wrote:
> On 4/20/20 1:53 AM, Jere wrote:
> > I am working in a space constrained environment (256k flash)
> > and I want to try and reuse the same exported function for
> > all of my unused interrupt handlers.
> >
> > procedure Default;
> > procedure Default is
> > begin
> > -- Do some complex stuff;
> > end Default;
>
> Interrupt handling in Ada is defined in ARM C.3
> (http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-C-3.html). The standard
> way to use a single handler for multiple interrupts is to create the handler as
> a library-level parameterless protected procedure with aspect Interrupt_Handler
> set to True. At elaboration, calls to Ada.Interrupts.Attach_Handler attach this
> handler to multiple Interrupt_Ids. No Export is needed.
>
> GNAT is supposed to support Annex C for all targets, so I would expect this to
> work with your setup. Perhaps there is something about your target that prevents
> this approach, but this would be my initial approach to the problem.
>
> --
> Jeff Carter
> "He that hath no beard is less than a man."
> Much Ado About Nothing
> 132
Unfortunately, the runtime I am using doesn't support
protected types and the Ada standard doesn't really
provide any support for interrupts in that arena that
I can tell. A lot of this has to be done
on a platform by platform basis, but I was hoping
that there was a way to at least leverage Export
as that was language defined.
^ permalink raw reply [relevance 0%]
* Re: How to emulate multiple exports
@ 2020-04-20 6:52 2% ` Jeffrey R. Carter
2020-04-20 20:51 0% ` Jere
0 siblings, 1 reply; 133+ results
From: Jeffrey R. Carter @ 2020-04-20 6:52 UTC (permalink / raw)
On 4/20/20 1:53 AM, Jere wrote:
> I am working in a space constrained environment (256k flash)
> and I want to try and reuse the same exported function for
> all of my unused interrupt handlers.
>
> procedure Default;
> procedure Default is
> begin
> -- Do some complex stuff;
> end Default;
Interrupt handling in Ada is defined in ARM C.3
(http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-C-3.html). The standard
way to use a single handler for multiple interrupts is to create the handler as
a library-level parameterless protected procedure with aspect Interrupt_Handler
set to True. At elaboration, calls to Ada.Interrupts.Attach_Handler attach this
handler to multiple Interrupt_Ids. No Export is needed.
GNAT is supposed to support Annex C for all targets, so I would expect this to
work with your setup. Perhaps there is something about your target that prevents
this approach, but this would be my initial approach to the problem.
--
Jeff Carter
"He that hath no beard is less than a man."
Much Ado About Nothing
132
^ permalink raw reply [relevance 2%]
* Re: Understanding GNAT Bare Board Run-time for Cortex-M
@ 2019-04-08 7:46 1% ` Niklas Holsti
0 siblings, 0 replies; 133+ results
From: Niklas Holsti @ 2019-04-08 7:46 UTC (permalink / raw)
On 19-04-08 05:13 , Daniel Way wrote:
> I'm trying to port the bare-board GNAT run-time to a Coretex-M0+ (NXP
> KV11Z7) processor. I'm new to concurrency and have been reading
> through the run-times for the STM32 targets to understand how the
> tasks and protected objects are implemented, however, there seems to
> be a web of dependencies between the different packages and wrappers
> of wrappers of wrappers for types and subprograms.
The wrappers of course try to isolate the target-specific code from the
target-independent code.
> * Is there any tool available to scan through the source code and
> generate a graphical call graph to help visualize the different
> dependencies?
I know of no free tool that generates graphical call-graphs. I've used
the non-graphical call tree information from GPS.
> * Has anyone on the forum successfully ported a bare-board run-time?
> What was your experience and do you have any tips?
In my last project, I ported the small-footprint Ravenscar run-time for
the SPARC architecture from the generic off-the-shelf AdaCore version to
a specific SPARC LEON2 processor embedded in an SoC for processing
satellite navigation signals, the AGGA-4 SoC.
My advice is to first understand the differences between the original
target processor and the new target processor, especially in these areas:
- Basic processor architecture, and especially if there is some
difference in the instruction set or in the sets of registers that must
be saved and restored in a task switch. In my case there was no
difference, so I did not have to modify the task-switch code nor the
Task Control Block structure. For porting across various models of the
same processsor architecture, perhaps the most likely difference is in
the presence or absence of a floating-point unit and dedicated
floating-point registers.
- The HW timers. In my case the RTS used two HW timers, and there were
some differences: the bit-width was different (32 instead of 24) and the
HW addresses and interrupt numbers were different. The corresponding
parts of the RTS had to be adapted, but in my case the changes were
small, and the logic of the code did not change.
- Interrupts and traps. Differences may have to be implemented in the
assembly-language code that initially handles interrupts and traps. In
my case, the architecture was the same (the structure of the trap table
and most of the HW error traps) but the set of external interrupt traps
was different, because of the particular I/O devices available on the
new target. This difference (if any) becomes visible to application
programs through Ada.Interrupts.
- "Console" I/O, usually some form of UART accessible via GNAT.Text_IO.
In my case, the UARTs in the new target were quite different from the
standard LEON2 UARTs, so I had to reimplement the low-level I/O
operations (Put character, Put string, etc.).
- Memory layout. Where in the address space is the ROM (or flash), where
is the RAM, where are the I/O control registers? Any differences in the
layout must be implemented in the linker command script, which in my
case was a file called leon.ld. The Ada RTS code probably does not have
to change for this reason, and did not change in my case.
Once all that is sorted out, you will probably have to modify the
start-up assembly-language code, which in my case was in the file
crt0.S. This deals with HW initialization (clearing registers, stopping
any I/O that might be running, disabling interrupts, etc.) and SW
initialization, which means to set up the stack for the environment task
and then enter the body of that task.
> * Is porting the run-time just a matter of updating the linker, a few
> packages, and a GPR script, or is there some fundamental
> implementation changes to consider?
If you are porting from one implementation of the same architecture to
another (in your case ARM Cortex M<n> with the Thumb-1/2 instruction
sets, if I understand right), IMO it is unlikely that any fundamental
changes are required. However, if there are differences in the
instruction set (with M0+ omitting some instructions available larger
members and perhaps used in the original RTS) be sure to use the correct
target options for the compiler so as to avoid generating code that will
not run on the M0+. If there is a major difference in instruction sets
(say, porting from Thumb-2 to Thumb-1) you will have to review and
perhaps modify all the assembly-language RTS parts, and all
assembly-language code insertions in the Ada RTS code, and all the code
in crt0.S.
HTH. I think others on this group have more experience with ARM Cortex
run-time systems and can probably offer better advice.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 1%]
* Re: Ada in command / control systems
2019-02-26 22:10 0% ` lyttlec
@ 2019-02-26 22:39 0% ` Niklas Holsti
0 siblings, 0 replies; 133+ results
From: Niklas Holsti @ 2019-02-26 22:39 UTC (permalink / raw)
On 19-02-27 00:10 , lyttlec wrote:
> On 2/26/19 10:50 AM, Simon Wright wrote:
>> "J-P. Rosen" <rosen@adalog.fr> writes:
>>
>>> Le 25/02/2019 à 20:21, russ lyttle a écrit :
>>
>>>> Some items need to be specified to be
>>>> allocated to EEPROM, some to RAM, etc.
>>> You can do that with address clauses.
>>
>> The compiler will straightforwardly distinguish between text, read-only,
>> read-write, and bss.
>>
>> If you need more, you can (GNAT) use pragma Linker_Section: for
>> interrupt vectors for an STM32F4,
>>
>> Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
>> (-9 .. -6 | -4 .. -3 => null, -- reserved
>> -14 => Dummy_Handler'Access, -- NMI
>> -13 => HardFault_Handler'Access, -- HardFault
>> -12 => Dummy_Handler'Access, -- MemManagement
>> -11 => Dummy_Handler'Access, -- BusFault
>> -10 => Dummy_Handler'Access, -- UsageFault
>> -5 => SVC_Handler'Access, -- SVCall
>> -2 => PendSV_Handler'Access, -- PendSV
>> -1 => SysTick_Handler'Access, -- SysTick
>> others => IRQ_Handler'Access)
>> with
>> Export,
>> Convention => Ada,
>> External_Name => "isr_vector";
>> pragma Linker_Section (Vectors, ".isr_vector");
>>
>> and then use the linker script to place that section appropriately.
>>
> The "use linker script" part is where I am having difficulty with gnat
> targeting a PC. Haven't tried the STM32F4 yet.
> All I've found so far, including tutorial on AdaCore, apply only to
> Windows and produce errors in Linux.
Simon is talking about targeting embedded, bare metal platforms, where
things like placing certain data or code in EEPROM, or at certain
addresses, make sense. For an OS like Windows or Linux on a PC, usually
there is no EEPROM (accessible to an application), and all special
addreses (such as I/O control registers) are reserved for OS use.
> For example the advice to use
> "-Xlinker -Wl --stack = ..." is Windows only.
Yes, the way you set the stack size of the Ada environment task is
different for each host OS (there was some discussion of this on
comp.lang.ada a while ago, and it was agreed that a portable, standard
method should be defined for Ada, such as using Pragma Storage_Size in
the main subprogram).
For Linux, I believe the environment stack size is not set when linking
the program, but through the shell "ulimit" command when starting the
program.
> We may have to give up and switch back to using Makefile, which
> probably isn't such a bad idea anyway.
I don't see how a Makefile would help with the stack-size setting. It
should be possible to pass all required command-line switches and
arguments through GPS and gprbuild.
I would recommend using a Makefile only if you must run some other tools
in connection with the build. If your build uses only gprbuild or
gnatmake, stick with the GNAT project file, or just with the gnatmake
environment variables (ADA_INCLUDE_PATH, ADA_OBJECTS_PATH).
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* Re: Ada in command / control systems
2019-02-26 15:50 1% ` Simon Wright
@ 2019-02-26 22:10 0% ` lyttlec
2019-02-26 22:39 0% ` Niklas Holsti
0 siblings, 1 reply; 133+ results
From: lyttlec @ 2019-02-26 22:10 UTC (permalink / raw)
On 2/26/19 10:50 AM, Simon Wright wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> Le 25/02/2019 à 20:21, russ lyttle a écrit :
>
>>> Some items need to be specified to be
>>> allocated to EEPROM, some to RAM, etc.
>> You can do that with address clauses.
>
> The compiler will straightforwardly distinguish between text, read-only,
> read-write, and bss.
>
> If you need more, you can (GNAT) use pragma Linker_Section: for
> interrupt vectors for an STM32F4,
>
> Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
> (-9 .. -6 | -4 .. -3 => null, -- reserved
> -14 => Dummy_Handler'Access, -- NMI
> -13 => HardFault_Handler'Access, -- HardFault
> -12 => Dummy_Handler'Access, -- MemManagement
> -11 => Dummy_Handler'Access, -- BusFault
> -10 => Dummy_Handler'Access, -- UsageFault
> -5 => SVC_Handler'Access, -- SVCall
> -2 => PendSV_Handler'Access, -- PendSV
> -1 => SysTick_Handler'Access, -- SysTick
> others => IRQ_Handler'Access)
> with
> Export,
> Convention => Ada,
> External_Name => "isr_vector";
> pragma Linker_Section (Vectors, ".isr_vector");
>
> and then use the linker script to place that section appropriately.
>
The "use linker script" part is where I am having difficulty with gnat
targeting a PC. Haven't tried the STM32F4 yet.
All I've found so far, including tutorial on AdaCore, apply only to
Windows and produce errors in Linux. For example the advice to use
"-Xlinker -Wl --stack = ..." is Windows only.
We may have to give up and switch back to using Makefile, which
probably isn't such a bad idea anyway.
^ permalink raw reply [relevance 0%]
* Re: Ada in command / control systems
@ 2019-02-26 15:50 1% ` Simon Wright
2019-02-26 22:10 0% ` lyttlec
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2019-02-26 15:50 UTC (permalink / raw)
"J-P. Rosen" <rosen@adalog.fr> writes:
> Le 25/02/2019 à 20:21, russ lyttle a écrit :
>> Some items need to be specified to be
>> allocated to EEPROM, some to RAM, etc.
> You can do that with address clauses.
The compiler will straightforwardly distinguish between text, read-only,
read-write, and bss.
If you need more, you can (GNAT) use pragma Linker_Section: for
interrupt vectors for an STM32F4,
Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
(-9 .. -6 | -4 .. -3 => null, -- reserved
-14 => Dummy_Handler'Access, -- NMI
-13 => HardFault_Handler'Access, -- HardFault
-12 => Dummy_Handler'Access, -- MemManagement
-11 => Dummy_Handler'Access, -- BusFault
-10 => Dummy_Handler'Access, -- UsageFault
-5 => SVC_Handler'Access, -- SVCall
-2 => PendSV_Handler'Access, -- PendSV
-1 => SysTick_Handler'Access, -- SysTick
others => IRQ_Handler'Access)
with
Export,
Convention => Ada,
External_Name => "isr_vector";
pragma Linker_Section (Vectors, ".isr_vector");
and then use the linker script to place that section appropriately.
^ permalink raw reply [relevance 1%]
* Re: Ada.Interrpts.Names
2019-01-29 13:09 2% ` Ada.Interrpts.Names Simon Wright
@ 2019-01-29 14:31 1% ` Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2019-01-29 14:31 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> Your best bet, I'd've thought, would be to write a very simple program
> just to catch that signal (i.e. a PO interrupt handler) using the raw
> integer and see if it works. If it doesn't, you'd probably have a long
> row to hoe. If it does, you can consider whether it's worth the pain of
> editing Ada.Interrupts.Names, otherwise, in your code, (e.g.)
>
> SIGRTMIN : constant Ada.Interrupts.Interrupt_ID := 42; -- or whatever
There may, of course, be some interaction of these signals with the Ada
RTS that explains why they're omitted from Ada.Interrupts.Names.
^ permalink raw reply [relevance 1%]
* Re: Ada.Interrpts.Names
@ 2019-01-29 13:09 2% ` Simon Wright
2019-01-29 14:31 1% ` Ada.Interrpts.Names Simon Wright
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2019-01-29 13:09 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> lyttlec <lyttlec@removegmail.com> writes:
>
>> Under Ubuntu Linux kill -l lists interrupts including SIGRTMIN and
>> SIGRTMAX. However, gnat a-intnam.ads does not have these, nor does the
>> Ada ARM toolchain. Is there a way to use these interrupts?
>
> Looks as though Interrupt_ID is visibly a numeric type, so you could
> just use the number (so long as it's less than (what on Darwin is)
> System.OS_Interface.Max_Interrupt). Whether the RTS will actually
> respond to the signal in a useful way is another matter. Again,
> System.OS_Interface should offer a clue.
Via mail (better to use the newsgroup!) you said
> I tried that and the program in Chap.4 of "Building Parallel,
> Embedded, and Real-Time Applications with Ada" compiles. The question
> is whether or not that is the only thing required to get a meaningful
> response?
> The "C" process is quiet complex.
> In Ada it looks like it might be as simple as editing a-intnam.ads,
> s-osinte.ads, and s-linux.ads. Or a lot more complex, like the methods
> for AVR-Ada.
I don't know, because I don't run Linux as my main development
environment.
Your best bet, I'd've thought, would be to write a very simple program
just to catch that signal (i.e. a PO interrupt handler) using the raw
integer and see if it works. If it doesn't, you'd probably have a long
row to hoe. If it does, you can consider whether it's worth the pain of
editing Ada.Interrupts.Names, otherwise, in your code, (e.g.)
SIGRTMIN : constant Ada.Interrupts.Interrupt_ID := 42; -- or whatever
^ permalink raw reply [relevance 2%]
* Re: Ada.Real_Time.Time_Last
2017-11-18 22:20 0% ` Ada.Real_Time.Time_Last Robert A Duff
@ 2017-11-19 10:50 1% ` Niklas Holsti
0 siblings, 0 replies; 133+ results
From: Niklas Holsti @ 2017-11-19 10:50 UTC (permalink / raw)
On 17-11-19 00:20 , Robert A Duff wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> For various reasons, the developers of the Ada language have seen fit to
>> define in the RM some standard, predefined types for which they have
>> wanted to state the nature of the type, but not its full definition. For
>> example, we have, in package System,
>>
>> subtype Any_Priority is Integer range implementation-defined;
>
> Yes, and Any_Priority'Last is a static expression.
Hm, I found no explicit statement on that in the RM. I assume it follows
from the pragma Pure in package System, yes? On the other hand, there is
an explicit requirement that Default_Bit_Order be static (RM 13.7(35/2)).
> Would it be static in your proposal?
I guess so; in this example, the proposal would only move the actual
range expression to the private part, so I assume pragma Pure would have
the same effect (enforce staticness) in the full declaration of the
semi-private type.
> Programmers need to know the priority range in order to
> write pragmas Priority. So in what sense is this
> "private" information?
Do you write, unportably:
pragma Priority (42);
or do you write, as I do:
Background_Prio : constant Priority := Priority'First;
One_Herz_Prio : constant Priority := Background_Prio + 1;
etc.
and then write
pragma Priority (Background_Prio);
etc.?
>> This would enable all discrete-type operations on the Item type, but
>> would hide (keep private) what sort of discrete type it is, as well as
>> the names of the enumeration literals, if it is implemented as an
>> enumerated type. The RM defines just such a type in Ada.Interrupts:
>>
>> type Interrupt_Id is implementation-defined;
>>
>> with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an
>> implementation-defined discrete type used to identify interrupts."
>
> If Interrupt_Id is an enumeration type (not true for GNAT), you don't
> want to hide the names of the interrupts from clients. If there's a
> Gizmo_Device_Interrupt, then clients want to attach handlers to that by
> name.
The RM defines the package Ada.Interrupts.Names for that (RM C.3.2(26));
it contains a set of definitions of constant Interrupt_Id objects, where
both the names and values of those objects are "implementation-defined".
This proposal would not change that, but these constants would probably
become deferred constants, with their actual values in a private part.
For sure, this proposal is not going to remove all
"implementation-defined" text from the RM. In my mind, that is not the
goal of the proposal; the goal is to give packages more control over the
amount of information they publish about their private types. For
example, I have had cases where I wanted to publish the ability to use a
private type as an array index type, without revealing much more about
the type. The RM is only a good source of examples of types which
should, perhaps, be semi-private in this sense.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 1%]
* Re: Ada.Real_Time.Time_Last
2017-11-18 15:24 1% ` Ada.Real_Time.Time_Last Niklas Holsti
@ 2017-11-18 22:20 0% ` Robert A Duff
2017-11-19 10:50 1% ` Ada.Real_Time.Time_Last Niklas Holsti
0 siblings, 1 reply; 133+ results
From: Robert A Duff @ 2017-11-18 22:20 UTC (permalink / raw)
Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> For various reasons, the developers of the Ada language have seen fit to
> define in the RM some standard, predefined types for which they have
> wanted to state the nature of the type, but not its full definition. For
> example, we have, in package System,
>
> subtype Any_Priority is Integer range implementation-defined;
Yes, and Any_Priority'Last is a static expression.
Would it be static in your proposal?
Programmers need to know the priority range in order to
write pragmas Priority. So in what sense is this
"private" information?
> This would enable all discrete-type operations on the Item type, but
> would hide (keep private) what sort of discrete type it is, as well as
> the names of the enumeration literals, if it is implemented as an
> enumerated type. The RM defines just such a type in Ada.Interrupts:
>
> type Interrupt_Id is implementation-defined;
>
> with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an
> implementation-defined discrete type used to identify interrupts."
If Interrupt_Id is an enumeration type (not true for GNAT), you don't
want to hide the names of the interrupts from clients. If there's a
Gizmo_Device_Interrupt, then clients want to attach handlers to that by
name.
- Bob
^ permalink raw reply [relevance 0%]
* Re: Ada.Real_Time.Time_Last
@ 2017-11-18 15:24 1% ` Niklas Holsti
2017-11-18 22:20 0% ` Ada.Real_Time.Time_Last Robert A Duff
0 siblings, 1 reply; 133+ results
From: Niklas Holsti @ 2017-11-18 15:24 UTC (permalink / raw)
On 17-11-18 16:15 , Jeffrey R. Carter wrote:
> On 11/18/2017 02:18 PM, Niklas Holsti wrote:
>>>>
>>>> type Count is private range <>;
>>
>> This proposal is meant to remove this problem, by letting the
>> programmer provide more information about the private type, in the
>> same way as information can now be provided about generic formal
>> types, to equip those types with predefined operators that can be used
>> in the generic.
>
> If by that you mean that all the operations available for a generic formal
>
> type Count is range <>;
>
> are also available for this private type, then Count'First and
> Count'Last are available, and there's nothing private about the type at
> all. I can't see that this buys anything.
Making Count'First and Count'Last available is part of the goal of the
extension, but the point is that the *expressions* that define their
values would still be *private*, which means that the user of the type
cannot (or is not meant to) depend on those expressions. The user can
access the end result ('First, 'Last) but is not meant to depend on any
other properties of those expressions.
For various reasons, the developers of the Ada language have seen fit to
define in the RM some standard, predefined types for which they have
wanted to state the nature of the type, but not its full definition. For
example, we have, in package System,
subtype Any_Priority is Integer range implementation-defined;
The RM could have said,
type Priority is private;
but then the RM could not have easily expressed the fact that
Any_Priority is divided into two sub-ranges, Priority and
Interrupt_Priority, and the RM would have had to provide several
operations on type Priority, for example relational operators, which are
now implicitly provided by the parent type Integer.
The purpose of the proposal is to replace the "implementation-defined"
in such definitions with some formal, legal expression that has the same
effect. This would make it possible for SW developers to mark such
"implementation-defined" things as private, while still keeping their
code in legal Ada rather than semi-formal RM text.
Perhaps the difference is clearer in the case of a private discrete
type, which could be written (aping the generic formal discrete type
syntax) as:
type Item is private (<>); -- Not current Ada!
This would enable all discrete-type operations on the Item type, but
would hide (keep private) what sort of discrete type it is, as well as
the names of the enumeration literals, if it is implemented as an
enumerated type. The RM defines just such a type in Ada.Interrupts:
type Interrupt_Id is implementation-defined;
with the explanation (RM C.3.2(13)) "The Interrupt_Id type is an
implementation-defined discrete type used to identify interrupts."
I agree that this proposal does not provide major benefits, but on the
other hand it seems to me that it does not require a whole lot of new
compiler mechanisms -- the information available about such
"semi-private" types would be the same as the information available
about generic formal types.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 1%]
* Re: Interrupts & Ravenscar
2017-10-12 15:16 2% Interrupts & Ravenscar Simon Wright
@ 2017-10-21 1:16 0% ` Randy Brukardt
0 siblings, 0 replies; 133+ results
From: Randy Brukardt @ 2017-10-21 1:16 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:lyy3ogbdn2.fsf@pushface.org...
> I'm specifically concerned with the Ravenscar profile. My
> cortex-gnat-rts raises PE when the second PO is initialized; AdaCore's
> ravenscar-full-stm32f4 doesn't - last in wins.
>
> I found this because an AdaCore library had already declared a handler
> for a particular interrupt, and I needed to implement my own
> behaviour. In this case, I could ensure that my handler was used by the
> proper elaboration pragmas. In other circumstances, e.g. attaching the
> wrong interrupt, there might be long and tedious debugging sessions.
>
> The ARM doesn't address this issue (aside from it being illegal in
> Ravenscar to use any subprogram from Ada.Interrupts, which means that
> the only control you have is via the elaboration order).
C.3.1(14.1/3) says it is erroneous if aspect Attach_Handler is not used in a
stack-like fashion. That implies that it ought to work if Attach_Handler is
used twice. C.3.1(10) says that Program_Error is raised if the interrupt
being attached is reserved (so that's probably what happened in your first
case). Otherwise, the last one wins (which is what happened in your second
case).
The intent appears to be that one would use subprograms to find out the
previous handler and then call that (so it isn't lost), but of course you
can't do that in Ravenscar.
In any case, I think the GNAT implementation is correct, in both cases
(although it probably would be frendlier to reserve that interrupt if GNAT
needs it in the Ravenscar version).
Randy.
^ permalink raw reply [relevance 0%]
* Interrupts & Ravenscar
@ 2017-10-12 15:16 2% Simon Wright
2017-10-21 1:16 0% ` Randy Brukardt
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2017-10-12 15:16 UTC (permalink / raw)
Interrupt handlers are specified as protected procedures, e.g.
protected PO is
...
private
...
procedure Handler
with Attach_Handler => Ada.Interrupts.Names.Foo_Interrupt;
end PO;
declared at library level.
What should happen if I also write in the same partition
protected Other_PO is
...
private
...
procedure Handler
with Attach_Handler => Ada.Interrupts.Names.Foo_Interrupt;
end Other_PO;
I'm specifically concerned with the Ravenscar profile. My
cortex-gnat-rts raises PE when the second PO is initialized; AdaCore's
ravenscar-full-stm32f4 doesn't - last in wins.
I found this because an AdaCore library had already declared a handler
for a particular interrupt, and I needed to implement my own
behaviour. In this case, I could ensure that my handler was used by the
proper elaboration pragmas. In other circumstances, e.g. attaching the
wrong interrupt, there might be long and tedious debugging sessions.
The ARM doesn't address this issue (aside from it being illegal in
Ravenscar to use any subprogram from Ada.Interrupts, which means that
the only control you have is via the elaboration order).
I would like to see PE being raised; would this be a suitable candidate
for an implementation restriction?
^ permalink raw reply [relevance 2%]
* how to use "in out" for the "self" parameter in a function in a protected object?
@ 2017-09-16 20:47 2% Frank Buss
0 siblings, 0 replies; 133+ results
From: Frank Buss @ 2017-09-16 20:47 UTC (permalink / raw)
I have a function in a protected object, which needs to change a
variable, but I get this error:
actual for "Self" must be a variable
I assume the reason is, that the implicit "self" parameter for my
function is declared as "in" and not "in out". How can I change it to
"in out"?
Below is the code. The function "Available" for example works, but the
function "Read" causes the error when compiling. Both are accessing the
FIFO variable, "Available" only with a call where the variable is used
as an "in" parameter, but for "Read" I call a function where it is
passed as an "in out" parameter.
with Interfaces; use Interfaces;
with Ada.Interrupts; use Ada.Interrupts;
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
with STM32.USARTs; use STM32.USARTs;
with Ringbuffers;
package Serial_IO is
package FIFO_Package is new Ringbuffers(256, Unsigned_8);
subtype FIFO is FIFO_Package.Ringbuffer;
protected type Serial_Port_Controller
is
procedure Init (Baud_Rate: Baud_Rates);
function Available return Boolean;
function Read return Unsigned_8;
procedure Write (Data : Unsigned_8);
private
procedure Interrupt_Handler;
pragma Attach_Handler (Interrupt_Handler, USART1_Interrupt);
Input : FIFO;
Output: FIFO;
Initialized : Boolean := False;
end Serial_Port_Controller;
Serial : Serial_Port_Controller;
end Serial_IO;
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
^ permalink raw reply [relevance 2%]
* Re: How to check syntax with GNAT?
@ 2017-07-13 5:47 1% ` Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2017-07-13 5:47 UTC (permalink / raw)
Victor Porton <porton@narod.ru> writes:
> $ make my-check
> gnatmake -p -Plibrdf.gpr \
> -XLIBRARY_KIND=static -XOBJ_DIR=./obj-static -
> Xsoversion=librdf-ada.so.2.0.14 -XMODE=Install -XDEBUG_MODE=check
> gnatgcc -c -gnatc -gnat2012 -gnatc rdf-raptor-bnode.adb
> ...
> gprlib rdf-ada.lexch
> ar cr /home/porton/Projects/redland-bindings/ada/lib/librdf-ada.a
> /home/porton/Projects/redland-bindings/ada/obj-static/rdf-raptor-bnode.o
> /home/porton/Projects/redland-bindings/ada/obj-static/rdf-raptor-iostream.o
> ...
> /usr//bin/ar: /home/porton/Projects/redland-bindings/ada/obj-static/rdf-
> raptor-bnode.o: No such file or directory
> gprlib: call to archive builder /usr//bin/ar failed
> gprbuild: could not build library for project librdf
> gnatmake: objects up to date.
>
> Why does it attempt to build object files and the library despite of -gnatc
> switch and how to make it not to attempt build object files?
It doesn't attempt to build object files; that's why the gprlib call
fails. It does build .ali files, though.
You can get gnatmake (actually, gprbuild) to stop after the compilation
by using its -c flag:
lockheed:test-stm32f4 simon$ gnatmake -p -P testbed -c -cargs -gnatc
Setup
[mkdir] object directory for project Testbed
Compile
[Ada] testbed.adb
[Ada] containing.adb
[Ada] dispatching.adb
[Ada] floating_point.adb
[Ada] heartbeat.adb
[Ada] interrupts.adb
interrupts.adb:44:09: (style) bad casing of "Handler" declared at line 41
[Ada] iteration.adb
[Ada] last_chance_handler.adb
[Ada] so.adb
[Ada] streams.adb
[Ada] strings.adb
[Ada] memory_streams.adb
lockheed:test-stm32f4 simon$ ls .build/*.o
ls: .build/*.o: No such file or directory
(the style warning is a compiler bug that I haven't reported yet!)
I say above "gnatmake (actually, gprbuild)" because nowadays (GCC 7, not
GCC 6) gnatmake checks whether gprbuild is available and execs it if so.
I do checks like this in the editor, because why wait to check the
closure rather than checking the change you just made? (of course this
isn't totally effective for spec changes). But, I have it (Emacs
ada-mode) set up to actually compile the unit being edited, by
'(ada-prj-default-check-cmd
"gprbuild -c -u -f -gnatc -p -P ${gpr_file} ${full_current}")
because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66162#c3 .
^ permalink raw reply [relevance 1%]
* Re: Precondition on protected entry
2016-10-11 17:02 1% Precondition on protected entry Simon Wright
@ 2016-10-12 16:07 1% ` Stephen Leake
0 siblings, 0 replies; 133+ results
From: Stephen Leake @ 2016-10-12 16:07 UTC (permalink / raw)
On Tuesday, October 11, 2016 at 3:29:47 PM UTC-5, Simon Wright wrote:
> I have this (Ravenscar, STM32F4) code:
>
I modified it slightly to compile with Windows GNAT GPL 2016:
with Ada.Interrupts.Names;
with System;
package Timer_Handler is
protected Timer_Handler
with Interrupt_Priority => System.Interrupt_Priority'Last
is
entry Wait
with Pre => Running;
procedure Start_Waiting (For_Interval : Duration)
with Pre => For_Interval <= 0.010_000 and not Running;
function Running return Boolean;
private
procedure Handler
with
Attach_Handler => Ada.Interrupts.Names.SIGFPE;
Triggered : Boolean := False;
Is_Running : Boolean := False;
end Timer_Handler;
end Timer_Handler;
package body Timer_Handler is
protected body Timer_Handler is
entry Wait
when Standard.True
is
begin
null;
end Wait;
procedure Start_Waiting
(For_Interval : Duration)
is
begin
null;
end Start_Waiting;
function Running return Boolean is
begin
return Is_Running;
end Running;
procedure Handler
is
begin
null;
end Handler;
end Timer_Handler;
end Timer_Handler;
gnatmake timer_handler.adb
no errors.
So this looks like a problem with the cross target only?
^ permalink raw reply [relevance 1%]
* Precondition on protected entry
@ 2016-10-11 17:02 1% Simon Wright
2016-10-12 16:07 1% ` Stephen Leake
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2016-10-11 17:02 UTC (permalink / raw)
I have this (Ravenscar, STM32F4) code:
protected Timer_Handler
with Interrupt_Priority => System.Interrupt_Priority'Last - 1
is
entry Wait
with Pre => Running;
procedure Start_Waiting (For_Interval : Duration)
with Pre => For_Interval <= 0.010_000 and not Running;
function Running return Boolean;
private
procedure Handler
with
Attach_Handler => Ada.Interrupts.Names.TIM8_TRG_COM_TIM14_Interrupt;
Triggered : Boolean := False;
Is_Running : Boolean := False;
end Timer_Handler;
and GNAT GPL 2016 says
19. protected Timer_Handler
20. with Interrupt_Priority => System.Interrupt_Priority'Last - 1
21. is
22. entry Wait
23. with Pre => Running;
|
>>> "Running" is undefined
Is this a compiler bug, or is there something in e.g. ARM 6.1.1 that
I've missed?
^ permalink raw reply [relevance 1%]
* GNAT bug with protected procedure interrupt handler
@ 2016-06-25 2:40 1% Daniel King
0 siblings, 0 replies; 133+ results
From: Daniel King @ 2016-06-25 2:40 UTC (permalink / raw)
I'm working on a project using GNAT GPL 2016 and AdaCore's ravenscar-sfp-stm32f4 runtime and I am encountering GNAT bugs when using the Attach_Handler aspect/pragma on a protected procedure.
More specifically, given the following (trivial) code:
with Ada.Interrupts.Names;
with System;
package IRQ_Test
is
protected type IRQ_Test_Type
is
procedure Handle_IRQ
with Attach_Handler => Ada.Interrupts.Names.RTC_Interrupt;
end IRQ_Test_Type;
end IRQ_Test;
I encounter the following GNAT bug message:
+===========================GNAT BUG DETECTED==============================+
| GPL 2016 (20160515-49) (arm-eabi) Program_Error sem_type.adb:814 explicit raise|
| Error detected at irq_test.ads:6:4 |
| Please submit a bug report by email to report@adacore.com. |
| GAP members can alternatively use GNAT Tracker: |
| http://www.adacore.com/ section 'send a report'. |
| See gnatinfo.txt for full info on procedure for submitting bugs. |
| Use a subject line meaningful to you and us to track the bug. |
| Include the entire contents of this bug box in the report. |
| Include the exact command that you entered. |
| Also include sources listed below. |
| Use plain ASCII or MIME attachment(s). |
+==========================================================================+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/arch/system.ads
/home/dan/projects/ada/stm32test/irq_test.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/ada.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/a-interr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-interr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-taskin.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/a-unccon.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/s-stoele.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/s-parame.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-tasinf.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-taspri.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-osinte.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-multip.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/s-bb.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-arch/s-bbpara.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/interfac.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/i-stm32.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/i-stm32-rcc.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/i-bit_types.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/s-stm32.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/s-bbbopa.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/s-bbmcpa.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/bsp/i-stm32-pwr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbthre.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbcppr.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbtime.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbinte.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bcprmu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbthqu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-bbbosu.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-taprob.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-mufalo.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-musplo.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/s-tposen.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-common/a-taside.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/gnarl-bsp/a-intnam.ads
/usr/gnat/arm-eabi/lib/gnat/ravenscar-sfp-stm32f4/common/s-unstyp.ads
If I omit the Attach_Handler line on my original example then there are no errors.
Has anyone else seen this problem, or are able to reproduce it? Have you found a workaround?
Daniel
^ permalink raw reply [relevance 1%]
* ANN: Cortex GNAT RTS 20160522
@ 2016-05-22 14:20 1% Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2016-05-22 14:20 UTC (permalink / raw)
Available at
https://sourceforge.net/projects/cortex-gnat-rts/files/20160522/
This release includes GNAT Ada Run Time Systems (RTSs) based
on FreeRTOS (http://www.freertos.org) and targeted at boards with
Cortex-M3, -M4, -M4F MCUs (Arduino Due from http://www.arduino.org,
the STM32F4-series evaluation boards from STMicroelectronics at
http://www.st.com).
In each case, the board support for the RTS (configuration for size
and location of Flash, RAM; clock initialization; interrupt naming) is
in $RTS/adainclude. Support for the on-chip peripherals is also
included, in Ada spec files generated by SVD2Ada
(https://github.com/AdaCore/svd2ada).
The Ada source is either original or based on FSF GCC (mainly 4.9.1,
some later releases too).
(1) arduino-due is a Ravenscar-style RTOS based on FreeRTOS from
http://www.freertos.org for the Arduino Due.
See arduino-due/COPYING* for licensing terms.
On-chip peripheral support in atsam3x8e/.
Tests in test-arduino-due/.
(2) stm32f4 is a Ravenscar-style RTOS based on FreeRTOS from
http://www.freertos.org for the STM32F4-DISC* board.
See stm32f4/COPYING* for licensing terms.
On-chip peripheral support in stm32f40x/.
Tests in test-stm32f4/.
(3) stm32f429i is a Ravenscar-style RTOS based on FreeRTOS from
http://www.freertos.org for the STM32F429I-DISC* board.
See stm32f429i/COPYING* for licensing terms.
On-chip peripheral support in stm32f429x/.
Tests in test-stm32f429i/.
In this release,
* There is no longer any dependence on the STMicroelectronics'
STM32Cube package.
* The support for on-chip peripherals is limited to the
SVD2Ada-generated spec files. The AdaCore 'bareboard' software
(currently https://github.com/AdaCore/bareboard, but a name change
is under consideration) supports the STM32 line.
* Tasking no longer requires an explicit start
(https://sourceforge.net/p/cortex-gnat-rts/tickets/5/).
* Locking in interrupt-handling protected objects no longer inhibits
all interrupts, only those of equal or lower priority
(https://sourceforge.net/p/cortex-gnat-rts/tickets/18/).
The standard packages included (there are more, implementation-specific,
ones) are:
Ada
Ada.Containers
Ada.Containers.Bounded_Hashed_Maps
Ada.Containers.Bounded_Vectors
Ada.Exceptions
Ada.IO_Exceptions
Ada.Interrupts
Ada.Interrupts.Names
Ada.Iterator_Interfaces
Ada.Real_Time
Ada.Streams
Ada.Synchronous_Task_Control
Ada.Tags
Ada.Task_Identification
Interfaces
Interfaces.C
Interfaces.C.Strings
System
System.Assertions
System.Address_To_Access_Conversions
System.Storage_Elements
GNAT
GNAT.Source_Info
^ permalink raw reply [relevance 1%]
* ANN: Cortex GNAT RTS 20160314
@ 2016-03-14 17:42 1% Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2016-03-14 17:42 UTC (permalink / raw)
At https://sourceforge.net/projects/cortex-gnat-rts/files/20160314/.
This release includes
* an RTS for the Arduino Due, arduino-due, and a minimal BSP,
arduino-due-bsp.
* an RTS for the STM32F429I-DISCO, stm32f429i-disco-rtos, based on
STMicroelectronics' STM32Cube package and FreeRTOS, and a
corresponding partial BSP, stm32f429i-disco-bsp.
* an RTS for the STM32F429I-DISCO, stm32f429i, based on FreeRTOS, with
a set of peripheral definition packages created by SVD2Ada.
In this release,
* the Containers support generalized iteration ("for all E of C
loop"). Note, this is achieved by removing tampering checks. While
tampering errors are rare, it would be as well to check algorithms
using a fully-featured desktop compiler.
The standard packages included (there are more, implementation-specific,
ones) are:
Ada
Ada.Containers
Ada.Containers.Bounded_Hashed_Maps
Ada.Containers.Bounded_Vectors
Ada.Exceptions
Ada.IO_Exceptions
Ada.Interrupts
Ada.Interrupts.Names
Ada.Iterator_Interfaces
Ada.Real_Time
Ada.Streams
Ada.Synchronous_Task_Control
Ada.Tags
Ada.Task_Identification
Interfaces
Interfaces.C
Interfaces.C.Strings
System
System.Assertions
System.Address_To_Access_Conversions
System.Storage_Elements
GNAT
GNAT.Source_Info
^ permalink raw reply [relevance 1%]
* ANN: Cortex GNAT RTS 20160207
@ 2016-02-07 22:45 1% Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2016-02-07 22:45 UTC (permalink / raw)
This release is at Sourceforge[1].
This release includes an RTS for the Arduino Due, arduino-due, and a
minimal BSP, arduino-due-bsp.
For the STM32F429I-DISCO, there is one RTS, stm32f429i-disco-rtos, and
one BSP, stm32f429i-disco-bsp.
In this release,
* the Containers support generalized iteration ("for all E of C
loop"). Note, this is achieved by removing tampering checks. While
tampering errors are rare, it would be as well to check algorithms
using a fully-featured desktop compiler.
* FreeRTOS is configured to detect stack overflow (if it is detected,
the RTS loops inside vApplicationStackOverflowHook()).
The standard packages included (there are more,
implementation-specific, ones) are:
Ada
Ada.Containers
Ada.Containers.Bounded_Hashed_Maps
Ada.Containers.Bounded_Vectors
Ada.Exceptions
Ada.IO_Exceptions
Ada.Interrupts
Ada.Interrupts.Names
Ada.Iterator_Interfaces
Ada.Real_Time
Ada.Streams
Ada.Synchronous_Task_Control
Ada.Tags
Ada.Task_Identification
Interfaces
Interfaces.C
Interfaces.C.Strings
System
System.Assertions
System.Address_To_Access_Conversions
System.Storage_Elements
GNAT
GNAT.Source_Info
The software is supplied built with for debugging (-g) and with suitable
optimisation (-Og), using GNAT GPL 2015 on Mac OS X (it should work
out of the box with a Linux-hosted GNAT GPL 2015 cross-compiler, but
will need recompiling for another compiler version).
[1] https://sourceforge.net/projects/cortex-gnat-rts/files/20160207/
^ permalink raw reply [relevance 1%]
* Re: GNAT GPL 2015 Troubles
2015-06-23 14:07 0% ` Stephen Leake
@ 2015-06-23 17:07 0% ` Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2015-06-23 17:07 UTC (permalink / raw)
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Simon Wright <simon@pushface.org> writes:
>
>> "RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
>>
>>> navigation did not work for me. i browsed and found the files but it
>>> is not ideal. A strong vote for your point about use clauses as well.
>>
>> For RTS components (e.g. Ada.Interrupts.Names.EXTI0_IRQ) I end up in the
>> native RTS. In spite of having the correct GPR loaded.
>
> "gnat list" is used to get the system library; testing with GNAT GPL
> 2014:
>
> with a project file foo.gpr containing
>
> package Builder is
> for Default_Switches ("ada") use ("--RTS=sjlj");
> end Builder;
>
> 'gnat list -v -P foo.gpr' returns the wrong system library.
>
> 'gnat list -v --RTS=sjlj' returns the correct system library.
>
> So the solution is to change gnat-core.el gnat-get-paths-1 to pass
> --RTS=... to 'gnat list', but in a general way.
>
> We could add a project variable 'runtime' (or 'rts'?), with default
> value "zcx".
>
> The gnat tools don't accept --RTS=zcx (at least not with a default
> install), so we have to check for that special case at each use.
Given AdaCore's intention to stop gnat make supporting projects, I
suppose it's hardly surprising that gnat list doesn't understand the
full syntax of projects.
GCC 5.1.0 and GNAT GPL 2015 behave the same way as you report.
I'd prefer 'runtime' (or 'rts') to have default value nil. Or am I
thinking of the corresponding elisp custom setting?
^ permalink raw reply [relevance 0%]
* Re: GNAT GPL 2015 Troubles
2015-06-21 16:21 1% ` Simon Wright
@ 2015-06-23 14:07 0% ` Stephen Leake
2015-06-23 17:07 0% ` Simon Wright
0 siblings, 1 reply; 133+ results
From: Stephen Leake @ 2015-06-23 14:07 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> "RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
>
>> navigation did not work for me. i browsed and found the files but it
>> is not ideal. A strong vote for your point about use clauses as well.
>
> For RTS components (e.g. Ada.Interrupts.Names.EXTI0_IRQ) I end up in the
> native RTS. In spite of having the correct GPR loaded.
"gnat list" is used to get the system library; testing with GNAT GPL
2014:
with a project file foo.gpr containing
package Builder is
for Default_Switches ("ada") use ("--RTS=sjlj");
end Builder;
'gnat list -v -P foo.gpr' returns the wrong system library.
'gnat list -v --RTS=sjlj' returns the correct system library.
So the solution is to change gnat-core.el gnat-get-paths-1 to pass
--RTS=... to 'gnat list', but in a general way.
We could add a project variable 'runtime' (or 'rts'?), with default
value "zcx".
The gnat tools don't accept --RTS=zcx (at least not with a default
install), so we have to check for that special case at each use.
--
-- Stephe
^ permalink raw reply [relevance 0%]
* Re: GNAT GPL 2015 Troubles
@ 2015-06-21 16:21 1% ` Simon Wright
2015-06-23 14:07 0% ` Stephen Leake
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2015-06-21 16:21 UTC (permalink / raw)
"RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
> navigation did not work for me. i browsed and found the files but it
> is not ideal. A strong vote for your point about use clauses as well.
For RTS components (e.g. Ada.Interrupts.Names.EXTI0_IRQ) I end up in the
native RTS. In spite of having the correct GPR loaded.
> Simon Another question - do you have any examples that work with AHB2?
> i am not able get the AHB2 peripherals to work at all.
No, only AHB1, sorry. Aside from RCC, that is, and I'm only using the
STM32Cube interface for that.
> also - is there a way you can write up the process of setting up a zfp
> for say TMSC123 or some other such Cortex core?
ZFP should be easy enough per se, the problem would be the board setup
and clock configuration; the clock configuration seems to be
manufacturer-specific?
Would Maciej's book help?
http://www.lulu.com/shop/maciej-sobczak/ada-and-spark-on-arm-cortex-m/paperback/product-22195745.html
http://inspirel.com/articles/Ada_On_Cortex.html
^ permalink raw reply [relevance 1%]
* GNAT GPL 2015 Troubles
@ 2015-06-20 18:38 1% RasikaSrinivasan
0 siblings, 1 reply; 133+ results
From: RasikaSrinivasan @ 2015-06-20 18:38 UTC (permalink / raw)
all
I upgrade my gnat to GPL 2015 on windows. I use both the Windows native version as well as the ARM elf hosted on Windows. gnat GPL 2014 worked just fine in this configuration except for some minor issues.
Several things are no longer working for me and I am at a loss to find the best way to fix it:
a. Used to be able to ask GPS for help with predefined packages like so :
From GPS, Help \ GNAT runtime \ Ada \ Text_io
- this would give me the spec for the package and I could browse the spec
I am no longer able to do this. In particular this is a problem for
packages like Ada.Interrupts.Names
b. It would appear that intellisense for predefined packages don't work anymore.
c. I don't have to specify the location of the profile for ARM targets (this is great) but I am not sure which profile the system is using. browsing the directories there appear to be 2 ravenscar profiles being installed.
Seeking some pointers on any of the above.
thanks, srini
^ permalink raw reply [relevance 1%]
* Re: longest path through a task
2015-05-28 17:52 1% ` Simon Wright
@ 2015-05-28 18:12 0% ` jan.de.kruyf
0 siblings, 0 replies; 133+ results
From: jan.de.kruyf @ 2015-05-28 18:12 UTC (permalink / raw)
On Thursday, May 28, 2015 at 7:52:55 PM UTC+2, Simon Wright wrote:
>
> I have been accused of terseness, sorry
It is an occupational disease, ask my wife.
> This is a Ravenscar runtime; the C interrupt handler has to invoke the
> Ada handler, which was registered by the Ada runtime when it saw a PO
> like
>
> protected Button
> with
> Interrupt_Priority => System.Interrupt_Priority'First
> is
> entry Wait_For_Trigger;
> private
> Triggered : Boolean := False;
> procedure Handler;
> pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
> end Button;
>
> and I started timing in Button.Handler.
>
> The corresponding task called Button.Wait_For_Trigger and I ended timing
> immediately on return.
Thanks, I think I remember coming to 5 usecs from glancing through the code, so it is even worse than that.
According to the gnat ravenscar profile they need that extra code layer to do things with locks and threads, but I could not tell you what anymore. I just cut my losses as explained above.
Here is the link to Matteo's page with the research papers on the subject.
http://inf.ethz.ch/personal/corti/
cheers,
j.
^ permalink raw reply [relevance 0%]
* Re: longest path through a task
@ 2015-05-28 17:52 1% ` Simon Wright
2015-05-28 18:12 0% ` jan.de.kruyf
0 siblings, 1 reply; 133+ results
From: Simon Wright @ 2015-05-28 17:52 UTC (permalink / raw)
jan.de.kruyf@gmail.com writes:
> On Thursday, May 28, 2015 at 6:37:28 PM UTC+2, Simon Wright wrote:
>
>>
>> > I dumped the multithread stuff and made a single-thread / multitask
>> > runtime (slow in Ada unfortunately, but not as slow as multi-threading
>> > and interrupts. The Ravenscar runtime tries to be everything for
>> > everybody).
>>
>> Just did some measurements (clumsily) using the Cortex-M4 counter as in
>> [1], and from entering the Ada handler to the triggered task starting to
>> execute averaged at 1200 cycles (6.7 us) with -Og, 1070 cycles (5.9 us)
>> with -O2. There is some code in the C handler to redirect to the Ada
>> handler: see [2], starting at line 236.
>>
>> I wrote the C handling using weak symbols, so there's no reason (that I
>> can see) why an interrupt that needed better performance shouldn't hook
>> in directly, avoiding the Ada RTS; not so obvious how it would then
>> communicate with the rest of the code.
>>
>> [1] http://stackoverflow.com/a/19124472
>> [2]
>> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-rtos/src/stm32f4xx_it.c
>
> I lost you a bit here Simon, your thinking is way ahead of your
> fingers :) I guess. or I am not familiar with your terminology. (more
> than likely)
I have been accused of terseness, sorry
> Is this interrupt latency? or software interrupt latency?
> Are you running multi threaded? are you triggering a task in this
> thread to run in that thread?
> Is this including your C runtime?
This is a Ravenscar runtime; the C interrupt handler has to invoke the
Ada handler, which was registered by the Ada runtime when it saw a PO
like
protected Button
with
Interrupt_Priority => System.Interrupt_Priority'First
is
entry Wait_For_Trigger;
private
Triggered : Boolean := False;
procedure Handler;
pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
end Button;
and I started timing in Button.Handler.
The corresponding task called Button.Wait_For_Trigger and I ended timing
immediately on return.
^ permalink raw reply [relevance 1%]
* Re: GNAT stm34f4 zfp question.
@ 2015-03-18 17:58 2% ` Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2015-03-18 17:58 UTC (permalink / raw)
Simon Wright <simon@pushface.org> writes:
> And even then I'm concerned about multiplexed GPIO interrupts; as I
> understand it, there is only one EXTI0 interrupt, corresponding to pin
> 0 on any GPIO, so if you need more than one pin 0 interrupt you'll
> need to manage all of them in one super-handler, or arrange to chain
> handlers (which I don't think AdaCore's RTS supports??)
Somewhat clearer about this now!
There are 16 GPIO-related interrupt lines, corresponding to the 16 bits
in a GPIO register.
Each line is associated with one GPIO (the default is GPIOA).
Each line can have interrupts enabled (and/or events???)
Lines 0..4 have their own interrupts, EXTI0_IRQ to EXTI4_IRQ.
Lines 5..9 are multiplexed to one interrupt, EXTI9_5_IRQ.
Lines 10..15 are multiplexed to one interrupt, EXTI15_10_IRQ.
So pin PC11 (GPIOC, bit 11), which is one of the unassigned pins on the
STM32F429I Disco, can be interrupt-enabled (in which case no other
GPIO's pin 11 can be interrupt-enabled) and will generate
EXTI15_10_IRQ. If interrupts are required on lines 10, 12, 13, 14, or 15
(which can each be associated with different GPIOs) then the handler for
EXTI15_10_IRQ will have to determine which is which.
At the moment I'm toying with mechanical translation of the STMCube
stm32f429xx.h (using -fdump-ada-spec and a sed script), and have the
code below, which is fairly ugly, rather like the C equivalent. I could
copy AdaCore's design (not the code, of course!) which handles multi-bit
fields much better, but I'm looking for a mechanical translation at this
stage.
with Ada.Interrupts.Names;
with Interfaces;
with System;
with stm32f429xx_h; use stm32f429xx_h;
package body Button is
-- We're going to use a pin on the left-hand side of the board:
-- P1/44 is PC11.
protected B
with
Interrupt_Priority => System.Interrupt_Priority'First is
entry Wait_For_Trigger;
private
Triggered : Boolean := False;
procedure Handler;
pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI15_10_IRQ);
end B;
procedure Wait_For_Button_Release is
begin
B.Wait_For_Trigger;
end Wait_For_Button_Release;
protected body B is
entry Wait_For_Trigger when Triggered is
begin
Triggered := False;
end Wait_For_Trigger;
procedure Handler is
use type Interfaces.Unsigned_32;
begin
if (EXTI.PR and EXTI_PR_PR11) /= 0 then
Triggered := True;
EXTI.PR := EXTI_PR_PR11; -- clear the interrupt by *writing* 1
else
raise Program_Error with "unexpected interrupt";
end if;
end Handler;
end B;
procedure Initialize is
use type Interfaces.Unsigned_32;
begin
-- First, we need to enable GPIOC's clock.
RCC.AHB1ENR := RCC.AHB1ENR or RCC_AHB1ENR_GPIOCEN;
-- Don't need to configure bit 11 as an input, because that's
-- the default.
-- Don't need to configure OTYPER, because the pin is an input.
-- Don't need to configure OSPEEDR, because the pin is an input.
-- Configure PUPDR for pull-up (AdaCore have no-pull?)
declare
Pull_Register : Interfaces.Unsigned_32;
begin
Pull_Register := GPIOC.PUPDR;
Pull_Register := Pull_Register and not GPIO_PUPDR_PUPDR11;
Pull_Register := Pull_Register or GPIO_PUPDR_PUPDR11_0;
GPIOC.PUPDR := Pull_Register;
end;
-- Enable SYSCFG's clock.
RCC.APB2ENR := RCC.APB2ENR or RCC_APB2ENR_SYSCFGEN;
-- Then, configure SYSCFG_EXTICR3[12:15] (pin 11) for GPIOC.
declare
Exti_Register : Interfaces.Unsigned_32;
begin
Exti_Register := SYSCFG.EXTICR (2); -- C indexing!
Exti_Register := Exti_Register and not SYSCFG_EXTICR3_EXTI11;
Exti_Register := Exti_Register or SYSCFG_EXTICR3_EXTI11_PC;
SYSCFG.EXTICR (2) := Exti_Register;
end;
-- Then, configure EXTI on pin 11 for rising-edge (button-release)
EXTI.RTSR := EXTI.RTSR or EXTI_RTSR_TR11;
-- and enable interrupts on pin 11.
EXTI.IMR := EXTI.IMR or EXTI_IMR_MR11;
end Initialize;
begin
Initialize;
end Button;
^ permalink raw reply [relevance 2%]
* Re: gnat ARM - predefined packages
@ 2015-01-28 17:30 1% ` RasikaSrinivasan
0 siblings, 0 replies; 133+ results
From: RasikaSrinivasan @ 2015-01-28 17:30 UTC (permalink / raw)
Eventually I found the file (spec for Ada.Interrupts.Names) on my system. It is not in the directory tree where I usually expect. There is a dir called "gnat" in the tree and there is an adainclude and adalib under that. This is where I found the RTS and the specific file.
I don't have the exact dir spec now but I can dig it up later in the night.
It would appear that several other such commands also search in the wrong places. For example the pretty print command from GPS did not work because it could not locate several required specs. (I had with'ed Ada.Real_Time).
I suspect this will work better with the next GPL version - as indicated in the reply I received from adacore.
cheers, srini
^ permalink raw reply [relevance 1%]
* Re: gnat ARM - predefined packages
2015-01-27 16:09 2% gnat ARM - predefined packages RasikaSrinivasan
2015-01-27 16:49 0% ` Bob Duff
@ 2015-01-27 16:49 0% ` Simon Wright
1 sibling, 1 reply; 133+ results
From: Simon Wright @ 2015-01-27 16:49 UTC (permalink / raw)
"RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
> Some clarifications please:
>
> I am using gnat for ARM - having reasonable success with the STM32F4
> discovery board.
There's the RTS that AdaCore provide with their cross compiler, which
includes packages like STM32F4.GPIO, and the RTS that I've been working
on. I think you're using the former.
> I would like to know:
>
> - The example project contains an import as follows:
>
> -- file: registers.ads
> GPIOD : GPIO_Register with ... ;
> pragma Import(Ada,GPIOD) ;
>
> where is this object GPIOD getting imported from?
The actual code is
GPIOD : GPIO_Register with
Volatile,
Address => System'To_Address (GPIOD_Base);
pragma Import (Ada, GPIOD);
(GPIO_Register comes from package STM32F4.GPIO: I'm surprised that
AdaCore use 'use' like this, it's quite unnecessary here).
The point of the pragma Import is to prevent any initialization that the
compiler might do on the object. I don't think that there is any in this
case, but consider an access variable: the default initialization is to
set it to null, which you certainly don't want to do to a hardware
register unless you ask for it.
> I am looking to use GPIOB and GPIOC. how can i import those?
exactly as GPIOD; the corresponding _Base declarations are in package
STM32F4.
> - the spec of Ada.Interrupts.Names so I know how to attach new
> interrupt handlers. (Example project provides
> Ada.Interrupts.Names.EXTIO_Interrrupt)
This is a-intnam.ads in your RTS's adainclude/ directory.
If you're looking at AdaCore's RTS, there's an _extremely_ misleading
comment about Interrupt_ID 0 being reserved (well, I was misled; it
probably doesn't matter to you).
> - Is it possible to install native gnat on the same Windows system and
> produce executables for both the native and the ARM targets?
I can't speak for GNAT GPL on Windows, but it would be completely normal
to have the native compiler installed first, then install the
cross-compiler on top of it (THEY MUST BE THE SAME VERSION). In fact
don't you need to? does the cross compiler include all the tools,
e.g. gprbuild, GPS?
> - Is it possible to use packages such as Ada.Containers in the
> embedded target?
Probably not; the AdaCore RTS doesn't support controlled types, my RTS
doesn't (yet) include controlled types or allocators or streams, nor
does it allow dispatching (so no classwide types).
^ permalink raw reply [relevance 0%]
* Re: gnat ARM - predefined packages
2015-01-27 16:09 2% gnat ARM - predefined packages RasikaSrinivasan
@ 2015-01-27 16:49 0% ` Bob Duff
2015-01-27 16:49 0% ` Simon Wright
1 sibling, 0 replies; 133+ results
From: Bob Duff @ 2015-01-27 16:49 UTC (permalink / raw)
"RasikaSrinivasan@gmail.com" <RasikaSrinivasan@gmail.com> writes:
> - the spec of Ada.Interrupts.Names so I know how to attach new interrupt
> handlers. (Example project provides Ada.Interrupts.Names.EXTIO_Interrrupt)
Look at the file a-intnam.ads in the adainclude directory of your
compiler installation. For example, on my native linux machine,
I have lib/gcc/x86_64-pc-linux-gnu/4.9.3/adainclude/a-intnam.ads.
Yours will have a similar-but-different name.
> - Is it possible to install native gnat on the same Windows system and produce
> executables for both the native and the ARM targets?
Yes, you can install as many versions of GNAT as you like.
- Bob
^ permalink raw reply [relevance 0%]
* gnat ARM - predefined packages
@ 2015-01-27 16:09 2% RasikaSrinivasan
2015-01-27 16:49 0% ` Bob Duff
2015-01-27 16:49 0% ` Simon Wright
0 siblings, 2 replies; 133+ results
From: RasikaSrinivasan @ 2015-01-27 16:09 UTC (permalink / raw)
Some clarifications please:
I am using gnat for ARM - having reasonable success with the STM32F4 discovery board.
I would like to know:
- The example project contains an import as follows:
-- file: registers.ads
GPIOD : GPIO_Register with ... ;
pragma Imp\x10oft(Ada,GP\x10IOD) ;
where is this object GPIOD getting imported from?
I am looking to use GPIOB and GPIOC. how can i import those?
- the spec of Ada.Interrupts.Names so I know how to attach new interrupt handlers. (Example project provides Ada.Interrupts.Names.EXTIO_Interrrupt)
- Is it possible to install native gnat on the same Windows system and produce executables for both the native and the ARM targets?
- Is it possible to use packages such as Ada.Containers in the embedded target?
thanks for pointers.
srini
^ permalink raw reply [relevance 2%]
* Use of expression function in protected type
@ 2015-01-20 22:34 1% Simon Wright
0 siblings, 0 replies; 133+ results
From: Simon Wright @ 2015-01-20 22:34 UTC (permalink / raw)
Is it permissible to use an expression function as the completion of a
protected function? (GNAT thinks so).
protected Button
is
function Current_Index return Interval_Index;
private
Index : Interval_Index := 0;
procedure Handler;
pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
end Button;
and then
protected body Button is
function Current_Index return Interval_Index is (Index); -- <<<<<<<<
procedure Handler is
begin
HAL_GPIO_EXTI_IRQHandler (16#0001#);
Index := Index + 1;
end Handler;
end Button;
ARM 6.1(30) distinguishes an expression_function_declaration from a
subprogram_declaration.
6.8(4) allows an expression_function_declaration to be a completion.
9.4(8) says a protected_operation_item can be, inter alia, a
subprogram_declaration or a subprogram body. (subprogram_declaration?
how can that be?)
^ permalink raw reply [relevance 1%]
* Re: STM32F4 Discovery, communication and libraries
2014-08-29 19:41 1% ` Niklas Holsti
@ 2014-08-30 22:00 0% ` Roy Emmerich
0 siblings, 0 replies; 133+ results
From: Roy Emmerich @ 2014-08-30 22:00 UTC (permalink / raw)
On Friday, 29 August 2014 21:41:18 UTC+2, Niklas Holsti wrote:
> On 14-08-29 19:47 , Roy Emmerich wrote:
> > My requirements for dynamic behaviour don't extend so far as to be
> > plug and play ready. What I do want, being a modular hardware
> > platform, is to define, in a configuration file, which hardware
> > modules are plugged into which socket. At start up the supervisor
> > will read this file and instantiate the relevant software modules.
>
> So the Ada program contains SW modules that can handle all known and
> possible hardware modules, but the SW modules are all "data/table
> driven" in the sense that the supervisor can tell each SW module where
> (in which socket, &c) its HW, if any, can be found?
Yes.
> As far as I can see, the only problem that the Ravenscar profile can
> cause for that design is the restriction No_Dynamic_Attachment, which
> means that the connection between an interrupt source and its handler
> must be established at elaboration time, by pragmas or aspects, and not
> dynamically using a call of Ada.Interrupts.Attach_Handler.
>
> In principle, the configuration file could be read at elaboration time,
> and could provide the interrupt numbers to be used in the pragma/aspect
> Attach_Handler. However, doing lots of computation at elaboration time
> can make it tricky for the compiler to find a feasible elaboration order
> (especially if the program has tasks).
>
> The other solution is to attach handlers to all interrupt sources
> statically, but to decide in each handler, at run time, based on the
> configuration data, which SW module is to handle the interrupt, and to
> call the suitable operation from that SW module. A kind of indirection step.
Okay. I think I got that.
> > This device will effectively aggregate the
> > data from all of these devices into one, unified format and send
> > control signals to the generator/inverters.
>
> What is the highest control frequency, or shortest deadline or response
> time, required of the SW?
Okay, some new terminology for me here. For this particular application the response time doesn't have to be very fast (a few seconds). It will be monitoring battery state of charge and active power and turning the generator on or off. I do foresee the need to do reactive power control in larger off-grid systems. For this the phase shift between voltage and current is normally measured by a CE/UL certified power analyser (legal/safety issues) and transmitted, once again, via MODBUS RTU, to my device. As this kind of control is a lot more dynamic, a much faster response time would be required (20 ms thumb suck value, considering one 50 Hz period is 20 ms long). Sorry that it is still so vague. A bit of guidance wouldn't go amiss :)
> > ... making it
> > important for it to be a low power device (e.g. much less than say a
> > beaglebone black embedded Linux board), able to run on a battery for
> > at least 3 days, preferably much more
>
> You may have to modify the Board Support Package and/or the kernel to
> let the processor sleep between clock interrupts. I don't know if the
> AdaCore ARM BSP has that ability off-the-shelf.
Is there an AdaCore ARM BSP yet? I thought this is what Mike Silva was referring to when he said:
"I know that AdaCore is working on comms libraries for the ARM Cortex M parts, but I don't know anything about the projected availability."
assuming this would include stuff such as I2C, SPI, UART, etc. which is normally also part of the BSP?
Speaking of which...in order to feel like I'm making progress and Ada is going to work for me, I really need to get connecting to my peripherals. The only way I can see it happening within the next week is to call the STM C drivers supplied with their BSP. Does this make sense?
> > It must keep accurate time (syncing once a day via GPS)
> > and (periodically/in emergency) make the data available remotely (via
> > GPRS).
>
> Time in a Ravenscar system is provided by the predefined package
> Ada.Real_Time. It is good for relative timing in seconds and ticks, but
> does not provide calendar date and time. Probably you will have to write
> your own Calendar-like package which is synchronised with GPS. Not a
> very big job.
Maybe not if you know what you're doing ;)
This is where it gets a bit vague for me. The STM32F4 has an on-board RTC with full calendar functionality. My thinking is at start up and then once a day to enter a "clock_sync" state, fire up the GPS receiver, somehow sync the processor's RTC and then continue with normal operation. If I need the absolute date/time I can just get it from the RTC, so I don't know why I would want to use the Ada.Calendar functionality in the first place. Could you shed some light on this?
^ permalink raw reply [relevance 0%]
* Re: STM32F4 Discovery, communication and libraries
@ 2014-08-29 19:41 1% ` Niklas Holsti
2014-08-30 22:00 0% ` Roy Emmerich
0 siblings, 1 reply; 133+ results
From: Niklas Holsti @ 2014-08-29 19:41 UTC (permalink / raw)
On 14-08-29 19:47 , Roy Emmerich wrote:
> On Friday, 29 August 2014 15:06:07 UTC+2, Dennis Lee Bieber wrote:
>> It works if the entire system including the "user application"
>> level is built "as one". It is NOT a very dynamic arrangement
>> wherein you may plug in a new sensor and have it magically install
>> itself to some list of sensors to be reported.
>
> My requirements for dynamic behaviour don't extend so far as to be
> plug and play ready. What I do want, being a modular hardware
> platform, is to define, in a configuration file, which hardware
> modules are plugged into which socket. At start up the supervisor
> will read this file and instantiate the relevant software modules.
So the Ada program contains SW modules that can handle all known and
possible hardware modules, but the SW modules are all "data/table
driven" in the sense that the supervisor can tell each SW module where
(in which socket, &c) its HW, if any, can be found?
As far as I can see, the only problem that the Ravenscar profile can
cause for that design is the restriction No_Dynamic_Attachment, which
means that the connection between an interrupt source and its handler
must be established at elaboration time, by pragmas or aspects, and not
dynamically using a call of Ada.Interrupts.Attach_Handler.
In principle, the configuration file could be read at elaboration time,
and could provide the interrupt numbers to be used in the pragma/aspect
Attach_Handler. However, doing lots of computation at elaboration time
can make it tricky for the compiler to find a feasible elaboration order
(especially if the program has tasks).
The other solution is to attach handlers to all interrupt sources
statically, but to decide in each handler, at run time, based on the
configuration data, which SW module is to handle the interrupt, and to
call the suitable operation from that SW module. A kind of indirection step.
> This device will effectively aggregate the
> data from all of these devices into one, unified format and send
> control signals to the generator/inverters.
What is the highest control frequency, or shortest deadline or response
time, required of the SW?
> ... making it
> important for it to be a low power device (e.g. much less than say a
> beaglebone black embedded Linux board), able to run on a battery for
> at least 3 days, preferably much more
You may have to modify the Board Support Package and/or the kernel to
let the processor sleep between clock interrupts. I don't know if the
AdaCore ARM BSP has that ability off-the-shelf.
> It must keep accurate time (syncing once a day via GPS)
> and (periodically/in emergency) make the data available remotely (via
> GPRS).
Time in a Ravenscar system is provided by the predefined package
Ada.Real_Time. It is good for relative timing in seconds and ticks, but
does not provide calendar date and time. Probably you will have to write
your own Calendar-like package which is synchronised with GPS. Not a
very big job.
> Let's be frank. This is not a satellite. I WON'T be doing any
> schedulability analyses.
AFAIK few satellites are subjected to formal schedulability analysis...
typically, some kind of "nominal worst-case scenario" is defined and a
simple computation similar to response-time analysis is used to
demonstrate that all important ("hard real time") tasks are fast enough
in this scenario, and that a reasonable fraction of CPU time is left for
the less urgent tasks.
> Today Ada seems like a very good fit, no?
I think so.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 1%]
* Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.
2013-03-27 14:38 0% ` Simon Clubley
@ 2013-03-27 22:58 0% ` Brian Drummond
0 siblings, 0 replies; 133+ results
From: Brian Drummond @ 2013-03-27 22:58 UTC (permalink / raw)
On Wed, 27 Mar 2013 14:38:23 +0000, Simon Clubley wrote:
> On 2013-03-27, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>
> Oh, sorry, I didn't mean to imply that I was seeing poor code in C as a
> result of marking the type itself as volatile, as I am not.
>> The only case of incorrect code generation seen so far has been where a
>> local procedure has been installed as an interrupt handler, and a local
>> variable (volatile) shared between it and the main.
>> Now it is unclear to me whether a local variable is even permitted to
>> be shared with an interrupt handler - or even if the handler is ever
>> permitted to be a local procedure. (
> Even if it appeared to work, I would be _very_ uncomfortable with the
> idea of a local procedure as a interrupt handler. Interrupt handlers are
> supposed to be a global, not localised, concept able to be executed at
> any time.
Agree absolutely. I have also verified that the AVR-Ada compiler
prohibits local procedures as handlers, and intend to update the MSP
tools accordingly.
>> However my reading of the Ravenscar profile only supports attaching
>> handlers via pragmas, in library level units - calling Ada.Interrupts.*
>> is a Program Error...
> I would need to read the Ravenscar profile in detail, but I thought the
> idea of a pragma based approach was that the vector table was defined
> during linking instead of at runtime.
Exactly.
> If so, I wonder how that would be compatible with the Atmel SAM7S setup
> I describe above. You may need to create a dummy interrupt table during
> linking and have the startup code populate the SAM7S interrupt registers
> from it.
I see no objection to copying a constant array to the actual interrupt
registers during startup, should that be necessary.
- Brian
^ permalink raw reply [relevance 0%]
* Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.
2013-03-27 11:34 1% ` Brian Drummond
@ 2013-03-27 14:38 0% ` Simon Clubley
2013-03-27 22:58 0% ` Brian Drummond
0 siblings, 1 reply; 133+ results
From: Simon Clubley @ 2013-03-27 14:38 UTC (permalink / raw)
On 2013-03-27, Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Tue, 26 Mar 2013 22:38:15 +0000, Simon Clubley wrote:
>> Some specific notes from reading your document:
>>
>> Have you hit any other volatile issues ? In C, I define the object
>> itself, rather than the data type, as volatile. This includes the case
>> when the data type is a struct (used when modelling a register set for a
>> specific peripheral).
>
> This may then be a wider GCC "feature" than MSP430-Ada or even Ada...
> I will have to look into it, to see if I can understand why applying
> volatile to types generates inferior code. In the meantime, since these
> "volatile" pragmas are part of the auto-generated packages, they are
> untidy but they make no extra work.
>
Oh, sorry, I didn't mean to imply that I was seeing poor code in C as a
result of marking the type itself as volatile, as I am not.
In fact, I didn't remember the situation correctly (it's been a while
since I wrote the headers). Although the struct itself is not volatile,
I have marked the individual fields (which represent individual registers)
within the struct as volatile.
> The only case of incorrect code generation seen so far has been where a
> local procedure has been installed as an interrupt handler, and a local
> variable (volatile) shared between it and the main.
>
> Since the frame pointer (to access local variables) is set by the caller,
> and there is no call site, this obviously did not work!
>
> Moving the shared variable to library level (package "shared") worked.
>
> Now it is unclear to me whether a local variable is even permitted to be
> shared with an interrupt handler - or even if the handler is ever
> permitted to be a local procedure. (Ravenscar definitively prohibits the
> latter, rendering local variables moot, but I understand Ada may not).
>
Even if it appeared to work, I would be _very_ uncomfortable with the idea
of a local procedure as a interrupt handler. Interrupt handlers are supposed
to be a global, not localised, concept able to be executed at any time.
To correctly model that reality, they should be in a library level package
if interrupt handlers are implemented in this way.
>> Interrupts are a good example of how a porting document can only provide
>> limited guidance in some areas. In your MSP430 example, you appear to
>> associate the interrupt vector with the routine at link time (I don't
>> know the MSP430; I am just going by your example), yet on a 32-bit
>> traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
>> interrupt handler's address into a interrupt dispatch table at runtime
>> and I need to supply interrupt support code to handle the interrupt.
>
> They are a good example. My current approach is defensible by pointing
> out that the MSP430 vector table is stored in Flash ROM! There is no
> other option for this or the AVR. I don't know if Flash-equipped ARMs
> like TI Stellaris or NXP always support RAM-based interrupt tables or if
> there are ARM targets where you may have to do the same.
>
Interrupt handling is very ARM device specific, although things _appear_
to have standardised somewhat for the Cortex series (which I have no
experience of; I am still using traditional ARM7TDMI/ARM9 boards although
I have some Cortex demo boards sat in the corner at home which I will
get to play with one day :-)).
Most ARM MCUs have a RAM based interrupt table of some sort, although
the Atmel SAM7S has a setup in which you load the interrupt vectors and
interrupt priority into a register space table instead. When you take a
IRQ interrupt exception (ARM exception, not Ada exception) your interrupt
wrapper support code can read the interrupt handler address directly from
the SAM7S Interrupt Vector Register (IVR).
> However my reading of the Ravenscar profile only supports attaching
> handlers via pragmas, in library level units - calling Ada.Interrupts.*
> is a Program Error, so moving one stage above bare metal, there is a
> stage where static vector tables are mandatory, though that wouldn't stop
> you populating them during elaboration if they aren't in ROM.
>
I would need to read the Ravenscar profile in detail, but I thought the
idea of a pragma based approach was that the vector table was defined
during linking instead of at runtime.
If so, I wonder how that would be compatible with the Atmel SAM7S setup
I describe above. You may need to create a dummy interrupt table during
linking and have the startup code populate the SAM7S interrupt registers
from it.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
^ permalink raw reply [relevance 0%]
* Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.
@ 2013-03-27 11:34 1% ` Brian Drummond
2013-03-27 14:38 0% ` Simon Clubley
0 siblings, 1 reply; 133+ results
From: Brian Drummond @ 2013-03-27 11:34 UTC (permalink / raw)
On Tue, 26 Mar 2013 22:38:15 +0000, Simon Clubley wrote:
> On 2013-03-26, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>> On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote:
>>
>>> On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>>> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:
>>>>> You also have no confidence that the model you have built is
>>>>> sufficiently complete to result in a robust port.
>>>>
>>>> What in your view would be required to give you that confidence?
>>> Coherent and structured porting documentation.
>> I admit I am surprised to hear documentation ahead of test. But that
>> makes it all the more worth hearing.
> Both are required, but good documentation is way more important because
> it answers the question "_why_ do we do this ?" but testing can only
> test what has been written _after_ you understand what needs writing in
> the first place.
Thanks. I needed to hear this. I believe I already knew it, but I still
needed to hear it!
> For example, when discussing Ada exception support, a porting document
> should discuss at a conceptual level what is required to implement
> exception support in GNAT hence allowing you to build a model of how a
> exception raised during the execution of user code flows through the
> various levels of the compiler generated code and the RTS and into the
> low-level bits you need to supply.
Not only a good example, but timely!
> (And yes, I know the thesis already touches on some of this, although as
> pointed out already the thesis is about a decade old and is written with
> more of a academic than a practical focus. I am just using exception
> support as a example.)
A comparative study of the report, and Luke's experience, and AVR-Ada etc
would help as a starting point.
> IOW, building a solid model of what is going on in the code base is the
> root stage from which all later stages, including testing, are derived
> from.
>
>> OK, here goes...
>>
>> http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/
>> download
>> And I don't expect many people to actually follow the process at this
>> stage :
> Actually, I would expect to find duplicating the process of building
> this specific compiler from what you have written in this document to be
> rather easy.
Paraphrasing : easy, if you have built compilers before, but tedious.
One of the (very few) interested parties so far, after I pointed him at
the document, still came back and asked "but which packages should I
install?"
> However, your document is more about how to build a specific port,
> ... What it does not discuss is _why_ the
> changes are needed or how those changes fit into the overall GNAT/GCC
> architecture.
I think that's because so far, there really haven't been significant
changes!
Apart from actually *doing* it and documenting the steps, my only
contribution has been the builder for the CPU support packages.
That seems to me (so far) to be successful and much better than a single
*huge* package or header file per processor. It does what the original
includes do (and the AVR-Ada equivalent per-CPU packages do) with about
10% of the source text.
It may be possible to *extract* what I have learned step by step into a
much more compact and therefore more usable design document; I will have
to think about that. (I already know I need to extract the build process!)
However if I am going to move forward I must add alternative RTS
components (which is why I have tried to be explicit that the RTS is a
separate component) and I am leaning towards the Ravenscar profile.
At which point your approach of document first is vitally important.
> A by rote approach can get you quite a bit of the way (assuming a
> similar architecture) but at some point, for example, when you start
> adding in exception support to your new architecture, you need to have a
> model of what is actually going on in GNAT and gcc.
I know so little that the process may involve experiment and document, as
well as review existing sources, then extract into a proper design
document.
> Some specific notes from reading your document:
>
> Have you hit any other volatile issues ? In C, I define the object
> itself, rather than the data type, as volatile. This includes the case
> when the data type is a struct (used when modelling a register set for a
> specific peripheral).
This may then be a wider GCC "feature" than MSP430-Ada or even Ada...
I will have to look into it, to see if I can understand why applying
volatile to types generates inferior code. In the meantime, since these
"volatile" pragmas are part of the auto-generated packages, they are
untidy but they make no extra work.
The only case of incorrect code generation seen so far has been where a
local procedure has been installed as an interrupt handler, and a local
variable (volatile) shared between it and the main.
Since the frame pointer (to access local variables) is set by the caller,
and there is no call site, this obviously did not work!
Moving the shared variable to library level (package "shared") worked.
Now it is unclear to me whether a local variable is even permitted to be
shared with an interrupt handler - or even if the handler is ever
permitted to be a local procedure. (Ravenscar definitively prohibits the
latter, rendering local variables moot, but I understand Ada may not).
It's a grey area since the proper Ada approach to interrupt handlers is
to use protected objects, so clearly the best thing is to support these
instead of obsessing over this bug. However, both AVR-Ada and the Lodz
ARM compiler (B.Horn) use this approach. Today's job is to see if AVR-Ada
shares this defect. If it does, then some way to prevent this error in
the compiler would be desirable.
> Your gnatmake command may appear to be complicated, but it's the kind of
> thing which could easily be turned into a pattern rule in a makefile so
> it would not be high on the list of things I would worry about too much.
My thinking exactly.
Or better, learn to write a .gpr file since Makefiles are the tool of the
devil (precursor of, and presumably the inspiration for the Whitespace
language!)
> Interrupts are a good example of how a porting document can only provide
> limited guidance in some areas. In your MSP430 example, you appear to
> associate the interrupt vector with the routine at link time (I don't
> know the MSP430; I am just going by your example), yet on a 32-bit
> traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
> interrupt handler's address into a interrupt dispatch table at runtime
> and I need to supply interrupt support code to handle the interrupt.
They are a good example. My current approach is defensible by pointing
out that the MSP430 vector table is stored in Flash ROM! There is no
other option for this or the AVR. I don't know if Flash-equipped ARMs
like TI Stellaris or NXP always support RAM-based interrupt tables or if
there are ARM targets where you may have to do the same.
However my reading of the Ravenscar profile only supports attaching
handlers via pragmas, in library level units - calling Ada.Interrupts.*
is a Program Error, so moving one stage above bare metal, there is a
stage where static vector tables are mandatory, though that wouldn't stop
you populating them during elaboration if they aren't in ROM.
> BTW, the complexity of that support code is also directly impacted by if
> you want to do things like priority nesting (my ARM bare metal interrupt
> support code does this).
That will have to come with Ravenscar.
>> And having spent 9 hours yesterday building AVR-Ada 1.2.1 from its "one
>> click" script I know that getting toolchains into that stage is not
>> trivial.
> :-)
Some of my patches to the previous script didn't make it into their
distribution, but other mysteries have also crept into the process :-(
- Brian
^ permalink raw reply [relevance 1%]
* Re: Interrupts handling in ADA
2011-12-12 3:19 0% ` anon
@ 2011-12-13 13:31 0% ` Ada BRL
0 siblings, 0 replies; 133+ results
From: Ada BRL @ 2011-12-13 13:31 UTC (permalink / raw)
On 12 Dic, 03:19, a...@att.net wrote:
> -- Interrupts are not necessary. From you description a simple set of
> -- tasks is all that is needed.
> --
> -- This program outline uses three task to read three sockets and
> -- after pre-processing and verifing data (if needed) passes this
> -- data to a main task. The main task then can continue processing
> -- this data.
> --
> -- Exception handling is limited to Socket error which will cause
> -- that task to die and after reporting to the Main task. Then Main
> -- task uses the abort statement to kill other tasks.
> --
>
> with Ada.Text_IO ;
> with Interfaces ;
> with GNAT.Sockets ;
>
> use Ada.Text_IO ;
> use Interfaces ;
> use GNAT.Sockets ;
>
> procedure v is
>
> localhost : constant Inet_Addr_Type := Inet_Addr ( "127.0.0.1" ) ;
> localport : constant Port_Type := 16#FFF0# ;
>
> task One is
> entry Start ; -- to insure network is operational
> end One ;
>
> task Two is
> entry Start ;
> end Two ;
>
> task Three is
> entry Start ;
> end Three ;
>
> task Main is
> -- accept data from first two tasks.
>
> entry Acknowledge_1 ( Data : Unsigned_32 ) ;
> entry Acknowledge_2 ( Data : Unsigned_32 ) ;
>
> -- accept data from third task only
>
> entry Control ( Data : Character ) ;
>
> -- denotes that network exception has ocurred from one of
> -- the three tasks. The ( 1 .. 3 ) sets a range for
> -- identifing the calling task. Where ( 1 ) is task One,
> -- ( 2 ) is task Two and ( 3 ) is task Three.
>
> entry Dead ( 1 .. 3 ) ;
> end Main ;
>
> --
> -- Task bodies
> --
> task body One is
>
> Socket : Socket_Type ;
> Address : Sock_Addr_Type ;
> Channel : Stream_Access ;
>
> Data : Unsigned_32 ;
>
> begin
> -- Initialize Sockect
>
> Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
> Address.Addr := localhost ;
> Address.Port := localport + 1 ;
> Connect_Socket ( Socket, Address ) ;
> Channel := Stream ( Socket ) ;
>
> accept Start ;
>
> -- Wait for controller to activate
> loop
>
> -- Wait for data.
>
> Unsigned_32'Read ( Channel, Data ) ;
>
> -- Verify or Pre-process data, if needed
>
> -- Send data to main task.
>
> Main.Acknowledge_1 ( Data ) ;
> end loop ;
>
> exception
> when Socket_Error =>
> if Main'Callable then
> Main.Dead ( 1 ) ;
> end if ;
> Close_Socket ( Socket ) ;
> end One ;
>
> task body Two is
>
> Socket : Socket_Type ;
> Address : Sock_Addr_Type ;
> Channel : Stream_Access ;
>
> Data : Unsigned_32 ;
>
> begin
> -- Initialize Sockect
>
> Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
> Address.Addr := localhost ;
> Address.Port := localport + 2 ;
> Connect_Socket ( Socket, Address ) ;
> Channel := Stream ( Socket ) ;
>
> accept Start ;
>
> -- Wait for controller to activate
> loop
>
> -- Wait for data.
>
> Unsigned_32'Read ( Channel, Data ) ;
>
> -- Verify or Pre-process data, if needed
>
> -- Send data to main task.
>
> Main.Acknowledge_2 ( Data ) ;
> end loop ;
>
> exception
> when Socket_Error =>
> if Main'Callable then
> Main.Dead ( 2 ) ;
> end if ;
> Close_Socket ( Socket ) ;
> end Two ;
>
> task body Three is
>
> Socket : Socket_Type ;
> Address : Sock_Addr_Type ;
> Channel : Stream_Access ;
>
> Data : Character ;
>
> begin
> -- Initialize Sockect
>
> Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
> Address.Addr := localhost ;
> Address.Port := localport + 3 ;
> Connect_Socket ( Socket, Address ) ;
> Channel := Stream ( Socket ) ;
>
> accept Start ;
>
> -- Wait for controller to activate
> loop
>
> -- Wait for data.
>
> Character'Read ( Channel, Data ) ;
>
> -- Verify or Pre-process data, if needed
>
> -- Send data to main task.
>
> Main.Control ( Data ) ;
> end loop ;
>
> exception
> when Socket_Error =>
> if Main'Callable then
> Main.Dead ( 3 ) ;
> end if ;
> Close_Socket ( Socket ) ;
> end Three ;
>
> --
> -- Main Task body
> --
> task body Main is
>
> Task_1_Data : Unsigned_32 ;
> Task_2_Data : Unsigned_32 ;
> Task_3_Data : Character ;
> --
> Task_Error : exception ;
>
> begin
> -- preform any initialize
> loop
> select
> accept Acknowledge_1 ( Data : Unsigned_32 ) do
> Task_1_Data := Data ;
> -- process data from task 1
> end Acknowledge_1 ;
> or
> accept Acknowledge_2 ( Data : Unsigned_32 ) do
> Task_2_Data := Data ;
> -- process data from task 2
> end Acknowledge_2 ;
> or
> accept Control ( Data : Character ) do
> Task_3_Data := Data ;
> -- process data from task 3
> end Control ;
> or
> accept Dead ( 1 ) ;
> Put_Line ( "Error has ocurred in Task One" ) ;
> raise Task_Error ;
> or
> accept Dead ( 2 ) ;
> Put_Line ( "Error has ocurred in Task Two" ) ;
> raise Task_Error ;
> or
> accept Dead ( 3 ) ;
> Put_Line ( "Error has ocurred in Task Three" ) ;
> raise Task_Error ;
> end select ;
>
> -- Continue processing with Data from all tasks
>
> end loop ;
>
> exception
> when Task_Error =>
> Put_Line ( "Error has cause this program to die" ) ;
> -- abort all tasks
> abort One ;
> abort Two ;
> abort Three ;
> end Main ;
>
> --
> -- The Main task could start the three child task
> --
>
> begin
>
> -- Verify all task are operational
>
> if not One'Callable then
> Put_Line ( "Error in Task One" ) ;
> abort Two ;
> abort Three ;
> abort Main ;
>
> elsif not Two'Callable then
> Put_Line ( "Error in Task Two" ) ;
> abort One ;
> abort Three ;
> abort Main ;
>
> elsif not Three'Callable then
> Put_Line ( "Error in Task Three" ) ;
> abort One ;
> abort Two ;
> abort Main ;
>
> else
> One.Start ;
> Two.Start ;
> Three.Start ;
> end if ;
>
> exception
> when others =>
> null ;
> end v ;
>
> In <30143086.6.1323549838421.JavaMail.geo-discussion-forums@vbbfq24>, "Ada @ BRL" <ada.brl.2...@gmail.com> writes:
>
>
>
>
>
>
>
> >Hello,
> >I'm an Erasmus student at the University of Bristol - UK and I'm carrying out the work for my master thesis in Computer Engineering.
>
> >I'm programming a multithreading application in C / C++ and ADA.
> >The latter is a completely new language for me...
>
> >The environment of ADA applcation is:
> >I have 4 tasks that execute at the same time:
> >one is the main task,
> >the other three execute a "read" from network (socket) function inside their bodies (on the other side there's the C/C++ application with 3 network sockets).
> >[I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ]
>
> >I want that when new data is available on one or more socket threads, this / these threads somehow notify the main thread that data is arrived and then safely send the data to it.
>
> >I've thought to use the interrupts...because I haven't found any references about the use of "events" in ADA.
> >I've thought to attach three different handler of interrupts into the main task and then to generate the interrupt from the socket task with ada.interrupts.signal.generate_interrupt.
> >Socket 1 will generate interrupt #1, socket 2 -> interrupt #2 and so on.
>
> >May you tell me please if this is the right way to face the problem?
> >I'm not skilled in ada and so there could be other better methods...
>
> >I've used the pragmas attach_handler and interrupt_handler but unfortunately I'm still not able to get all the stuff working...
>
> >I think it's a problem of ADA implementation because:
> >even if I call pragma unreserve_all_interrupts I've found that the function Is_Reserved(Interr_ID) returns FALSE only for this signals IDs: 2(SIGINT), 4(SIGILL), 8(SIGFPE), 11(SISEGV), 15(SIGTERM), 22(SIGABRT).
>
> >I guess that this is the opposite behaviour as I expected...
> >If I try to set an handler to the interrupt say 9, the program cannot start due to this error:
>
> >raised PROGRAM_ERROR : adjust/finalize raised PROGRAM_ERROR: s-interr.adb:343 explicit raise
>
> >If I call the function Is_Attached the program suddenly exits:
> >Program exited with code 01.
> >(gdb)
>
> >Do you know if is it possible to generate user defined interrupts?
>
> >Can you help me please to find out what's the problem?
> >Unfortunately there's not so much documentation about ADA =( and I'm late for my thesis...
>
> >Thank you very much in advance for your help,
> >Ada @ BRL
Thank you for your complete example!
^ permalink raw reply [relevance 0%]
* Re: Interrupts handling in ADA
@ 2011-12-13 13:11 1% ` Ada BRL
0 siblings, 0 replies; 133+ results
From: Ada BRL @ 2011-12-13 13:11 UTC (permalink / raw)
On 11 Dic, 09:23, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat, 10 Dec 2011 12:43:58 -0800 (PST), Ada @ BRL wrote:
> > The environment of ADA applcation is:
> > I have 4 tasks that execute at the same time:
> > one is the main task,
> > the other three execute a "read" from network (socket) function inside
> > their bodies (on the other side there's the C/C++ application with 3
> > network sockets).
> > [I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ]
>
> What dll import has to do with sockets, except that sockets usually are
> provided by a library?
I would have liked to use dll import to exchange data between C stuff
and Ada program instead of using two programs (C and Ada)
communicating through sockets...
but the dll import hasn't worked even with dummy and correct dll...
So, in order to overcome the problem, I've decided to use sockets.
>
> > I want that when new data is available on one or more socket threads, this
> > / these threads somehow notify the main thread that data is arrived and
> > then safely send the data to it.
>
> If you have many sockets, you should probably use select on them rather
> than blocking calls from many tasks. The maximal number of tasks supported
> by the OS is usually much lower than the maximal number of sockets.
I have a maximum of 5 sockets so I guess there will be no problems
onto the OS side...I hope so =).
What's the "select" you have just mentioned?
>
> > I've thought to use the interrupts...
>
> Interrupt in Ada is meant more like "hardware interrupt." It is possible
> but unlikely that your network stack generates such interrupts or that you
> could have an access to them under the OS you are running.
Ok, now I've figured out that the Ada interrupts are only HW and not
SW.
The software interrupts are implemented with entry / accept paradigm
(like events in C++? ).
>
> Software interrupt, also called asynchronous system trap (AST) is a
> different thing. What you had in mind is probably a software interrupt.
YES!
> The corresponding Ada mechanism is "Asynchronous Transfer of Control" (ATC).
> But there are much better ways.
>
> > because I haven't found any
> > references about the use of "events" in ADA.
>
> Events are low-level synchronization objects easily implemented using Ada
> protected objects, e.g.:
>
> http://www.dmitry-kazakov.de/ada/components.htm#Events
>
> Events are rarely used in Ada, because for inter task communication you
> have higher-level means.
>
> > I've thought to attach three different handler of interrupts into the main
> > task and then to generate the interrupt from the socket task with
>
> There are many ways to implement things like this:
>
> 1. One task + socket select
See above: what's select?
>
> 2. "Monitor": multiple socket readers do rendezvous to the main task, which
> accept the rendezvous.
In rendez-vous paradigm, is the main task forced to wait for ALL the
socket tasks or only for a subset of them?
Eg: only socket #2 has received some data, can the main task execute
or does it have to wait also for the other sockets?
>
> 3. "Queue": socket readers enqueue some data (the queue is implemented
> using a protected object). Other tasks (there could be many) dequeue data
> and do something meaningful with them. There are many kinds of queues for
> different purposes and of different behavior.
>
> 4. Single rank co-workers. Each socket reader processes data by themselves.
> In order to interlock processing there is a semaphore/mutex (implemented by
> a protected object), which is seized when processing starts and released
> afterwards.
In your opinion, what's the most effective and at the same time
simplest way to sort out my problem?
Simon Wright has posted an example of Protected queue and entry /
accept statements and it seems to be simple but effective as well.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
^ permalink raw reply [relevance 1%]
* Re: Interrupts handling in ADA
2011-12-10 20:43 2% Interrupts handling in ADA Ada @ BRL
2011-12-10 22:09 0% ` Niklas Holsti
@ 2011-12-12 3:19 0% ` anon
2011-12-13 13:31 0% ` Ada BRL
2 siblings, 1 reply; 133+ results
From: anon @ 2011-12-12 3:19 UTC (permalink / raw)
-- Interrupts are not necessary. From you description a simple set of
-- tasks is all that is needed.
--
-- This program outline uses three task to read three sockets and
-- after pre-processing and verifing data (if needed) passes this
-- data to a main task. The main task then can continue processing
-- this data.
--
-- Exception handling is limited to Socket error which will cause
-- that task to die and after reporting to the Main task. Then Main
-- task uses the abort statement to kill other tasks.
--
with Ada.Text_IO ;
with Interfaces ;
with GNAT.Sockets ;
use Ada.Text_IO ;
use Interfaces ;
use GNAT.Sockets ;
procedure v is
localhost : constant Inet_Addr_Type := Inet_Addr ( "127.0.0.1" ) ;
localport : constant Port_Type := 16#FFF0# ;
task One is
entry Start ; -- to insure network is operational
end One ;
task Two is
entry Start ;
end Two ;
task Three is
entry Start ;
end Three ;
task Main is
-- accept data from first two tasks.
entry Acknowledge_1 ( Data : Unsigned_32 ) ;
entry Acknowledge_2 ( Data : Unsigned_32 ) ;
-- accept data from third task only
entry Control ( Data : Character ) ;
-- denotes that network exception has ocurred from one of
-- the three tasks. The ( 1 .. 3 ) sets a range for
-- identifing the calling task. Where ( 1 ) is task One,
-- ( 2 ) is task Two and ( 3 ) is task Three.
entry Dead ( 1 .. 3 ) ;
end Main ;
--
-- Task bodies
--
task body One is
Socket : Socket_Type ;
Address : Sock_Addr_Type ;
Channel : Stream_Access ;
Data : Unsigned_32 ;
begin
-- Initialize Sockect
Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
Address.Addr := localhost ;
Address.Port := localport + 1 ;
Connect_Socket ( Socket, Address ) ;
Channel := Stream ( Socket ) ;
accept Start ;
-- Wait for controller to activate
loop
-- Wait for data.
Unsigned_32'Read ( Channel, Data ) ;
-- Verify or Pre-process data, if needed
-- Send data to main task.
Main.Acknowledge_1 ( Data ) ;
end loop ;
exception
when Socket_Error =>
if Main'Callable then
Main.Dead ( 1 ) ;
end if ;
Close_Socket ( Socket ) ;
end One ;
task body Two is
Socket : Socket_Type ;
Address : Sock_Addr_Type ;
Channel : Stream_Access ;
Data : Unsigned_32 ;
begin
-- Initialize Sockect
Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
Address.Addr := localhost ;
Address.Port := localport + 2 ;
Connect_Socket ( Socket, Address ) ;
Channel := Stream ( Socket ) ;
accept Start ;
-- Wait for controller to activate
loop
-- Wait for data.
Unsigned_32'Read ( Channel, Data ) ;
-- Verify or Pre-process data, if needed
-- Send data to main task.
Main.Acknowledge_2 ( Data ) ;
end loop ;
exception
when Socket_Error =>
if Main'Callable then
Main.Dead ( 2 ) ;
end if ;
Close_Socket ( Socket ) ;
end Two ;
task body Three is
Socket : Socket_Type ;
Address : Sock_Addr_Type ;
Channel : Stream_Access ;
Data : Character ;
begin
-- Initialize Sockect
Create_Socket ( Socket, Family_Inet, Socket_Datagram ) ;
Address.Addr := localhost ;
Address.Port := localport + 3 ;
Connect_Socket ( Socket, Address ) ;
Channel := Stream ( Socket ) ;
accept Start ;
-- Wait for controller to activate
loop
-- Wait for data.
Character'Read ( Channel, Data ) ;
-- Verify or Pre-process data, if needed
-- Send data to main task.
Main.Control ( Data ) ;
end loop ;
exception
when Socket_Error =>
if Main'Callable then
Main.Dead ( 3 ) ;
end if ;
Close_Socket ( Socket ) ;
end Three ;
--
-- Main Task body
--
task body Main is
Task_1_Data : Unsigned_32 ;
Task_2_Data : Unsigned_32 ;
Task_3_Data : Character ;
--
Task_Error : exception ;
begin
-- preform any initialize
loop
select
accept Acknowledge_1 ( Data : Unsigned_32 ) do
Task_1_Data := Data ;
-- process data from task 1
end Acknowledge_1 ;
or
accept Acknowledge_2 ( Data : Unsigned_32 ) do
Task_2_Data := Data ;
-- process data from task 2
end Acknowledge_2 ;
or
accept Control ( Data : Character ) do
Task_3_Data := Data ;
-- process data from task 3
end Control ;
or
accept Dead ( 1 ) ;
Put_Line ( "Error has ocurred in Task One" ) ;
raise Task_Error ;
or
accept Dead ( 2 ) ;
Put_Line ( "Error has ocurred in Task Two" ) ;
raise Task_Error ;
or
accept Dead ( 3 ) ;
Put_Line ( "Error has ocurred in Task Three" ) ;
raise Task_Error ;
end select ;
-- Continue processing with Data from all tasks
end loop ;
exception
when Task_Error =>
Put_Line ( "Error has cause this program to die" ) ;
-- abort all tasks
abort One ;
abort Two ;
abort Three ;
end Main ;
--
-- The Main task could start the three child task
--
begin
-- Verify all task are operational
if not One'Callable then
Put_Line ( "Error in Task One" ) ;
abort Two ;
abort Three ;
abort Main ;
elsif not Two'Callable then
Put_Line ( "Error in Task Two" ) ;
abort One ;
abort Three ;
abort Main ;
elsif not Three'Callable then
Put_Line ( "Error in Task Three" ) ;
abort One ;
abort Two ;
abort Main ;
else
One.Start ;
Two.Start ;
Three.Start ;
end if ;
exception
when others =>
null ;
end v ;
In <30143086.6.1323549838421.JavaMail.geo-discussion-forums@vbbfq24>, "Ada @ BRL" <ada.brl.2011@gmail.com> writes:
>Hello,
>I'm an Erasmus student at the University of Bristol - UK and I'm carrying out the work for my master thesis in Computer Engineering.
>
>I'm programming a multithreading application in C / C++ and ADA.
>The latter is a completely new language for me...
>
>The environment of ADA applcation is:
>I have 4 tasks that execute at the same time:
>one is the main task,
>the other three execute a "read" from network (socket) function inside their bodies (on the other side there's the C/C++ application with 3 network sockets).
>[I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ]
>
>I want that when new data is available on one or more socket threads, this / these threads somehow notify the main thread that data is arrived and then safely send the data to it.
>
>I've thought to use the interrupts...because I haven't found any references about the use of "events" in ADA.
>I've thought to attach three different handler of interrupts into the main task and then to generate the interrupt from the socket task with ada.interrupts.signal.generate_interrupt.
>Socket 1 will generate interrupt #1, socket 2 -> interrupt #2 and so on.
>
>May you tell me please if this is the right way to face the problem?
>I'm not skilled in ada and so there could be other better methods...
>
>I've used the pragmas attach_handler and interrupt_handler but unfortunately I'm still not able to get all the stuff working...
>
>I think it's a problem of ADA implementation because:
>even if I call pragma unreserve_all_interrupts I've found that the function Is_Reserved(Interr_ID) returns FALSE only for this signals IDs: 2(SIGINT), 4(SIGILL), 8(SIGFPE), 11(SISEGV), 15(SIGTERM), 22(SIGABRT).
>
>I guess that this is the opposite behaviour as I expected...
>If I try to set an handler to the interrupt say 9, the program cannot start due to this error:
>
>raised PROGRAM_ERROR : adjust/finalize raised PROGRAM_ERROR: s-interr.adb:343 explicit raise
>
>If I call the function Is_Attached the program suddenly exits:
>Program exited with code 01.
>(gdb)
>
>Do you know if is it possible to generate user defined interrupts?
>
>Can you help me please to find out what's the problem?
>Unfortunately there's not so much documentation about ADA =( and I'm late for my thesis...
>
>Thank you very much in advance for your help,
>Ada @ BRL
^ permalink raw reply [relevance 0%]
* Re: Interrupts handling in ADA
2011-12-10 20:43 2% Interrupts handling in ADA Ada @ BRL
@ 2011-12-10 22:09 0% ` Niklas Holsti
2011-12-12 3:19 0% ` anon
2 siblings, 0 replies; 133+ results
From: Niklas Holsti @ 2011-12-10 22:09 UTC (permalink / raw)
On 11-12-10 22:43 , Ada @ BRL wrote:
> Hello,
> I'm an Erasmus student at the University of Bristol - UK and I'm
> carrying out the work for my master thesis in Computer Engineering.
>
> I'm programming a multithreading application in C / C++ and ADA.
> The latter is a completely new language for me...
>
> The environment of ADA applcation is:
> I have 4 tasks that execute at the same time:
> one is the main task,
> the other three execute a "read" from network (socket) function inside
> their bodies (on the other side there's the C/C++ application with 3 network sockets).
> [I decided to use the sockets instead of dll/lib import because this
> approach hasn't worked... =( ]
>
> I want that when new data is available on one or more socket threads, this
> / these threads somehow notify the main thread that data is arrived and
> then safely send the data to it.
>
> I've thought to use the interrupts...because I haven't found any references
> about the use of "events" in ADA.
> I've thought to attach three different handler of interrupts into the main
> task and then to generate the interrupt from the socket task with
> ada.interrupts.signal.generate_interrupt.
> Socket 1 will generate interrupt #1, socket 2 -> interrupt #2 and so on.
>
> May you tell me please if this is the right way to face the problem?
I wouldn't say so -- better use the Ada features intended for
task-to-task communication. There are basically two such features:
- rendezvous, an older method, and
- protected objects, a newer method.
The rendezvous method resembles sockets, in a way: one task acts as a
server and exports an "entry" that other client tasks can call. When the
server task is ready to accept a call on an entry, it executes an
"accept" statement; typically, the accept statement suspends the server
task until some client task calls the entry. Symmetrically, if a client
task calls the entry, and the server is not waiting in an accept
statement for that entry, the client task is suspended until the server
accepts the call. (You can also avoid these suspension, if you want.)
When the server is accepting, and some client is calling, the
"rendezvous" (French for "meeting") happens, and the statements defined
for the entry (in the accept statement) are executed. The parameters of
the entry can transfer data from client to server and server to client.
When the entry statements are completed, the rendezvous ends and both
tasks continue in parallel again.
In your case, the main task would act as the server task and the other
three tasks would be client tasks. If the data ("events") that the three
client tasks send to the main task are of different types, the main task
could export three different entries, one for each client task, with the
corresponding types of parameters. If all client tasks send the same
kind of data to the main task, a single entry that is called by all
client tasks would be enough (perhaps it needs a parameter that tells
which client is calling, too).
The "protected object" method is like a "monitor" or a "mailbox": You
define an object that has some public operations and some private data.
The "protected" property means that the public operations are associated
with a mutex that enforces mutual exclusion between the calling tasks
(well, to be precise, the synchronization allows multiple concurrent
readers, or one exclusive writer). Some public operations can be
labelled "entries" which means that there is a Boolean "guard"
expression, similar to a "condition variable": if a task calls an entry
subprogram, and the guard is false, the task is suspended until the
guard becomes true (thanks to some other task calling some other
operation of the same protected object).
In your case, you could define a protected object that has internal
buffers to hold data ("events") from the three socket tasks. The socket
tasks would call operations of this object to store data in the buffers;
the main task would call an operation to extract data from the buffers;
the latter operation could be defined as an entry, with a guard that
makes the main task wait until there is some data in the buffers.
> Unfortunately there's not so much documentation about ADA =(
Sure there is... for example, the Wikibook at
http://en.wikibooks.org/wiki/Ada_Programming. You should look at the
chapter on tasking, at http://en.wikibooks.org/wiki/Ada_Programming/Tasking.
HTH!
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [relevance 0%]
* Interrupts handling in ADA
@ 2011-12-10 20:43 2% Ada @ BRL
2011-12-10 22:09 0% ` Niklas Holsti
` (2 more replies)
0 siblings, 3 replies; 133+ results
From: Ada @ BRL @ 2011-12-10 20:43 UTC (permalink / raw)
Hello,
I'm an Erasmus student at the University of Bristol - UK and I'm carrying out the work for my master thesis in Computer Engineering.
I'm programming a multithreading application in C / C++ and ADA.
The latter is a completely new language for me...
The environment of ADA applcation is:
I have 4 tasks that execute at the same time:
one is the main task,
the other three execute a "read" from network (socket) function inside their bodies (on the other side there's the C/C++ application with 3 network sockets).
[I decided to use the sockets instead of dll/lib import because this approach hasn't worked... =( ]
I want that when new data is available on one or more socket threads, this / these threads somehow notify the main thread that data is arrived and then safely send the data to it.
I've thought to use the interrupts...because I haven't found any references about the use of "events" in ADA.
I've thought to attach three different handler of interrupts into the main task and then to generate the interrupt from the socket task with ada.interrupts.signal.generate_interrupt.
Socket 1 will generate interrupt #1, socket 2 -> interrupt #2 and so on.
May you tell me please if this is the right way to face the problem?
I'm not skilled in ada and so there could be other better methods...
I've used the pragmas attach_handler and interrupt_handler but unfortunately I'm still not able to get all the stuff working...
I think it's a problem of ADA implementation because:
even if I call pragma unreserve_all_interrupts I've found that the function Is_Reserved(Interr_ID) returns FALSE only for this signals IDs: 2(SIGINT), 4(SIGILL), 8(SIGFPE), 11(SISEGV), 15(SIGTERM), 22(SIGABRT).
I guess that this is the opposite behaviour as I expected...
If I try to set an handler to the interrupt say 9, the program cannot start due to this error:
raised PROGRAM_ERROR : adjust/finalize raised PROGRAM_ERROR: s-interr.adb:343 explicit raise
If I call the function Is_Attached the program suddenly exits:
Program exited with code 01.
(gdb)
Do you know if is it possible to generate user defined interrupts?
Can you help me please to find out what's the problem?
Unfortunately there's not so much documentation about ADA =( and I'm late for my thesis...
Thank you very much in advance for your help,
Ada @ BRL
^ permalink raw reply [relevance 2%]
* Re: ACCESS TO SYSTEM VARIABLES
@ 2011-03-09 18:59 2% ` Emile8
0 siblings, 0 replies; 133+ results
From: Emile8 @ 2011-03-09 18:59 UTC (permalink / raw)
On 8 mar, 18:13, Emile8 <pocchiola.y...@gmail.com> wrote:
> On 7 mar, 22:32, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
>
> > On Mon, 7 Mar 2011, Emile8 wrote:
> > > It is not a very elegant solution and I should look also at how the
> > > Ada version of ncurses manages to get the same informations.
>
> > When the terminal is resized the programs running in it receive a Unix
> > signal (SIGWINCH?). By default that signal is ignored. However, one can
> > install a signal handler for it and then presumably call into the system
> > (some terminal API) to ask for the new sizes.
>
> > I could probably figure out how to do this in C, but I'm not familiar with
> > how Ada on Unix deals with Unix signals.
>
> > Peter
>
> You are right, the approach by a user handler attached to the relevant
> UNIX signal is certainly the good approach to cope with terminal
> modifications. I am looking at some documentation to understand how to
> proceed with these handles in Ada (Rosetta Code ans Big Online Book of
> Linux Ada to begin).
>
> Thank you.
Your suggestion to use a handler on SIGWINCH works fine with the
following Ada package which has simply to be imported by the
application which uses a terminal. The Ansi_Tty_Control package
provides :
-The N_Columns and N_Lines variables which keep trace of the
terminal size.
-The Dim_Terminal procedure which reads the terminal sizes
Window resizing and terminal police size change are well detected and
new columns and lines number well reported.
Great !
--SPECIFICATION
with Ada.Interrupts.Names; use Ada.Interrupts, Ada.Interrupts.Names;
package Sigwinchhandler is
protected Signalhandler is
procedure Handlewindowresizing;
pragma Attach_Handler (Handlewindowresizing, SIGWINCH);
-- SIGWINCH (window resizing) intercepted by
-- Handlewindowresizing
end Signalhandler;
end Sigwinchhandler;
-- BODY
with Ada.Text_IO; use Ada.Text_IO;
with Ansi_Tty_Control; use Ansi_Tty_Control;
package body Sigwinchhandler is
-- Package to handle SIGWINCH Linux signals
protected body Signalhandler is
-- This protected type contains the signal handlers for the
applications
procedure Handlewindowresizing is
-- window dimensions handler
begin
-- Acquisition of terminal LINES and COLUMNS by bash
command :
-- stty size > TermSize.txt (waiting for something else more
direct ...)
Dim_Terminal;
Put_Line ("Columns : " & Positive'Image (N_Columns));-- Here
the PROOF that it works !
Put_Line ("Lines : " & Positive'Image (N_Lines));
end Handlewindowresizing;
end Signalhandler;
end Sigwinchhandler;
^ permalink raw reply [relevance 2%]
* Re: GNAT and SIGTERM (Linux x86_64)
2010-10-26 16:36 0% ` Yannick Duchêne (Hibou57)
@ 2010-10-27 7:43 7% ` Ludovic Brenta
0 siblings, 0 replies; 133+ results
From: Ludovic Brenta @ 2010-10-27 7:43 UTC (permalink / raw)
Yannick Duchêne wrote on comp.lang.ada:
> Signal_Handler is a type, and a type does not live on its own. To make it
> “real”, you have to instantiate an entity of that type.
Good catch.
> In few word : in Entry_Point, you forget to declare a variable of type
> Signal_Handler.
>
> Try this :
>
> procedure Entry_Point is
> Shutdown_Flag : Boolean := False;
> Handler : Signal_Handler; -- < Add this line
> begin
> [... remaining of you cool stuff]
> end Entry_Point;
>
> It works :)
Or, simply remove the "type" keyword from the declaration of
Signal_Handler, i.e.
--- signals.ads before
+++ signals.ads after
@@ -6,6 +6,6 @@
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
package Signals is
pragma Unreserve_All_Interrupts;
- protected type Signal_Handler is
+ protected Signal_Handler is
procedure Handle_SIGTERM;
pragma Attach_Handler(Handle_SIGTERM, SIGTERM);
pragma Interrupt_State (SIGTERM, System);
--
Ludovic Brenta.
I love hand-writing unified diffs in the morning.
^ permalink raw reply [relevance 7%]
* Re: GNAT and SIGTERM (Linux x86_64)
2010-10-26 15:52 2% GNAT and SIGTERM (Linux x86_64) Bryan
@ 2010-10-26 16:36 0% ` Yannick Duchêne (Hibou57)
2010-10-27 7:43 7% ` Ludovic Brenta
0 siblings, 1 reply; 133+ results
From: Yannick Duchêne (Hibou57) @ 2010-10-26 16:36 UTC (permalink / raw)
Le Tue, 26 Oct 2010 17:52:57 +0200, Bryan <brobinson.eng@gmail.com> a
écrit:
> I'm trying to capture SIGTERM in a very simple test program but I'm
> running into some issues. When I execute the code (at the end of
> message), I get the following output in my terminal when I send "kill -
> SIGTERM <PID>:
>
>> ./entry_point
> SIGTERM handler is NOT reserved
> !!! SIGTERM handler is NOT attached !!!
> Terminated
>
> [...]
> --------------------------------------
> Test program source code:
> --------------------------------------
> -- Signals.ads
> with Ada.Interrupts; use Ada.Interrupts;
> with Ada.Interrupts.Names; use Ada.Interrupts.Names;
> package Signals is
> pragma Unreserve_All_Interrupts;
> protected type Signal_Handler is
> procedure Handle_SIGTERM;
> pragma Attach_Handler(Handle_SIGTERM, SIGTERM);
> pragma Interrupt_State (SIGTERM, System);
> end Signal_Handler;
> end Signals;
>
> -- Signals.adb
> with Ada.Text_IO; use Ada.Text_IO;
> package body Signals is
> protected body Signal_Handler is
> procedure Handle_SIGTERM is
> begin
> Put_Line( "SIGTERM caught!" );
> end Handle_SIGTERM;
> end Signal_Handler;
> end Signals;
>
> -- Entrypoint.adb
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Interrupts; use Ada.Interrupts;
> with Ada.Interrupts.Names; use Ada.Interrupts.Names;
> with Signals; use Signals;
>
> procedure Entry_Point is
> Shutdown_Flag : Boolean := False;
> begin
> if Is_Reserved(SIGTERM) then
> Put_Line("SIGTERM handler is reserved");
> else
> Put_Line("SIGTERM handler is NOT reserved");
> end if;
>
> if Is_Attached(SIGTERM) then
> Put_Line("SIGTERM handler is attached");
> else
> Put_Line("!!! SIGTERM handler is NOT attached !!!");
> end if;
>
> loop
> -- do nothing
> exit when Shutdown_Flag = True;
> end loop;
> end Entry_Point;
Signal_Handler is a type, and a type does not live on its own. To make it
“real”, you have to instantiate an entity of that type.
In few word : in Entry_Point, you forget to declare a variable of type
Signal_Handler.
Try this :
procedure Entry_Point is
Shutdown_Flag : Boolean := False;
Handler : Signal_Handler; -- < Add this line
begin
[... remaining of you cool stuff]
end Entry_Point;
It works :)
--
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour
les chiens.
^ permalink raw reply [relevance 0%]
* GNAT and SIGTERM (Linux x86_64)
@ 2010-10-26 15:52 2% Bryan
2010-10-26 16:36 0% ` Yannick Duchêne (Hibou57)
0 siblings, 1 reply; 133+ results
From: Bryan @ 2010-10-26 15:52 UTC (permalink / raw)
I'm trying to capture SIGTERM in a very simple test program but I'm
running into some issues. When I execute the code (at the end of
message), I get the following output in my terminal when I send "kill -
SIGTERM <PID>:
> ./entry_point
SIGTERM handler is NOT reserved
!!! SIGTERM handler is NOT attached !!!
Terminated
I attached the signal handler in signals.ads, but it seems the handler
is still not attached. The sample program in the Big Book of Ada
Programming for Linux attaches the handler in the package
specification, and I tried to follow the sample program. To make
things more interesting, If I run this same code on a Mac OS X with
GNAT, I get the following as my output:
> ./entry_point
SIGTERM handler is reserved
raised PROGRAM_ERROR : Interrupt 15 is reserved
This happens even with the Unreserve_All_Interrupts in signals.ads.
The behavior of both the Linux and the Mac binary are leading me to--
perhaps wrongly--consider that there is something I am missing with
GNAT to allow it to work with UNIX signals.
Questions:
1) Do my pragma statements need to be in the specification or the
body?
2) Do I need to pass some sort of flag to gnat to enable signals?
I would greatly appreciate any input or advice on this issue.
--------------------------------------
Test program source code:
--------------------------------------
-- Signals.ads
with Ada.Interrupts; use Ada.Interrupts;
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
package Signals is
pragma Unreserve_All_Interrupts;
protected type Signal_Handler is
procedure Handle_SIGTERM;
pragma Attach_Handler(Handle_SIGTERM, SIGTERM);
pragma Interrupt_State (SIGTERM, System);
end Signal_Handler;
end Signals;
-- Signals.adb
with Ada.Text_IO; use Ada.Text_IO;
package body Signals is
protected body Signal_Handler is
procedure Handle_SIGTERM is
begin
Put_Line( "SIGTERM caught!" );
end Handle_SIGTERM;
end Signal_Handler;
end Signals;
-- Entrypoint.adb
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Interrupts; use Ada.Interrupts;
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
with Signals; use Signals;
procedure Entry_Point is
Shutdown_Flag : Boolean := False;
begin
if Is_Reserved(SIGTERM) then
Put_Line("SIGTERM handler is reserved");
else
Put_Line("SIGTERM handler is NOT reserved");
end if;
if Is_Attached(SIGTERM) then
Put_Line("SIGTERM handler is attached");
else
Put_Line("!!! SIGTERM handler is NOT attached !!!");
end if;
loop
-- do nothing
exit when Shutdown_Flag = True;
end loop;
end Entry_Point;
^ permalink raw reply [relevance 2%]
* Re: How to exit a loop with keyboard input
2010-04-12 13:59 1% ` John McCormick
@ 2010-04-13 19:38 0% ` Jerry
0 siblings, 0 replies; 133+ results
From: Jerry @ 2010-04-13 19:38 UTC (permalink / raw)
On Apr 12, 6:59 am, John McCormick <mccorm...@cs.uni.edu> wrote:
> On Apr 12, 5:36 am, Jerry <lancebo...@qwest.net> wrote:
>
> > Thanks, Georg and Manuel, for testing. I'm on OS X 10.5.8 and:
>
> > MBPro:/ me$ gnat
> > GNAT 4.4.0 20080314 (experimental) [trunk revision 133226]
> > Copyright 1996-2007, Free Software Foundation, Inc.
>
> > I've tried the program on three different terminal programs with the
> > same result: it prints out 0 and waits for RETURN, then prints out 1,
> > etc. If I hit q then RETURN the loop is exited. But the loop never
> > "free-runs."
>
> > Jerry
>
> Perhaps the Asynchronous Transfer of Control mechanism would be
> appropriate. Here is some GNAT code that runs under Windows XP in
> which the input loop is interrutpted by Ctrl-c. The interrupt handler
> must be at the library level so I put it in its own package.
>
> select
> Ctrl_C_Interrupt.Wait;
> Put_Line ("Handled Ctrl C");
> then abort
> loop
> Put_Line ("Enter an integer (Ctrl C to exit)");
> Get (Value);
> Put (Value);
> New_Line;
> end loop;
> end select;
>
> -----------------------------------------------------------
> with Ada.Interrupts.Names;
> package Ctrl_C is
>
> protected Ctrl_C_Interrupt is
> entry Wait;
> procedure Handler;
> pragma Attach_Handler (Handler, Ada.Interrupts.Names.SIGINT);
> pragma Interrupt_Priority;
> private
> Received : Boolean := False;
> end Ctrl_C_Interrupt;
> end Ctrl_C;
>
> -----------------------------------------------------------
> package body Ctrl_C is
>
> protected body Ctrl_C_Interrupt is
> procedure Handler is
> begin
> Received := True;
> end Handler;
>
> entry Wait when Received is
> begin
> Received := False;
> end Wait;
> end Ctrl_C_Interrupt;
>
> end Ctrl_C;
>
> John
Thanks, John.
Your solution does work (after I added pragma
Unreserve_All_Interrupts;) and I think I can adapt it to my specific
problem but it takes 100% of CPU time so I'm not sure how that would
affect my number-crunching loop. (A similar solution was suggested by
Chris on the GNAT-OSX list but I haven't tried it yet.)
Jerry
^ permalink raw reply [relevance 0%]
* Re: How to exit a loop with keyboard input
@ 2010-04-12 13:59 1% ` John McCormick
2010-04-13 19:38 0% ` Jerry
0 siblings, 1 reply; 133+ results
From: John McCormick @ 2010-04-12 13:59 UTC (permalink / raw)
On Apr 12, 5:36 am, Jerry <lancebo...@qwest.net> wrote:
> Thanks, Georg and Manuel, for testing. I'm on OS X 10.5.8 and:
>
> MBPro:/ me$ gnat
> GNAT 4.4.0 20080314 (experimental) [trunk revision 133226]
> Copyright 1996-2007, Free Software Foundation, Inc.
>
> I've tried the program on three different terminal programs with the
> same result: it prints out 0 and waits for RETURN, then prints out 1,
> etc. If I hit q then RETURN the loop is exited. But the loop never
> "free-runs."
>
> Jerry
Perhaps the Asynchronous Transfer of Control mechanism would be
appropriate. Here is some GNAT code that runs under Windows XP in
which the input loop is interrutpted by Ctrl-c. The interrupt handler
must be at the library level so I put it in its own package.
select
Ctrl_C_Interrupt.Wait;
Put_Line ("Handled Ctrl C");
then abort
loop
Put_Line ("Enter an integer (Ctrl C to exit)");
Get (Value);
Put (Value);
New_Line;
end loop;
end select;
-----------------------------------------------------------
with Ada.Interrupts.Names;
package Ctrl_C is
protected Ctrl_C_Interrupt is
entry Wait;
procedure Handler;
pragma Attach_Handler (Handler, Ada.Interrupts.Names.SIGINT);
pragma Interrupt_Priority;
private
Received : Boolean := False;
end Ctrl_C_Interrupt;
end Ctrl_C;
-----------------------------------------------------------
package body Ctrl_C is
protected body Ctrl_C_Interrupt is
procedure Handler is
begin
Received := True;
end Handler;
entry Wait when Received is
begin
Received := False;
end Wait;
end Ctrl_C_Interrupt;
end Ctrl_C;
John
^ permalink raw reply [relevance 1%]
* Re: Ada and (SIGTERM?)
2009-08-06 19:57 1% ` Jeffrey R. Carter
@ 2009-08-06 20:00 1% ` okellogg
1 sibling, 0 replies; 133+ results
From: okellogg @ 2009-08-06 20:00 UTC (permalink / raw)
On Aug 6, 9:30 pm, Tomek Wałkuski <tomek.walku...@gmail.com> wrote:
> Thx for replies, but... what am I doing wrong?
>
> protected type Interrupt_Handler is
> procedure Handler;
> pragma Attach_Handler (Handler, 15); -- is it correct for SIGTERM?
Yes, although using Ada.Interrupts.Names.SIGTERM could be more
readable.
>
> function Quit return Boolean;
> private
> Q : Boolean := False;
> end Interrupt_Handler;
>
> protected body Interrupt_Handler is
> procedure Handler is
> begin
> Q := True;
> end Handler;
>
> function Quit return Boolean is
> begin
> return Q;
> end Quit;
> end Interrupt_Handler;
>
> Then... somewhere Interrupt_Handler is declared and loop looks like:
>
> while not Quit loop
> Do_Something;
> end loop;
>
> And... This does not work. What am I missing?
If you are using GNAT then perhaps you need a
pragma Unreserve_All_Interrupts;
somewhere in a library level spec.
Just shooting from the hip here -
Oliver
^ permalink raw reply [relevance 1%]
* Re: Ada and (SIGTERM?)
@ 2009-08-06 19:57 1% ` Jeffrey R. Carter
2009-08-06 20:00 1% ` okellogg
1 sibling, 0 replies; 133+ results
From: Jeffrey R. Carter @ 2009-08-06 19:57 UTC (permalink / raw)
Tomek Wałkuski wrote:
> Thx for replies, but... what am I doing wrong?
>
> protected type Interrupt_Handler is
> procedure Handler;
> pragma Attach_Handler (Handler, 15); -- is it correct for SIGTERM?
You probably only want a single handler for interrupt 15. So either this should
be an object rather than a type, or it should have a discriminant to indicate
the interrupt to handle.
Check your vendor's Ada.Interrupts.Names for the interrupts you can handle on
your system.
> while not Quit loop
> Do_Something;
> end loop;
>
> And... This does not work. What am I missing?
Quit is inside an object of type Interrupt_Handler, and so must be referenced
using dot notation:
<object>.Quit
"Does not work" is rather vague. Saying "gives me a compilation error with the
message 'xyz'" or "raises Xyz at run time" or "causes my computer to explode"
would make it easier to help you.
--
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83
^ permalink raw reply [relevance 1%]
* Timing Example was Re: Interrupt handler and Ada.Real_Time.Timing_Events
2009-05-15 16:26 2% Interrupt handler and Ada.Real_Time.Timing_Events Reto Buerki
2009-05-15 16:54 0% ` Adam Beneschan
2009-05-15 16:56 0% ` Ludovic Brenta
@ 2009-05-16 11:05 0% ` anon
2 siblings, 0 replies; 133+ results
From: anon @ 2009-05-16 11:05 UTC (permalink / raw)
This is a Timeing example that uses "Ada.Real_Time.Timing_Events" package.
Now, adding an interrupt handler to this design you should wrap the interrupt
handler within a Task routine bacuse "Ada.Real_Time.Timing_Events" uses
tasking for its underlying algorithm, then call the Timers Shutdown routine
once the interrupt has occurred.
--
-- generic_timers.ads
--
with Ada.Real_Time.Timing_Events ;
generic
Multi_Events : Boolean := True ;
Timer_Name : String := "Generic_Timers" ;
Interval : in Ada.Real_Time.Time_Span ;
with procedure Action is <> ;
package Generic_Timers is
Timer_Error : exception ;
procedure Activate ;
procedure Shutdown ;
private
The_Event : Ada.Real_Time.Timing_Events.Timing_Event ;
end Generic_Timers ;
--
-- generic_timers.adb
--
with Ada.Real_Time ;
use Ada.Real_Time ;
package body Generic_Timers is
protected Events is
procedure Handler ( Event: in out Timing_Events.Timing_Event ) ;
end Events ;
protected body Events is
procedure Handler ( Event: in out Timing_Events.Timing_Event ) is
begin
Action ;
if Multi_Events then
Activate ; -- periodic timer continues
end if ;
end Handler ;
end Events ;
procedure Activate is
use type Timing_Events.Timing_Event_Handler ;
begin
if Timing_Events.Current_Handler ( The_Event ) = null then
Timing_Events.Set_Handler ( The_Event,
Interval,
Events.Handler'Access ) ;
else
raise Timer_Error with "Activation " & Timer_Name ;
end if ;
end Activate ;
procedure Shutdown is
Success : Boolean := False ;
use type Timing_Events.Timing_Event_Handler ;
begin
if Timing_Events.Current_Handler ( The_Event ) /= null then
Timing_Events.Cancel_Handler ( The_Event, Success ) ;
if not Success then
raise Timer_Error with "Shutdown: " & Timer_Name ;
end if ;
end if ;
end Shutdown ;
end Generic_Timers ;
--
-- timers.ads
--
package Timers is
procedure Activate ;
procedure Shutdown ;
end Timers ;
--
-- Timers.adb
--
with Ada.Real_Time ;
with Ada.Text_IO ;
with Generic_Timers ;
package body Timers is
use Ada ;
use Real_Time ;
use Text_IO ;
------------------------------------
-- Define Periodic Event Timers --
------------------------------------
Periodic_Interval : constant Time_Span := Milliseconds ( 2000 ) ;
Periodic_Timer_ID : constant String := "Periodic Timer" ;
procedure Periodic_Action is
begin
Put_Line ( "Timeout: Periodic Timer" ) ;
end Periodic_Action ;
Package Periodic_Timer is new Generic_Timers ( True,
Periodic_Timer_ID,
Periodic_Interval,
Periodic_Action ) ;
----------------------------------
-- Define Single Event Timers --
----------------------------------
Single_Interval : constant Time_Span := Milliseconds ( 1000 ) ;
Single_Timer_ID : constant String := "Single Timer" ;
procedure Single_Action is
begin
Put_Line ( "Timeout: Single Timer " ) ;
end Single_Action ;
Package Single_Timer is new Generic_Timers ( False,
Single_Timer_ID,
Single_Interval,
Single_Action ) ;
----------------------------
-- Controlling Routines --
----------------------------
procedure Activate is
begin
Put_Line ( "Timers: Activate" ) ;
Periodic_Timer.Activate ;
for Index in 0 .. 3 loop
Single_Timer.Activate ;
delay 7.0 ;
end loop;
end Activate ;
procedure Shutdown is
begin
Put_Line ( "Timers: Shutdown" ) ;
Periodic_Timer.Shutdown ;
Single_Timer.Shutdown ;
end Shutdown;
end Timers ;
--
-- testing.adb
--
with Ada.Exceptions ;
with Ada.Text_IO ;
with Timers ;
procedure Testing is
use Ada ;
use Text_IO ;
begin
Put_Line ( "Testing : Begin" ) ;
Timers.Activate ;
delay 5.0 ;
Timers.Shutdown ;
Put_Line ( "Testing : End" ) ;
exception
when Error : others =>
Put_Line ( "Testing fails for because of ==> "
& Exceptions.Exception_Information ( Error ) ) ;
end Testing ;
In <guk532$u44$1@news.motzarella.org>, Reto Buerki <reet@codelabs.ch> writes:
>Hi,
>
>I hit a rather strange issue today mixing signal/interrupt handling with
>Ada.Real_Time.Timing_Events. We have a real life application where we
>use timing events but we also need a signal handler to catch signals
>from the environment (SIGTERM etc.).
>
>I wrote a small reproducer to illustrate the problem. The following
>protected object is used as an interrupt handler, which can be attached
>to a specific interrupt/signal:
>
>with Ada.Interrupts;
>
>package Handlers is
>
> protected type Signal_Handler (Signal : Ada.Interrupts.Interrupt_ID)
> is
> pragma Interrupt_Priority;
>
> entry Wait;
> private
> procedure Handle_Signal;
> pragma Attach_Handler (Handle_Signal, Signal);
>
> Occured : Boolean := False;
> end Signal_Handler;
>
>end Handlers;
>
>package body Handlers is
>
> protected body Signal_Handler is
> procedure Handle_Signal is
> begin
> Occured := True;
> end Handle_Signal;
>
> entry Wait when Occured is
> begin
> if Wait'Count = 0 then
> Occured := False;
> end if;
> end Wait;
> end Signal_Handler;
>
>end Handlers;
>
>The handler is used like this:
>
>with Ada.Text_IO;
>with Ada.Interrupts.Names;
>
>-- Uncommenting the next line breaks interrupt handler
>-- with Ada.Real_Time.Timing_Events;
>
>with Handlers;
>
>procedure Interrupt_Problem is
> use Ada.Interrupts;
>
> Handler : Handlers.Signal_Handler (Signal => Names.SIGTERM);
>begin
>
> if Is_Attached (Interrupt => Names.SIGTERM) then
> Ada.Text_IO.Put_Line ("Attached handler to SIGTERM");
> else
> Ada.Text_IO.Put_Line ("Could not attach to SIGTERM!");
> return;
> end if;
>
> Handler.Wait;
> Ada.Text_IO.Put_Line ("Interrupt received ...");
>
>end Interrupt_Problem;
>
>As expected, when sending SIGTERM to the running 'Interrupt_Problem'
>process "Interrupt received ..." is displayed. So far so good.
>
>As commented in the source code, as soon as the
>Ada.Real_Time.Timing_Events package is with'ed, this mechanism breaks.
>
>The signal handler is not invoked any more when I send a SIGTERM signal
>to a running 'Interrupt_Problem' process, it just terminates without
>triggering the Handler.Wait.
>
>What could be the cause for this behavior? Is there a problem with this
>code?
>
>Thanks in advance!
>- reto
^ permalink raw reply [relevance 0%]
* Re: Interrupt handler and Ada.Real_Time.Timing_Events
2009-05-15 16:26 2% Interrupt handler and Ada.Real_Time.Timing_Events Reto Buerki
2009-05-15 16:54 0% ` Adam Beneschan
@ 2009-05-15 16:56 0% ` Ludovic Brenta
2009-05-16 11:05 0% ` Timing Example was " anon
2 siblings, 0 replies; 133+ results
From: Ludovic Brenta @ 2009-05-15 16:56 UTC (permalink / raw)
On May 15, 6:26 pm, Reto Buerki <r...@codelabs.ch> wrote:
> Hi,
>
> I hit a rather strange issue today mixing signal/interrupt handling with
> Ada.Real_Time.Timing_Events. We have a real life application where we
> use timing events but we also need a signal handler to catch signals
> from the environment (SIGTERM etc.).
>
> I wrote a small reproducer to illustrate the problem. The following
> protected object is used as an interrupt handler, which can be attached
> to a specific interrupt/signal:
>
> with Ada.Interrupts;
>
> package Handlers is
>
> protected type Signal_Handler (Signal : Ada.Interrupts.Interrupt_ID)
> is
> pragma Interrupt_Priority;
>
> entry Wait;
> private
> procedure Handle_Signal;
> pragma Attach_Handler (Handle_Signal, Signal);
>
> Occured : Boolean := False;
> end Signal_Handler;
>
> end Handlers;
>
> package body Handlers is
>
> protected body Signal_Handler is
> procedure Handle_Signal is
> begin
> Occured := True;
> end Handle_Signal;
>
> entry Wait when Occured is
> begin
> if Wait'Count = 0 then
> Occured := False;
> end if;
> end Wait;
> end Signal_Handler;
>
> end Handlers;
>
> The handler is used like this:
>
> with Ada.Text_IO;
> with Ada.Interrupts.Names;
>
> -- Uncommenting the next line breaks interrupt handler
> -- with Ada.Real_Time.Timing_Events;
>
> with Handlers;
>
> procedure Interrupt_Problem is
> use Ada.Interrupts;
>
> Handler : Handlers.Signal_Handler (Signal => Names.SIGTERM);
> begin
>
> if Is_Attached (Interrupt => Names.SIGTERM) then
> Ada.Text_IO.Put_Line ("Attached handler to SIGTERM");
> else
> Ada.Text_IO.Put_Line ("Could not attach to SIGTERM!");
> return;
> end if;
>
> Handler.Wait;
> Ada.Text_IO.Put_Line ("Interrupt received ...");
>
> end Interrupt_Problem;
>
> As expected, when sending SIGTERM to the running 'Interrupt_Problem'
> process "Interrupt received ..." is displayed. So far so good.
>
> As commented in the source code, as soon as the
> Ada.Real_Time.Timing_Events package is with'ed, this mechanism breaks.
>
> The signal handler is not invoked any more when I send a SIGTERM signal
> to a running 'Interrupt_Problem' process, it just terminates without
> triggering the Handler.Wait.
>
> What could be the cause for this behavior? Is there a problem with this
> code?
Ada.Real_Time.Timing_Events's elaboration block creates a task and
promotes it to an outer level (i.e. it is no longer dependent on a
master). The only way to terminate this task is by sending it
SIGTERM, so the task attaches another signal handler to SIGTERM before
yours. That handler catches the signal and does not propagate it to
any other handler. See System.Task_Primitives.Operations.Initialize.
I'm afraid there is no way out :) maybe you can use another signal in
your task?
--
Ludovic Brenta.
^ permalink raw reply [relevance 0%]
* Re: Interrupt handler and Ada.Real_Time.Timing_Events
2009-05-15 16:26 2% Interrupt handler and Ada.Real_Time.Timing_Events Reto Buerki
@ 2009-05-15 16:54 0% ` Adam Beneschan
2009-05-15 16:56 0% ` Ludovic Brenta
2009-05-16 11:05 0% ` Timing Example was " anon
2 siblings, 0 replies; 133+ results
From: Adam Beneschan @ 2009-05-15 16:54 UTC (permalink / raw)
On May 15, 9:26 am, Reto Buerki <r...@codelabs.ch> wrote:
> Hi,
>
> I hit a rather strange issue today mixing signal/interrupt handling with
> Ada.Real_Time.Timing_Events. We have a real life application where we
> use timing events but we also need a signal handler to catch signals
> from the environment (SIGTERM etc.).
>
> I wrote a small reproducer to illustrate the problem. The following
> protected object is used as an interrupt handler, which can be attached
> to a specific interrupt/signal:
>
> with Ada.Interrupts;
>
> package Handlers is
>
> protected type Signal_Handler (Signal : Ada.Interrupts.Interrupt_ID)
> is
> pragma Interrupt_Priority;
>
> entry Wait;
> private
> procedure Handle_Signal;
> pragma Attach_Handler (Handle_Signal, Signal);
>
> Occured : Boolean := False;
> end Signal_Handler;
>
> end Handlers;
>
> package body Handlers is
>
> protected body Signal_Handler is
> procedure Handle_Signal is
> begin
> Occured := True;
> end Handle_Signal;
>
> entry Wait when Occured is
> begin
> if Wait'Count = 0 then
> Occured := False;
> end if;
> end Wait;
> end Signal_Handler;
>
> end Handlers;
>
> The handler is used like this:
>
> with Ada.Text_IO;
> with Ada.Interrupts.Names;
>
> -- Uncommenting the next line breaks interrupt handler
> -- with Ada.Real_Time.Timing_Events;
>
> with Handlers;
>
> procedure Interrupt_Problem is
> use Ada.Interrupts;
>
> Handler : Handlers.Signal_Handler (Signal => Names.SIGTERM);
> begin
>
> if Is_Attached (Interrupt => Names.SIGTERM) then
> Ada.Text_IO.Put_Line ("Attached handler to SIGTERM");
> else
> Ada.Text_IO.Put_Line ("Could not attach to SIGTERM!");
> return;
> end if;
>
> Handler.Wait;
> Ada.Text_IO.Put_Line ("Interrupt received ...");
>
> end Interrupt_Problem;
>
> As expected, when sending SIGTERM to the running 'Interrupt_Problem'
> process "Interrupt received ..." is displayed. So far so good.
>
> As commented in the source code, as soon as the
> Ada.Real_Time.Timing_Events package is with'ed, this mechanism breaks.
>
> The signal handler is not invoked any more when I send a SIGTERM signal
> to a running 'Interrupt_Problem' process, it just terminates without
> triggering the Handler.Wait.
>
> What could be the cause for this behavior?
My guess would be that when Ada.Real_Time.Timing_Events is with'ed,
this causes elaboration code for the Timing_Events package to be
executed (before Interrupt_Problem), and there must be something that
this elaboration does that interferes with the Attach_Handler
mechanism. I can't find anything in the language definition of
Timing_Events that would cause this, so it must be a problem
particular to your Ada compiler implementation, and you should contact
the vendor, or at least let us know what compiler you're using so that
others who may have some knowledge of that particular compiler might
be able to help.
> Is there a problem with this
> code?
Yes, definitely: "occurred" is misspelled. It has two R's. I happen
to know this one very well because I blew this word (or another form,
like "occurrence") in my 8th-grade spelling bee by only putting one R
in it. So you've brought up some memories here.......
-- Adam
^ permalink raw reply [relevance 0%]
* Interrupt handler and Ada.Real_Time.Timing_Events
@ 2009-05-15 16:26 2% Reto Buerki
2009-05-15 16:54 0% ` Adam Beneschan
` (2 more replies)
0 siblings, 3 replies; 133+ results
From: Reto Buerki @ 2009-05-15 16:26 UTC (permalink / raw)
Hi,
I hit a rather strange issue today mixing signal/interrupt handling with
Ada.Real_Time.Timing_Events. We have a real life application where we
use timing events but we also need a signal handler to catch signals
from the environment (SIGTERM etc.).
I wrote a small reproducer to illustrate the problem. The following
protected object is used as an interrupt handler, which can be attached
to a specific interrupt/signal:
with Ada.Interrupts;
package Handlers is
protected type Signal_Handler (Signal : Ada.Interrupts.Interrupt_ID)
is
pragma Interrupt_Priority;
entry Wait;
private
procedure Handle_Signal;
pragma Attach_Handler (Handle_Signal, Signal);
Occured : Boolean := False;
end Signal_Handler;
end Handlers;
package body Handlers is
protected body Signal_Handler is
procedure Handle_Signal is
begin
Occured := True;
end Handle_Signal;
entry Wait when Occured is
begin
if Wait'Count = 0 then
Occured := False;
end if;
end Wait;
end Signal_Handler;
end Handlers;
The handler is used like this:
with Ada.Text_IO;
with Ada.Interrupts.Names;
-- Uncommenting the next line breaks interrupt handler
-- with Ada.Real_Time.Timing_Events;
with Handlers;
procedure Interrupt_Problem is
use Ada.Interrupts;
Handler : Handlers.Signal_Handler (Signal => Names.SIGTERM);
begin
if Is_Attached (Interrupt => Names.SIGTERM) then
Ada.Text_IO.Put_Line ("Attached handler to SIGTERM");
else
Ada.Text_IO.Put_Line ("Could not attach to SIGTERM!");
return;
end if;
Handler.Wait;
Ada.Text_IO.Put_Line ("Interrupt received ...");
end Interrupt_Problem;
As expected, when sending SIGTERM to the running 'Interrupt_Problem'
process "Interrupt received ..." is displayed. So far so good.
As commented in the source code, as soon as the
Ada.Real_Time.Timing_Events package is with'ed, this mechanism breaks.
The signal handler is not invoked any more when I send a SIGTERM signal
to a running 'Interrupt_Problem' process, it just terminates without
triggering the Handler.Wait.
What could be the cause for this behavior? Is there a problem with this
code?
Thanks in advance!
- reto
^ permalink raw reply [relevance 2%]
* Re: Access procedure to pointer
@ 2008-05-29 20:20 1% ` Jeffrey R. Carter
0 siblings, 0 replies; 133+ results
From: Jeffrey R. Carter @ 2008-05-29 20:20 UTC (permalink / raw)
S�bastien wrote:
>
> Ok I use it really often then. Sorry if I'm a bit rude but you can easly
> find POSIX signal implementation in ada in this document.
>
> Ok there is the Signal reference in index "See interrups".
>
> But the first sentence of C.3 is:
> "This clause specifies the language-defined model for hardware
> interrupts in addition to mechanisms for handling interrupts."
I agree. This is a tough area; what constitutes and interrupt is highly
compiler- and platform-dependent. The ARM does a decent job of defining a
platform-independent approach to interrupt handling, but is not a good source
for solutions to platform-dependent concepts such as POSIX signals.
However, the index reference "see interrupts" should indicate that (on some
platforms, at least) "signal" is a synonym for "interrupt" and that in those
cases C.3 applies to them as well. From there you might discover the existence
of Ada.Interrupts.Names, and look at its implementation for your compiler, and
there find SIGHUP as one of the names.
Then again, the ARM is not the most easily read document, and you might not (and
didn't). The Ada-83 RM, while less formal and precise, was much more readable,
and Ada-83 developers often referred to it. Many of us still like to refer to
the ARM. Other sources might be better for others. Many people use the AARM, but
it's not really any better for your problem.
--
Jeff Carter
"Unix and C are the ultimate computer viruses."
Richard Gabriel
99
^ permalink raw reply [relevance 1%]
* Re: Access procedure to pointer
2008-05-28 21:36 2% ` Adam Beneschan
@ 2008-05-28 23:02 0% ` Sebastien Morand
0 siblings, 1 reply; 133+ results
From: Sebastien Morand @ 2008-05-28 23:02 UTC (permalink / raw)
> Right, but the reference manual doesn't say that "interrupts" are
> "Unix signals", even on a Unix-like system, which is to be expected,
> since this is a highly implementation-dependent matter and the RM
> can't be expected to speak on what "interrupts" mean in a particular
> implementation. So the RM can't be expected to help solve Sebastien's
> problem at all. I'd think that GNAT documentation *would* give an
> answer to this, but a quick search of the GNAT documentation that I
> found on AdaCore's site didn't say anything about what the
> "interrupts" in Ada.Interrupts refer to. I may not have been looking
> in the right place, though. I did find the .ads file that defines the
> Ada.Interrupts.Names spec in GNAT's runtime, and that did make it
> clear that "interrupts" are Unix (or Linux or something) signals.
Completly agree. Actually I'm not so sure I have the right link to the manual
you all speak about :-)
There is so many packages in my adainclude directory, that make me sick not to
know what is inside ;-)
Sebastien
^ permalink raw reply [relevance 0%]
* Re: Access procedure to pointer
2008-05-28 15:26 1% ` Jean-Pierre Rosen
@ 2008-05-28 21:36 2% ` Adam Beneschan
2008-05-28 23:02 0% ` Sebastien Morand
0 siblings, 1 reply; 133+ results
From: Adam Beneschan @ 2008-05-28 21:36 UTC (permalink / raw)
On May 28, 8:26 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Sébastien a écrit :>> Why don't you simply use Ada.Interrupts?
>
> > Two reasons:
> > 1) It didn't know it exists
> > 2) It's not documented, and not intuitive, no example nothing to start.
>
> > As a matter of fact, the first problem is solved ;-), if you any help
> > about the second problem, I'll be happy to use standard package instead
> > of mine.
>
> Well, it is documented in the reference manual, and a quick search for
> the word "interrupt" in the index would have put you right there...
Right, but the reference manual doesn't say that "interrupts" are
"Unix signals", even on a Unix-like system, which is to be expected,
since this is a highly implementation-dependent matter and the RM
can't be expected to speak on what "interrupts" mean in a particular
implementation. So the RM can't be expected to help solve Sebastien's
problem at all. I'd think that GNAT documentation *would* give an
answer to this, but a quick search of the GNAT documentation that I
found on AdaCore's site didn't say anything about what the
"interrupts" in Ada.Interrupts refer to. I may not have been looking
in the right place, though. I did find the .ads file that defines the
Ada.Interrupts.Names spec in GNAT's runtime, and that did make it
clear that "interrupts" are Unix (or Linux or something) signals.
-- Adam
^ permalink raw reply [relevance 2%]
* Re: Access procedure to pointer
2008-05-28 10:13 1% ` Jean-Pierre Rosen
2008-05-28 14:57 0% ` Sébastien
@ 2008-05-28 17:00 0% ` Simon Wright
1 sibling, 0 replies; 133+ results
From: Simon Wright @ 2008-05-28 17:00 UTC (permalink / raw)
Jean-Pierre Rosen <rosen@adalog.fr> writes:
> S�bastien a �crit :
>
>> type Signal is (SIGHUP);
>> for Signal use (SIGHUP => 1);
>>
>> type Signal_Callback is access procedure(sig: Signal);
>>
>> procedure InterceptSignal(sig: in Signal; callback: in Signal_Callback);
>>
>> procedure c_signal(sig: in Signal; callback: in System.Address);
>> pragma Import(C, c_signal, "signal");
>>
> Why don't you simply use Ada.Interrupts?
Perhaps because interrupts are not signals? (of course GNAT maps
signals to interrupts for 'complex' targets eg Linux, Windows and I
believe Mac OS X, but on VxWorks interrupts are interrupts and signals
are another matter altogether!)
^ permalink raw reply [relevance 0%]
* Re: Access procedure to pointer
2008-05-28 14:57 0% ` Sébastien
2008-05-28 15:26 1% ` Jean-Pierre Rosen
@ 2008-05-28 15:29 2% ` Sébastien
1 sibling, 0 replies; 133+ results
From: Sébastien @ 2008-05-28 15:29 UTC (permalink / raw)
> 2) It's not documented, and not intuitive, no example nothing to start.
>
> As a matter of fact, the first problem is solved ;-), if you any help
> about the second problem, I'll be happy to use standard package instead
> of mine.
I answer to my own question. Here is a sample code it works fine:
package AdaInterrupsTest is
protected Test is
procedure TestHandler;
pragma Interrupt_Handler(TestHandler);
end Test;
end AdaInterrupsTest;
package body AdaInterrupsTest is
protected body Test is
procedure TestHandler is
begin
Put_Line("Hello from test");
end TestHandler;
end Test;
end AdaInterrupsTest;
procedure TestAdaInterrupt is
use AdaInterrupsTest;
use Ada.Interrupts;
use Ada.Interrupts.Names;
begin
Attach_Handler(Test.TestHandler'Access, SIGHUP);
delay 30.0;
end TestAdaInterrupt;
Then get the pid before the end of the delay and then kill -1 <pid> give
me "Hello from test" on stdout
Thanks about the tip
Sebastien
^ permalink raw reply [relevance 2%]
* Re: Access procedure to pointer
2008-05-28 14:57 0% ` Sébastien
@ 2008-05-28 15:26 1% ` Jean-Pierre Rosen
2008-05-28 21:36 2% ` Adam Beneschan
2008-05-28 15:29 2% ` Sébastien
1 sibling, 1 reply; 133+ results
From: Jean-Pierre Rosen @ 2008-05-28 15:26 UTC (permalink / raw)
S�bastien a �crit :
>> Why don't you simply use Ada.Interrupts?
>
> Two reasons:
> 1) It didn't know it exists
> 2) It's not documented, and not intuitive, no example nothing to start.
>
> As a matter of fact, the first problem is solved ;-), if you any help
> about the second problem, I'll be happy to use standard package instead
> of mine.
>
Well, it is documented in the reference manual, and a quick search for
the word "interrupt" in the index would have put you right there...
However, I think this is an interesting example. I guess the OP simply
thought "oh, I must handle interrupts, therefore I must interface with
the system - i.e. use C)", he didn't even imagine that it was provided
out of the box...
Short answer: to attach statically:
pragma Attach_Handler (PO.P, Interrupt_Number);
to attach dynamically:
Ada.Interrupts.Attach_Handler (PO.P'Access, Interrupt_Number);
Note that the handler must be a *protected* procedure (i.e. a procedure
declared in a protected type), to model the non-reentrant nature of
interrupt handlers.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [relevance 1%]
* Re: Access procedure to pointer
2008-05-28 10:13 1% ` Jean-Pierre Rosen
@ 2008-05-28 14:57 0% ` Sébastien
2008-05-28 15:26 1% ` Jean-Pierre Rosen
2008-05-28 15:29 2% ` Sébastien
2008-05-28 17:00 0% ` Simon Wright
1 sibling, 2 replies; 133+ results
From: Sébastien @ 2008-05-28 14:57 UTC (permalink / raw)
> Why don't you simply use Ada.Interrupts?
Two reasons:
1) It didn't know it exists
2) It's not documented, and not intuitive, no example nothing to start.
As a matter of fact, the first problem is solved ;-), if you any help
about the second problem, I'll be happy to use standard package instead
of mine.
Sebastien
^ permalink raw reply [relevance 0%]
* Re: Access procedure to pointer
@ 2008-05-28 10:13 1% ` Jean-Pierre Rosen
2008-05-28 14:57 0% ` Sébastien
2008-05-28 17:00 0% ` Simon Wright
0 siblings, 2 replies; 133+ results
From: Jean-Pierre Rosen @ 2008-05-28 10:13 UTC (permalink / raw)
S�bastien a �crit :
> type Signal is (SIGHUP);
> for Signal use (SIGHUP => 1);
>
> type Signal_Callback is access procedure(sig: Signal);
>
> procedure InterceptSignal(sig: in Signal; callback: in Signal_Callback);
>
> procedure c_signal(sig: in Signal; callback: in System.Address);
> pragma Import(C, c_signal, "signal");
>
Why don't you simply use Ada.Interrupts?
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [relevance 1%]
* Re: problem with ada.interrupts
2005-08-10 16:01 4% problem with ada.interrupts evangeli
2005-08-10 18:00 1% ` Robert A Duff
2005-08-10 18:19 1% ` jimmaureenrogers
@ 2005-08-25 12:25 2% ` Thierry Pirot
2 siblings, 0 replies; 133+ results
From: Thierry Pirot @ 2005-08-25 12:25 UTC (permalink / raw)
> with
> Ada.Interrupts,
> Ada.Interrupts.Names,
> Ada.Text_Io;
>
> procedure Test is
>
> protected Interruption_Handler is
> procedure SIGINT_Handler;
> end Interruption_Handler;
> protected body Interruption_Handler is
> procedure SIGINT_Handler is
> begin
> Ada.Text_Io.Put_Line("interruption");
> end;
> end Interruption_Handler;
>
> begin
>
> Ada.Interrupts.Attach_Handler(Interruption_Handler.SIGINT_Handler'Access,
> Ada.Interrupts.Names.SIGINT);
> Ada.Text_Io.Put_Line("ok");
> delay 5.0;
> end;
>
>
> this compiles fine, but when i launch it, nothing happens (not even the
> put_line("ok")).
> it seems that even this little program does not terminate :
>
> with
> Ada.Interrupts;
>
> procedure Test is
> begin
> null:
> end;
(My two cents)
How did you launch it ? Maybe you forgot "test" is an internal shell command.
What about
./test
which test
help test
--
Take it Easy Don't worry Be Happy
Thierry
�������o�o��������o�o��������o�o��������o�o��������o�o�������
^ permalink raw reply [relevance 2%]
* Re: problem with ada.interrupts
2005-08-10 16:01 4% problem with ada.interrupts evangeli
2005-08-10 18:00 1% ` Robert A Duff
@ 2005-08-10 18:19 1% ` jimmaureenrogers
2005-08-25 12:25 2% ` Thierry Pirot
2 siblings, 0 replies; 133+ results
From: jimmaureenrogers @ 2005-08-10 18:19 UTC (permalink / raw)
evangeli@cnam.fr wrote:
> hello
> in my program i want to catch the interruption by the user, e.g.,
> ctrl+c.
> i looked at the RM and it seems that package ada.interrupts is designed
> to do this kind of things.
> so i tested this little program (my compiler is gnat 3.15p) :
>
Consider the following statements from the Ada Reference Manual:
The form of a pragma Interrupt_Handler is as follows:
pragma Interrupt_Handler(handler_name);
The form of a pragma Attach_Handler is as follows:
pragma Attach_Handler(handler_name, expression);
Name Resolution Rules
For the Interrupt_Handler and Attach_Handler pragmas, the handler_name
shall resolve to denote a protected procedure with a parameterless
profile.
For the Attach_Handler pragma, the expected type for the expression is
Interrupts.Interrupt_ID (see C.3.2).
Legality Rules
The Attach_Handler pragma is only allowed immediately within the
protected_definition where the corresponding subprogram is declared.
The corresponding protected_type_declaration or
single_protected_declaration shall be a library level declaration.
The Interrupt_Handler pragma is only allowed immediately within a
protected_definition. The corresponding protected_type_declaration
shall be a library level declaration. In addition, any
object_declaration of such a type shall be a library level
declaration.
-------
Your Attach_Handler pragma is misplaced.
You do not have an Interrupt_Handler pragma.
Your protected object is not defined at a library level.
Jim Rogers
^ permalink raw reply [relevance 1%]
* Re: problem with ada.interrupts
2005-08-10 16:01 4% problem with ada.interrupts evangeli
@ 2005-08-10 18:00 1% ` Robert A Duff
2005-08-10 18:19 1% ` jimmaureenrogers
2005-08-25 12:25 2% ` Thierry Pirot
2 siblings, 0 replies; 133+ results
From: Robert A Duff @ 2005-08-10 18:00 UTC (permalink / raw)
evangeli@cnam.fr writes:
> hello
> in my program i want to catch the interruption by the user, e.g.,
> ctrl+c.
> i looked at the RM and it seems that package ada.interrupts is designed
> to do this kind of things.
Yes. I have done this successfully, on both GNAT and Sofcheck's
AdaMagic compilers, on WindowsXP, Linux, and Solaris.
Technically, it is wrong to do I/O in a protected procedure, but some
compilers allow it. You should instead have the handler procedure
trigger an entry barrier, and have some task wait for the entry.
You need a pragma on the SIGINT_Handler. Pragma Attach_Handler is
simpler; Interrupt_Handler is more powerful. See the RM for details.
On GNAT, you need pragma Unreserve_All_Interrupts on some systems.
See the GNAT docs.
> it seems that even this little program does not terminate :
>
> with
> Ada.Interrupts;
>
> procedure Test is
> begin
> null:
> end;
>
> i suspect a problem in the elaboration of package Ada.Interrupts, but i
> have no idea of how to deal with it.
> any idea?
No. You could try stepping through that code in gdb.
- Bob
^ permalink raw reply [relevance 1%]
* problem with ada.interrupts
@ 2005-08-10 16:01 4% evangeli
2005-08-10 18:00 1% ` Robert A Duff
` (2 more replies)
0 siblings, 3 replies; 133+ results
From: evangeli @ 2005-08-10 16:01 UTC (permalink / raw)
hello
in my program i want to catch the interruption by the user, e.g.,
ctrl+c.
i looked at the RM and it seems that package ada.interrupts is designed
to do this kind of things.
so i tested this little program (my compiler is gnat 3.15p) :
with
Ada.Interrupts,
Ada.Interrupts.Names,
Ada.Text_Io;
procedure Test is
protected Interruption_Handler is
procedure SIGINT_Handler;
end Interruption_Handler;
protected body Interruption_Handler is
procedure SIGINT_Handler is
begin
Ada.Text_Io.Put_Line("interruption");
end;
end Interruption_Handler;
begin
Ada.Interrupts.Attach_Handler(Interruption_Handler.SIGINT_Handler'Access,
Ada.Interrupts.Names.SIGINT);
Ada.Text_Io.Put_Line("ok");
delay 5.0;
end;
this compiles fine, but when i launch it, nothing happens (not even the
put_line("ok")).
it seems that even this little program does not terminate :
with
Ada.Interrupts;
procedure Test is
begin
null:
end;
i suspect a problem in the elaboration of package Ada.Interrupts, but i
have no idea of how to deal with it.
any idea?
Thanks for any help
Sami
^ permalink raw reply [relevance 4%]
* Re: Interrupt handler seems not to be called in GNAT 3.15p
2005-06-16 8:03 1% ` Egil H. H�vik
@ 2005-06-16 9:36 0% ` Thorsten
0 siblings, 0 replies; 133+ results
From: Thorsten @ 2005-06-16 9:36 UTC (permalink / raw)
Hi Egil!
> Have you looked at pragma Attach_Handler?
>
> pragma Unreserve_All_Interrupts;
> protected Handler is
> procedure Handle_SIGSEGV;
> pragma Attach_Handler( Handle_SIGSEGV, Ada.Interrupts.Names.SIGSEGV );
> end Handler;
Yes, I also tried with a static signal handler. There is no difference
in behaviour.
I also tried with a task type insted of a protected object - which also
makes no difference.
Regards,
Thorsten
^ permalink raw reply [relevance 0%]
* Re: Interrupt handler seems not to be called in GNAT 3.15p
2005-06-15 15:39 1% Interrupt handler seems not to be called in GNAT 3.15p Thorsten
2005-06-16 6:52 0% ` David C. Hoos, Sr.
@ 2005-06-16 8:03 1% ` Egil H. H�vik
2005-06-16 9:36 0% ` Thorsten
1 sibling, 1 reply; 133+ results
From: Egil H. H�vik @ 2005-06-16 8:03 UTC (permalink / raw)
> When running the program SIGSEGV is raised twice (which I can see only
> in gdb) for the same memory location and the program terminates. If I
> put a delay 5.0 (or some other time) statement just before accessing
> the memory, I also get the output of the exception handler, which
> means an exception (PROGRAM_ERROR) is raised.
>
> Can anyone give me a hint? Is this a known problem with GNAT 3.15p?
> Is it possible to handle SIGSEGV at all in this environment?
Have you looked at pragma Attach_Handler?
pragma Unreserve_All_Interrupts;
protected Handler is
procedure Handle_SIGSEGV;
pragma Attach_Handler( Handle_SIGSEGV, Ada.Interrupts.Names.SIGSEGV );
end Handler;
~egilhh
^ permalink raw reply [relevance 1%]
* Re: Interrupt handler seems not to be called in GNAT 3.15p
2005-06-15 15:39 1% Interrupt handler seems not to be called in GNAT 3.15p Thorsten
@ 2005-06-16 6:52 0% ` David C. Hoos, Sr.
2005-06-16 8:03 1% ` Egil H. H�vik
1 sibling, 0 replies; 133+ results
From: David C. Hoos, Sr. @ 2005-06-16 6:52 UTC (permalink / raw)
To: Thorsten; +Cc: comp.lang.ada
Did you use the pragma Unreserved_all_Interrupts?
See the discussion of that Pragma un the GNAT Reference Manual
----- Original Message -----
From: "Thorsten" <thorsten.behrens@dorunth.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: June 15, 2005 10:39 AM
Subject: Interrupt handler seems not to be called in GNAT 3.15p
> Hi!
>
> I'm currently writing a small package that does a memory dump in an
> 'od' like format. The program is compiled using GNTA 3.15p under Win2k,
> but will be compiled with AdaMulti as well and shall later on run on a
> special hardware.
>
> When accessing memory, I might not have access to some memory location.
> I've therefore implemented an interrupt handler to take care of
> SIGSEGV. This, however, does not seem to be called - at least not under
> Windows (I haven't tested on the target hardware yet, because it has to
> run under Windows as well).
>
> Running the program with gdb, I can see SIGSEGV being raised. However,
> it is not passed to my interrupt handler, but causes the program to
> terminate (as is the "normal" behaviour defined for SIGSEGV).
>
> Here's some code snippets which to me seem quite OK ;-)
>
> package body MONITOR is
> ...
> -- Definition of signal handler to react on SIGSEGV. The procedure
> -- HANDLE_SIGSEGV just sets the boolean variable and returns
> -- therafter to handle the interrupt with a minimum of time. Whether
> -- or not an interrupt occured can be checked with entry
> -- SIGSEGV_RAISED, which is callable then.
> protected SIGNAL_HANDLER is
> pragma UNRESERVE_ALL_INTERRUPTS;
> procedure HANDLE_SIGSEGV;
> pragma INTERRUPT_HANDLER(HANDLE_SIGSEGV);
> entry SIGSEGV_RAISED;
> private
> SIGSEGV_RECEIVED : BOOLEAN := FALSE;
> end SIGNAL_HANDLER;
>
> protected body SIGNAL_HANDLER is
> procedure HANDLE_SIGSEGV is
> begin
> SIGSEGV_RECEIVED := TRUE;
> end HANDLE_SIGSEGV;
>
> entry SIGSEGV_RAISED when SIGSEGV_RECEIVED is
> begin
> IO_PACKAGE.PUT_LINE("There was a SIGSEGV");
> SIGSEGV_RECEIVED := FALSE;
> end SIGSEGV_RAISED;
> end SIGNAL_HANDLER;
>
> ...
>
> begin
>
> ...
>
> if not ATTACHED_SIGSEGV then
> if not ADA.INTERRUPTS.IS_RESERVED(SIGSEGV) then
> begin
> NEW_SIGSEGV_HANDLER := SIGNAL_HANDLER.HANDLE_SIGSEGV'ACCESS;
> ADA.INTERRUPTS.EXCHANGE_HANDLER(OLD_SIGSEGV_HANDLER,
> NEW_SIGSEGV_HANDLER,
> SIGSEGV);
> ATTACHED_SIGSEGV := TRUE;
> exception
> when THE_ERROR: PROGRAM_ERROR =>
> IO_PACKAGE.PUT_LINE
> ("SIGNAL_HANDLER installation: " &
> ADA.TEXT_IO.UTIL.LINE_TERMINATION_STRING &
> ADA.EXCEPTIONS.EXCEPTION_INFORMATION(THE_ERROR));
> raise;
> end;
> end if;
> end if;
>
> ...
>
> -- THE_BUFFER is an array of SYSTEM.STORAGE_ELEMENTs
> for I in THE_BUFFER'RANGE loop
> begin
> -- Access storage only once (i.e. THE_BUFFER(I) is only acessed
> -- here). We add this to the previous value of STORAGE_ELEMENT
> -- (which is 0 in case we format the output in bytes and may hold
> -- the values of upper (double)word(s) in other cases).
> STORAGE_ELEMENT := THE_BUFFER(I);
>
> -- Test, whether there was a segmentation violation when accessing
> -- memory. If it was, the entry of our signal handler is callable
> -- and we will set STORAGE_ELEMENT to 0. Otherwise everything is
> -- fine.
> select
> SIGNAL_HANDLER.SIGSEGV_RAISED;
> STORAGE_ELEMENT := 0;
> else
> null;
> end select;
>
> exception
> when THE_ERROR: others =>
> IO_PACKAGE.DEBUG("Exception " &
> ADA.EXCEPTIONS.EXCEPTION_NAME(THE_ERROR) &
> " is raised when accessing memory!");
> STORAGE_ELEMENT := 0;
> end;
>
> ...
>
> end MONITOR;
>
> When running the program SIGSEGV is raised twice (which I can see only
> in gdb) for the same memory location and the program terminates. If I
> put a delay 5.0 (or some other time) statement just before accessing
> the memory, I also get the output of the exception handler, which
> means an exception (PROGRAM_ERROR) is raised.
>
> Can anyone give me a hint? Is this a known problem with GNAT 3.15p?
> Is it possible to handle SIGSEGV at all in this environment?
>
> Regards,
> Thorsten
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>
>
^ permalink raw reply [relevance 0%]
* Interrupt handler seems not to be called in GNAT 3.15p
@ 2005-06-15 15:39 1% Thorsten
2005-06-16 6:52 0% ` David C. Hoos, Sr.
2005-06-16 8:03 1% ` Egil H. H�vik
0 siblings, 2 replies; 133+ results
From: Thorsten @ 2005-06-15 15:39 UTC (permalink / raw)
Hi!
I'm currently writing a small package that does a memory dump in an
'od' like format. The program is compiled using GNTA 3.15p under Win2k,
but will be compiled with AdaMulti as well and shall later on run on a
special hardware.
When accessing memory, I might not have access to some memory location.
I've therefore implemented an interrupt handler to take care of
SIGSEGV. This, however, does not seem to be called - at least not under
Windows (I haven't tested on the target hardware yet, because it has to
run under Windows as well).
Running the program with gdb, I can see SIGSEGV being raised. However,
it is not passed to my interrupt handler, but causes the program to
terminate (as is the "normal" behaviour defined for SIGSEGV).
Here's some code snippets which to me seem quite OK ;-)
package body MONITOR is
...
-- Definition of signal handler to react on SIGSEGV. The procedure
-- HANDLE_SIGSEGV just sets the boolean variable and returns
-- therafter to handle the interrupt with a minimum of time. Whether
-- or not an interrupt occured can be checked with entry
-- SIGSEGV_RAISED, which is callable then.
protected SIGNAL_HANDLER is
pragma UNRESERVE_ALL_INTERRUPTS;
procedure HANDLE_SIGSEGV;
pragma INTERRUPT_HANDLER(HANDLE_SIGSEGV);
entry SIGSEGV_RAISED;
private
SIGSEGV_RECEIVED : BOOLEAN := FALSE;
end SIGNAL_HANDLER;
protected body SIGNAL_HANDLER is
procedure HANDLE_SIGSEGV is
begin
SIGSEGV_RECEIVED := TRUE;
end HANDLE_SIGSEGV;
entry SIGSEGV_RAISED when SIGSEGV_RECEIVED is
begin
IO_PACKAGE.PUT_LINE("There was a SIGSEGV");
SIGSEGV_RECEIVED := FALSE;
end SIGSEGV_RAISED;
end SIGNAL_HANDLER;
...
begin
...
if not ATTACHED_SIGSEGV then
if not ADA.INTERRUPTS.IS_RESERVED(SIGSEGV) then
begin
NEW_SIGSEGV_HANDLER := SIGNAL_HANDLER.HANDLE_SIGSEGV'ACCESS;
ADA.INTERRUPTS.EXCHANGE_HANDLER(OLD_SIGSEGV_HANDLER,
NEW_SIGSEGV_HANDLER,
SIGSEGV);
ATTACHED_SIGSEGV := TRUE;
exception
when THE_ERROR: PROGRAM_ERROR =>
IO_PACKAGE.PUT_LINE
("SIGNAL_HANDLER installation: " &
ADA.TEXT_IO.UTIL.LINE_TERMINATION_STRING &
ADA.EXCEPTIONS.EXCEPTION_INFORMATION(THE_ERROR));
raise;
end;
end if;
end if;
...
-- THE_BUFFER is an array of SYSTEM.STORAGE_ELEMENTs
for I in THE_BUFFER'RANGE loop
begin
-- Access storage only once (i.e. THE_BUFFER(I) is only acessed
-- here). We add this to the previous value of STORAGE_ELEMENT
-- (which is 0 in case we format the output in bytes and may hold
-- the values of upper (double)word(s) in other cases).
STORAGE_ELEMENT := THE_BUFFER(I);
-- Test, whether there was a segmentation violation when accessing
-- memory. If it was, the entry of our signal handler is callable
-- and we will set STORAGE_ELEMENT to 0. Otherwise everything is
-- fine.
select
SIGNAL_HANDLER.SIGSEGV_RAISED;
STORAGE_ELEMENT := 0;
else
null;
end select;
exception
when THE_ERROR: others =>
IO_PACKAGE.DEBUG("Exception " &
ADA.EXCEPTIONS.EXCEPTION_NAME(THE_ERROR) &
" is raised when accessing memory!");
STORAGE_ELEMENT := 0;
end;
...
end MONITOR;
When running the program SIGSEGV is raised twice (which I can see only
in gdb) for the same memory location and the program terminates. If I
put a delay 5.0 (or some other time) statement just before accessing
the memory, I also get the output of the exception handler, which
means an exception (PROGRAM_ERROR) is raised.
Can anyone give me a hint? Is this a known problem with GNAT 3.15p?
Is it possible to handle SIGSEGV at all in this environment?
Regards,
Thorsten
^ permalink raw reply [relevance 1%]
* Catching Ctrl-C SIGINT
@ 2005-01-17 14:13 1% Christopher Broeg
0 siblings, 0 replies; 133+ results
From: Christopher Broeg @ 2005-01-17 14:13 UTC (permalink / raw)
Hi,
I am having some trouble with protected types. I am trying to do some
cleanup work if the user presses Ctrl-C SIGINT.
For this I wrote a little test program. The problem is getting the
information about the raised interrupt back to the main program. I tried
using a little task that calls a entry in a protected type:
with Catch_Interrupt;
with Ada.Text_IO;use Ada.Text_IO;
procedure Test1 is
Stop: exception;
task Get_Info is
entry Stop;
end Get_info;
task body Get_Info is
begin
loop
Catch_Interrupt.Event.wait;
-- here comes the code that handles the interrupt received
select
accept Stop do
Stop;
end Stop;
or
terminate;
end select;
end loop;
end Get_Info;
begin
for i in 1 .. 5 loop
Put(Integer'Image(i));
delay 1.0;
end loop;
end Test1;
the package actually doing the interrupt catching is:
with Ada.Interrupts;
with Ada.Interrupts.names;
package Catch_Interrupt is
Sig_Int_Caught : exception;
procedure Signal_Public;
protected Catch_Interrupt is
procedure Clean_up;
pragma Unreserve_All_Interrupts;
--pragma interrupt_Handler(Clean_Up);
pragma Attach_Handler(Clean_Up,Ada.Interrupts.Names.SIGINT);
end Catch_Interrupt;
protected Event is
entry Wait;
procedure Signal;
private
Allowed : Boolean := False;
end Event;
end Catch_Interrupt;
with Ada.Text_IO;
use Ada.Text_IO;
package body Catch_Interrupt is
procedure Signal_Public is
begin
Event.Signal;
end Signal_Public;
protected body Catch_Interrupt is
procedure Clean_up is
begin
Put_line("Interrupt SIGINT caught. sending signal ");
Signal_public;
Put_line("SIGNAL SENT. ");
end Clean_Up;
end Catch_Interrupt;
protected body Event is
entry Wait when allowed is
begin
Put_line("catch_interrupt msg: in entry wait");
end Wait;
procedure Signal is
begin
Put_line("Signal received!!!");
Allowed := True;
end Signal;
end Event;
end Catch_Interrupt;
Here the problem:
I do get the message
"Interrupt SIGINT caught. sending signal "
but the signal_public procedure never manages to send the signal. I
don't know why. If I call the signal_public procedure from test1 it
works, but is of course useless.
Can you give me any hints on what I am doing wrong? I am lost.
Maybe there is a better way to react upon the interrupt? But still I am
wondering why my solution is not working.
Thanx a lot,
Chris
^ permalink raw reply [relevance 1%]
* Catching Ctrl-C SIGINT
@ 2005-01-17 14:07 1% Christopher Broeg
0 siblings, 0 replies; 133+ results
From: Christopher Broeg @ 2005-01-17 14:07 UTC (permalink / raw)
Hi,
I am having some trouble with protected types. I am trying to do some
cleanup work if the user presses Ctrl-C SIGINT.
For this I wrote a little test program. The problem is getting the
information about the raised interrupt back to the main program. I tried
using a little task that calls a entry in a protected type:
with Catch_Interrupt;
with Ada.Text_IO;use Ada.Text_IO;
procedure Test1 is
Stop: exception;
task Get_Info is
entry Stop;
end Get_info;
task body Get_Info is
begin
loop
Catch_Interrupt.Event.wait;
-- here comes the code that handles the interrupt received
select
accept Stop do
Stop;
end Stop;
or
terminate;
end select;
end loop;
end Get_Info;
begin
for i in 1 .. 5 loop
Put(Integer'Image(i));
delay 1.0;
end loop;
end Test1;
the package actually doing the interrupt catching is:
with Ada.Interrupts;
with Ada.Interrupts.names;
package Catch_Interrupt is
Sig_Int_Caught : exception;
procedure Signal_Public;
protected Catch_Interrupt is
procedure Clean_up;
pragma Unreserve_All_Interrupts;
--pragma interrupt_Handler(Clean_Up);
pragma Attach_Handler(Clean_Up,Ada.Interrupts.Names.SIGINT);
end Catch_Interrupt;
protected Event is
entry Wait;
procedure Signal;
private
Allowed : Boolean := False;
end Event;
end Catch_Interrupt;
with Ada.Text_IO;
use Ada.Text_IO;
package body Catch_Interrupt is
procedure Signal_Public is
begin
Event.Signal;
end Signal_Public;
protected body Catch_Interrupt is
procedure Clean_up is
begin
Put_line("Interrupt SIGINT caught. sending signal ");
Signal_public;
Put_line("SIGNAL SENT. ");
end Clean_Up;
end Catch_Interrupt;
protected body Event is
entry Wait when allowed is
begin
Put_line("catch_interrupt msg: in entry wait");
end Wait;
procedure Signal is
begin
Put_line("Signal received!!!");
Allowed := True;
end Signal;
end Event;
end Catch_Interrupt;
Here the problem:
I do get the message
"Interrupt SIGINT caught. sending signal "
but the signal_public procedure never manages to send the signal. I
don't know why. If I call the signal_public procedure from test1 it
works, but is of course useless.
Can you give me any hints on what I am doing wrong? I am lost.
Maybe there is a better way to react upon the interrupt? But still I am
wondering why my solution is not working.
Thanx a lot,
Chris
^ permalink raw reply [relevance 1%]
* Catching Ctrl-C SIGINT
@ 2005-01-17 12:26 1% Christopher Broeg
0 siblings, 0 replies; 133+ results
From: Christopher Broeg @ 2005-01-17 12:26 UTC (permalink / raw)
Hi,
I am having some trouble with protected types. I am trying to do some
cleanup work if the user presses Ctrl-C SIGINT.
For this I wrote a little test program. The problem is getting the
information about the raised interrupt back to the main program. I tried
using a little task that calls a entry in a protected type:
with Catch_Interrupt;
with Ada.Text_IO;use Ada.Text_IO;
procedure Test1 is
Stop: exception;
task Get_Info is
entry Stop;
end Get_info;
task body Get_Info is
begin
loop
Catch_Interrupt.Event.wait;
-- here comes the code that handles the interrupt received
select
accept Stop do
Stop;
end Stop;
or
terminate;
end select;
end loop;
end Get_Info;
begin
for i in 1 .. 5 loop
Put(Integer'Image(i));
delay 1.0;
end loop;
end Test1;
the package actually doing the interrupt catching is:
with Ada.Interrupts;
with Ada.Interrupts.names;
package Catch_Interrupt is
Sig_Int_Caught : exception;
procedure Signal_Public;
protected Catch_Interrupt is
procedure Clean_up;
pragma Unreserve_All_Interrupts;
--pragma interrupt_Handler(Clean_Up);
pragma Attach_Handler(Clean_Up,Ada.Interrupts.Names.SIGINT);
end Catch_Interrupt;
protected Event is
entry Wait;
procedure Signal;
private
Allowed : Boolean := False;
end Event;
end Catch_Interrupt;
with Ada.Text_IO;
use Ada.Text_IO;
package body Catch_Interrupt is
procedure Signal_Public is
begin
Event.Signal;
end Signal_Public;
protected body Catch_Interrupt is
procedure Clean_up is
begin
Put_line("Interrupt SIGINT caught. sending signal ");
Signal_public;
Put_line("SIGNAL SENT. ");
end Clean_Up;
end Catch_Interrupt;
protected body Event is
entry Wait when allowed is
begin
Put_line("catch_interrupt msg: in entry wait");
end Wait;
procedure Signal is
begin
Put_line("Signal received!!!");
Allowed := True;
end Signal;
end Event;
end Catch_Interrupt;
Here the problem:
I do get the message
"Interrupt SIGINT caught. sending signal "
but the signal_public procedure never manages to send the signal. I
don't know why. If I call the signal_public procedure from test1 it
works, but is of course useless.
Can you give me any hints on what I am doing wrong? I am lost.
Maybe there is a better way to react upon the interrupt? But still I am
wondering why my solution is not working.
Thanx a lot,
Chris
^ permalink raw reply [relevance 1%]
* Re: system interrupt handler programming on a PC under windows
2004-11-24 12:11 1% system interrupt handler programming on a PC under windows Adrien Plisson
@ 2004-11-24 14:55 0% ` Steve
0 siblings, 0 replies; 133+ results
From: Steve @ 2004-11-24 14:55 UTC (permalink / raw)
IMHO it is very likely you would be better off interfacing to the vendors
library using the C interface.
Ada has very nice capabilites for interfacing with C (see Interfaces.C).
In my experience interfacing with hardware only starts with following the
documentation. It is followed by identifying what features of the hardware
don't work properly and creating work-arounds.
Several years ago I started to write a serial driver for a PC. Well defined
interface to hardware, right? When I started having difficulties with
misbehavior, I took a look at IBM's driver that was included with OS/2.
IBM's driver had a bunch of extra code to identify the maker of the serial
hardware and disable specific features that didn't work for specific
hardware. Better to use someone elses work on this.
Also, I have run into several cases when I asked vendors about library
support for Ada (thinking they might already have a binding), the common
response is: can't be done. I usually generate my own binding, which
demonstrates their ignorance.
Steve
(The Duck)
"Adrien Plisson" <aplisson-news@stochastique.net> wrote in message
news:41a47994$0$13459$ba620e4c@news.skynet.be...
> hello everyone !
>
> i wonder if anyone can explain me (or give me a pointer to an explanation)
how
> i can set up an interrupt handler under windows to interact with a PCI
board
> plugged into my computer.
>
> in my company we are using a PCI I/O board which is only programmable
through
> the use of a library available only for C, VB and Pascal. i would like to
> interract with this board from Ada, but writing a thin binding over the
library
> does not lead to anything useful. so i would like to create a really thick
> binding by interacting directly with the board.
>
> this board is very well documented: i have all the interresting values
address
> expressed in term of BASE address + offset and all seems ok for me to read
or
> write them (or they wouldn't have documented this).
>
> but i need to set up an interrupt handler to get notified of events. i
started
> using Ada.Interrupts but discovered that the I/O board interrupt is
reserved so
> i can't register my own interrupt handler.
>
> so, how can I override the default handler ? is it safe to do it ? what
about
> shared interrupts ? in short, i want to know everything you can tell me
about
> system interrupt handling from Ada...
>
> thanks in advance.
>
> --
> rien
^ permalink raw reply [relevance 0%]
* system interrupt handler programming on a PC under windows
@ 2004-11-24 12:11 1% Adrien Plisson
2004-11-24 14:55 0% ` Steve
0 siblings, 1 reply; 133+ results
From: Adrien Plisson @ 2004-11-24 12:11 UTC (permalink / raw)
hello everyone !
i wonder if anyone can explain me (or give me a pointer to an explanation) how
i can set up an interrupt handler under windows to interact with a PCI board
plugged into my computer.
in my company we are using a PCI I/O board which is only programmable through
the use of a library available only for C, VB and Pascal. i would like to
interract with this board from Ada, but writing a thin binding over the library
does not lead to anything useful. so i would like to create a really thick
binding by interacting directly with the board.
this board is very well documented: i have all the interresting values address
expressed in term of BASE address + offset and all seems ok for me to read or
write them (or they wouldn't have documented this).
but i need to set up an interrupt handler to get notified of events. i started
using Ada.Interrupts but discovered that the I/O board interrupt is reserved so
i can't register my own interrupt handler.
so, how can I override the default handler ? is it safe to do it ? what about
shared interrupts ? in short, i want to know everything you can tell me about
system interrupt handling from Ada...
thanks in advance.
--
rien
^ permalink raw reply [relevance 1%]
* Re: SIGINT problem under LINUX
@ 2004-06-16 11:13 2% ` Jeff C,
0 siblings, 0 replies; 133+ results
From: Jeff C, @ 2004-06-16 11:13 UTC (permalink / raw)
"Radek Kotowicz" <kor@li.pl> wrote in message
news:51bc4db.0406160129.7cb72fb8@posting.google.com...
> Hi,
> I'm facing the following problem. I have written a signal handler for
> SIGINT and a few other signals. The program performs as expected when
> I type CTRL+C, but somehow the signal isn't handled or delivered when
> I issue `kill -s SIGINT <pid>`. There is only one process of my app
> running.
> Is there at all any way the program can infer what does the signal
> come from - I guess it cannot carry any extra info with it.
> Does anyone have any clue what the problem is?
>
> Thanx in advance,
> Radek Kotowicz
> --
Though it does not sound like the exact problem that you are seeing, it is
probably work a re-read of the GNAT RM and one of the GNAT header files to
see if you can gleen any useful information from it.
pragma Unreserve_All_Interrupts
Syntax:
pragma Unreserve_All_Interrupts;
Normally certain interrupts are reserved to the implementation.
Any attempt to attach an interrupt causes Program_Error to be raised, as
described in RM C.3.2(22). A typical example is the SIGINT interrupt used in
many systems for an Ctrl-C interrupt. Normally this interrupt is reserved to
the implementation, so that Ctrl-C can be used to interrupt execution.
If the pragma Unreserve_All_Interrupts appears anywhere in any unit in a
program, then all such interrupts are unreserved. This allows the program to
handle these interrupts, but disables their standard functions. For example,
if this pragma is used, then pressing Ctrl-C will not automatically
interrupt execution. However, a program can then handle the SIGINT interrupt
as it chooses.
For a full list of the interrupts handled in a specific implementation, see
the source code for the specification of Ada.Interrupts.Names in file
a-intnam.ads. This is a target dependent file that contains the list of
interrupts recognized for a given target. The documentation in this file
also specifies what interrupts are affected by the use of the
Unreserve_All_Interrupts pragma.
^ permalink raw reply [relevance 2%]
* Re: Signal handler blocks proteced type
2004-03-25 17:05 1% Lutz Donnerhacke
@ 2004-03-26 10:00 1% ` Lutz Donnerhacke
0 siblings, 0 replies; 133+ results
From: Lutz Donnerhacke @ 2004-03-26 10:00 UTC (permalink / raw)
* Lutz Donnerhacke wrote:
> A protected type with a signal handler is instantiated in order to catch a
> signal. If the signal is not catched, everything works fine. If the signal
> was delivered, the inner scope will not be terminated, because the protected
> type can not be finalized.
>
> Why?
Ada.Interrupts.Detach_Handler is broken. It does not return if the signal
was delivered.
Changing the example to 'pragma Interrupt_Handler' and an explicit
Attach_Handler works fine (termination of the enviroment task succeeds).
Any call to Detach_Handler after a signal delivery results in a blocking
runtime call.
select
delay 2.0;
else abort
Detach_Handler(SIGHUP);
end select;
does not work. Even an Abort_Task call from an other task has no effect.
The runtime (Linux-Threads) seems to miss an SIGCHILD and waits forever for
the wrong clone.
^ permalink raw reply [relevance 1%]
* Signal handler blocks proteced type
@ 2004-03-25 17:05 1% Lutz Donnerhacke
2004-03-26 10:00 1% ` Lutz Donnerhacke
0 siblings, 1 reply; 133+ results
From: Lutz Donnerhacke @ 2004-03-25 17:05 UTC (permalink / raw)
The following test program shows a strange behavior:
A protected type with a signal handler is instantiated in order to catch a
signal. If the signal is not catched, everything works fine. If the signal
was delivered, the inner scope will not be terminated, because the protected
type can not be finalized.
Why?
Ok, there is a zombie afterwards.
\f
with Ada.Text_IO; use Ada.Text_IO;
with Ints;
procedure t is
begin
Put_Line("Enviroment started.");
declare
i : Ints.Int;
begin
Put_Line("Waiting.");
delay 2.0;
if i.Found then
Put_Line("Catched.");
else
Put_Line("Nothing.");
end if;
end;
Put_Line("Enviroment stopped.");
end t;
\f
Example:
$ ./t
Enviroment started.
Waiting.
Nothing.
Enviroment stopped.
$ ./t & sleep 1; kill -1 %1; sleep 3
[1] 2366
Enviroment started.
Waiting.
Catched.
$ jobs
[1]+ Running ./t &
$ pstree
|-sh-+-pstree
| `-t---(t)
\f
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
package Ints is
protected type Int is
procedure Signal;
pragma Attach_Handler(Signal, SIGHUP);
procedure Reset;
function Found return Boolean;
private
catched : Boolean := False;
end Int;
end Ints;
\f
package body Ints is
protected body Int is
procedure Signal is
begin
catched := True;
end Signal;
procedure Reset is
begin
catched := False;
end Reset;
function Found return Boolean is
begin
return catched;
end Found;
end Int;
end Ints;
^ permalink raw reply [relevance 1%]
* Signal handler blocks proteced type
@ 2004-03-25 17:03 1% Lutz Donnerhacke
0 siblings, 0 replies; 133+ results
From: Lutz Donnerhacke @ 2004-03-25 17:03 UTC (permalink / raw)
The following test program shows a strange behavior:
A protected type with a signal handler is instantiated in order to catch a
signal. If the signal is not catched, everything works fine. If the signal
was delivered, the inner scope will not be terminated, because the protected
type can not be finalized.
Why?
\f
with Ada.Text_IO; use Ada.Text_IO;
with Ints;
procedure t is
begin
Put_Line("Enviroment started.");
declare
i : Ints.Int;
begin
Put_Line("Waiting.");
delay 2.0;
if i.Found then
Put_Line("Catched.");
else
Put_Line("Nothing.");
end if;
end;
Put_Line("Enviroment stopped.");
end t;
\f
Example:
$ ./t
Enviroment started.
Waiting.
Nothing.
Enviroment stopped.
$ ./t & sleep 1; kill -1 %1; sleep 3
[1] 2366
Enviroment started.
Waiting.
Catched.
$ jobs
[1]+ Running ./t &
\f
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
package Ints is
protected type Int is
procedure Signal;
pragma Attach_Handler(Signal, SIGHUP);
procedure Reset;
function Found return Boolean;
private
catched : Boolean := False;
end Int;
end Ints;
\f
package body Ints is
protected body Int is
procedure Signal is
begin
catched := True;
end Signal;
procedure Reset is
begin
catched := False;
end Reset;
function Found return Boolean is
begin
return catched;
end Found;
end Int;
end Ints;
^ permalink raw reply [relevance 1%]
* Re: gnat/linux:setitimer
@ 2004-01-15 3:35 2% ` Tilman Glotzner
0 siblings, 0 replies; 133+ results
From: Tilman Glotzner @ 2004-01-15 3:35 UTC (permalink / raw)
1) How do I monitor signals with gdb ?
I know of the "handle <signal> print" command, and the "handle <signal>
stop" command.
I tried to set a breakpoint with "catch signal 14", but gdb tells me, that
this feature is not yet implemented (My version of gdb is 5.1.1).
Are there any other ways ?
2) I tried to to export all signal related code to c, and released all
signals by using pragma Unreserve_All_Interrupts (see program below). The
signal is not catched either:
Even though setitimer returns a 0 (=success), I am suspecious if the
SIG_ALRM signal is really sent.
Or maybe gnat's runtime library uses that signal even though it should be
release released by pragma Unreserve_All_Interrupts
--------------------------------------------------------------
-- Filename: timer_test.adb
-- Desc: Test program for timer package
--
-- (c) 2003 Tilman Glotzner, DG2TG
--
-- History:
-- Date Name Descrition
-- 2003-12-08 T. Glotzner Creation
--------------------------------------------------------------
pragma Unreserve_All_Interrupts;
with Text_Io,Ada.Interrupts,Ada.Interrupts.Names;
use Text_Io,Ada.Interrupts,Ada.Interrupts.Names;
procedure Timer_Test_A is
Counter: Integer := 0;
I: Integer := 20;
procedure Settimer;
pragma Import (C,Settimer);
begin
New_line;
Put_Line("Timer_Test_A");
Put_Line("==========");
Settimer;
Put_Line("I := " & I'Img);
while (Counter <= I) loop
null;
Counter := Counter + 1;
delay(0.5);
-- Put_Line("Counter = " & Counter'Img);
end loop;
end Timer_Test_A;
// Filename: setitimer.c
#include<stdlib.h>
#include<stdio.h>
#include<signal.h>
#include<time.h>
#include<unistd.h>
#include<sys/time.h>
void sigalrm_dispatcher(int signal)
{
printf("sigalarm dispatcher started (%d)\n",signal);
}
int settimer()
{
int status;
struct itimerval timer;
/* initial interval */
timer.it_value.tv_sec = 2;
timer.it_value.tv_usec = 100000;
/* subsequent intervals */
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = 500000;
if (SIG_ERR == signal ( SIGALRM, sigalrm_dispatcher ))
{
printf("Installation of signal handler failed.\n");
}
else
{
printf("Installation of signal handler successful.\n");
}
status = setitimer( ITIMER_REAL, &timer, NULL );
printf("settimer executed (Status=%d).\n",status);
}
Thanks,
Tilman
Mark H Johnson
Mark H Johnson wrote:
> TIlman Glotzner wrote:
>> Hello,
>>
>> below my attempt to connect the linux system timer to an ada program.
>> 1) In the process list, I see the program distributed over 5
>> processes. Each signal handler is mapped onto one process. One
>> process is probably needed for the main program. On which part
>> of the program are the other 2 processes mapped to ?
>>
>
> The GNAT implementation of tasks on Linux (up until *very* recently) has
> processes for
> - the main program
> - a thread manager
> - a thread per signal being managed
> - a thread per task
> and they show up as individual processes in ps, top, etc. We ended up
> writing a small library package that would write a file in /tmp/ that
> had our "task name" so we could correlate between PID's and tasks.
>
> When I mean "very recently", if you are using the new pthread library
> (e.g., Red Hat 9 or later), the rules have changed somewhat and I
> haven't used it enough to comment on it.
>
>> 2) When the timer expires, the timer signal (SIGALRM) is not catched
>> by the signal handler. The signal handlers itselves apparrently work as
>> the handlers react to signals sent by a unix kill command. As
>> process number I need to give the PID of the appropriate signal
>> handler. I suspect that the signal is sent to the process that
>> started the itimer. As the signal signal handlers run as
>> separated processes, the SIGALRM signal issued from the itimer does not
>> reach the signal handlers. What do I need to do to make it work ?
>>
> What we do instead is to:
> - determine the process group
> - use killpg instead of kill to send the signal to the process group
> In this case, the signal is delivered to all the threads and all but one
> thread will ignore it. Only the signal handler will catch it and process
> it.
>
>> 3) Is there a unix utility that allows me to monitor signals,
>> i.e. which program issues which signal, and which program catches it ?
>>
> The latter part can be done with the debugger (gdb). I am not aware of
> any utility to tell you who sent the signal.
>
>> 4) I first tried to import the system call "setitimer", and hand over
>> setitimer's parameters by access types(ITimervalPtrs'address). The
>> program also compiles if handing over the variables directly (not
>> references to the variables). Is gnat/ada doing a parameter conversion to
>> a reference implicitly for me ?
>>
> Not sure, we have C code that actually calls setitimer in our system
> :-). You should be able to do something like...
> pragma Interface(C, Setitimer);
> and use declarations that are compatible with C to call setitimer
> directly from Ada. We do that for a lot of other functions but just not
> that one.
>
> You may also need
> pragma Unreserve_All_Interrupts;
> since the run time may also be trapping the specific signals you are
> trying to use.
> --Mark
--
Tilman Glotzner
ETAS Ltd, Seoul, Korea
^ permalink raw reply [relevance 2%]
* gnat/linux:setitimer
@ 2004-01-03 18:52 2% TIlman Glotzner
0 siblings, 1 reply; 133+ results
From: TIlman Glotzner @ 2004-01-03 18:52 UTC (permalink / raw)
Hello,
below my attempt to connect the linux system timer to an ada program.
1) In the process list, I see the program distributed over 5
processes. Each signal handler is mapped onto one process. One
process is probably needed for the main program. On which part
of the program are the other 2 processes mapped to ?
2) When the timer expires, the timer signal (SIGALRM) is not catched
by the signal handler. The signal handlers itselves apparrently work as
the handlers react to signals sent by a unix kill command. As
process number I need to give the PID of the appropriate signal
handler. I suspect that the signal is sent to the process that
started the itimer. As the signal signal handlers run as
separated processes, the SIGALRM signal issued from the itimer does not
reach the signal handlers. What do I need to do to make it work ?
3) Is there a unix utility that allows me to monitor signals,
i.e. which program issues which signal, and which program catches it ?
4) I first tried to import the system call "setitimer", and hand over
setitimer's parameters by access types(ITimervalPtrs'address). The
program also compiles if handing over the variables directly (not
references to the variables). Is gnat/ada doing a parameter conversion to
a reference implicitly for me ?
Thank you,
Tilman
--------------------------------------------------------------
-- Filename: timer.ads
--------------------------------------------------------------
with Type_Defs,System.Address_To_Access_Conversions,Ada.Interrupts.Names;
use Type_Defs,Ada.Interrupts, Ada.Interrupts.Names;
package Timer is
-- Timers run in real time.
ITIMER_REAL: constant := 0;
-- Timers run only when the process is executing.
ITIMER_VIRTUAL: constant := 1;
-- Timers run when the process is executing and when
-- the system is executing on behalf of the process.
ITIMER_PROF: constant := 2;
type T_Time is new Long_Integer;
type T_Timeval is record
Tv_Sec : T_Time; -- seconds
Tv_Usec: T_Time; -- microseconds
end record;
type T_Itimerval is record
It_Interval: T_Timeval; -- next value
It_Value: T_Timeval; -- current Value
end record;
package TimevalPtrs is new System.Address_To_Access_Conversions(
T_Timeval );
package ITimervalPtrs is new System.Address_To_Access_Conversions(
T_Itimerval );
protected SignalHandler is
-- SIGINT (Control-C) signals will be intercepted by
-- HandleControlC
procedure HandleControlPwrFail;
pragma Attach_Handler( HandleControlPwrFail, SIGPWR );
-- Signal handler for SIGALARM issued from a timer
procedure HandleAlarm;
pragma Attach_Handler( HandleAlarm, SIGALRM );
end SignalHandler;
procedure Setitimer(RC:out Integer; Which: in Integer ;
Value: in out T_Itimerval;
Ovalue: in out T_Itimerval);
pragma Import (C,Setitimer);
pragma Import_Valued_Procedure(Setitimer);
end Timer;
--------------------------------------------------------------
-- Filename: timer.adb
--------------------------------------------------------------
with Timer, System.Address_To_Access_Conversions,Text_IO;
use Timer,Text_Io;
package body Timer is
protected body SignalHandler is
-- This protected type contains all our signal handlers
procedure HandleAlarm is
-- Alarm signal handler
begin
Put_Line( "HandleAlarm: ALARMSIG catched." );
end HandleAlarm;
procedure HandleControlPwrFail is
-- Power fail signal handler
begin
Put_Line( "HandleControlPwrFail activated by catched signal SIGPWR"
);
end HandleControlPwrFail;
end SignalHandler;
end Timer;
--------------------------------------------------------------
-- Filename: timer_test.adb
--------------------------------------------------------------
with Text_Io,Timer,Ada.Interrupts,Ada.Interrupts.Names;
use Text_Io,Timer,Ada.Interrupts,Ada.Interrupts.Names;
procedure Timer_Test_B is
Handler : Parameterless_Handler;
Counter: Integer := 0;
Timer: aliased T_Itimerval := ((0,10000),(0,10000));
OldTimer: aliased T_Itimerval := ((0,0),(0,0));
I: Integer := 20;
begin
Put_Line("Timer_Test");
Put_Line("==========");
Timer.It_Value.Tv_Sec := 0;
Timer.It_Value.Tv_Usec := 100000;
Timer.It_Interval.Tv_Sec := 0;
Timer.It_Interval.Tv_Usec := 100000;
if Is_Reserved( SIGALRM ) then
Put_Line( "The ALARMSIG handler is reserved" );
else
Put_Line( "The ALARMSIG handler isn't reserved" );
end if;
if Is_Attached( SIGALRM ) then
Put_Line( "The ALARMSIG handler is attached" );
else
Put_Line( "The ALARMSIG handler isn't attached" );
end if;
if Is_Reserved( SIGPWR ) then
Put_Line( "The SIGPWR handler is reserved" );
else
Put_Line( "The SIGPWR handler isn't reserved" );
end if;
if Is_Attached( SIGPWR ) then
Put_Line( "The SIGPWR handler is attached" );
else
Put_Line( "The SIGPWR handler isn't attached" );
end if;
New_Line;
Put_Line( "Testing SIGALRM handler..." );
Handler := Current_Handler( SIGALRM );
-- Current_Handler gives a callback to the handler
Handler.all;
Put_Line( "End testing SIGALRM handler..." );
New_Line;
Put_Line( "Testing SIGPWR handler..." );
Handler := Current_Handler( SIGPWR );
-- Current_Handler gives a callback to the handler
Handler.all;
Put_Line( "End testing SIGPWR handler..." );
New_Line;
Put_Line("Timer parameters");
Put_Line("----------------");
Put_Line("Time.sec = " & Timer.It_Value.Tv_Sec'Img );
Put_Line("Time.usec= " & Timer.It_Value.Tv_Usec'Img );
Put_Line("Preset.sec = " & Timer.It_Interval.Tv_Sec'Img );
Put_Line("Preset.usec= " & Timer.It_Interval.Tv_Usec'Img );
New_Line;
Put("Arming timer...");
Setitimer(I,ITIMER_REAL,Timer,OldTimer);
-- ITimervalPtrs.To_Address(Timer'Unchecked_access),
-- ITimervalPtrs.To_Address(OldTimer'Unchecked_Access));
Put_Line(" Timer armed.");
New_Line;
Put_Line("I := " & I'Img);
while (Counter <= I) loop
null;
-- Counter := Counter + 1;
-- delay(1.0);
end loop;
end Timer_Test_B;
--
Tilman Gloetzner
ETAS Korea Ltd, Seoul, Korea
^ permalink raw reply [relevance 2%]
* strange execution error
@ 2003-02-22 22:31 2% alfonso acosta
0 siblings, 0 replies; 133+ results
From: alfonso acosta @ 2003-02-22 22:31 UTC (permalink / raw)
Hi:
I recently started a project in savannah called adabot
(https://savannah.nongnu.org/projects/adabot/). Its a realtimebattle
(http://realtimebattle.sourceforge.net/) bot developed completely in Ada.
The problem I have, is the following:
When trying to test a package which isnt finished (messages.ads in
http://savannah.nongnu.org/cgi-bin/viewcvs/adabot/adabot/src/)
with this procedure:
-----
with Ada.Strings.Unbounded.Text_IO, Ada.Interrupts.Names ;
use Ada.Strings.Unbounded.Text_IO, Ada.Interrupts.Names, Ada.Interrupts;
procedure Messages.Test is
Msg : Msg_From_Robot;
Str : Unbounded_String;
begin
Msg := (RobotOption, (Signal, SIGUSR1));
Msg2Str (Msg, Str);
Put (Str);
end Messages.Test;
-----
After compiling with GNAT I execute it and it gets completely frozen,
the most curious about it is that 4 processes are created. Gdb tells me
the error comes from messages.adb line 152:
Append(Source => Str,
New_Item => Interrupt_ID'Pos(Msg.Value.Which));
but I dont understand why its wrong
Can anybody have a look at the code?
Thanks in advance:
Alfonso Acosta
PS: If anyone is interested in the project Ill be pleased to give
him/her a CVS write account (Its obvoius that Im not an experienced Ada
programmer and need some help)
^ permalink raw reply [relevance 2%]
* Re: tasking programs built with GNAT insensitive to SIGTERM
@ 2003-02-04 19:55 1% ` Craig Carey
0 siblings, 0 replies; 133+ results
From: Craig Carey @ 2003-02-04 19:55 UTC (permalink / raw)
On Wed, 29 Jan 2003 15:54:38 -0600, Mark Johnson
<mark_h_johnson@raytheon.com> wrote:
>Oliver Kellogg wrote:
...
>> Under Linux, how come tasking programs built with GNAT
>> (3.2, but other versions as well) don't react to
>> "kill -TERM" ?
>>
>> Is there a trick to make them killable?
>>
For GNAT 3.15p in Linux with native threads, attaching a signal handler
for SIGTERM (see below) fixes the problem so that the thread can be
terminated with "kill -s TERM <pid>".
Unfortunately 3 new threads that ignored SIGTERM are added if the
method is used (but it is better, since all 4 die if the right thread
is TERM-ed). I sent in a bug report saying that 4 is too many.
>> See also http://gcc.gnu.org/cgi-bin/gnatsweb.pl
>> bug number 9480.
>>
>Hmm. Very odd behavior. You can probably get what you want by using
> pragma Interrupt_State (SIGTERM, System);
>
What is the compiler that implements a pragma 'Interrupt_State' ?.
(The GNAT compiler I tried didn't understand that pragma).
>Which forces SIGTERM to be handled as a "system" interrupt. See the GNAT
The simple example of problem 9480 did not try to handle SIGTERM signals.
>Reference Manual for more details. I ran a test program and it appears
>to do what you want it to.
>
>It is odd enough - I may forward it to ACT to see what they say about
>it.
Any information on when GNAT will run as well in Linux as it does in
Windows 200 ?: one Ctrl-C (a plain Windows signal) and the program is
100% removed from memory.
> Also note - you DO have to hit one of the threads that has that
>signal enabled to make it terminate the program. The main program is OK
Isn't that a compiler vendor or OS bug?. SIGKILL terminates all of the
4 threads no matter which of that signal is sent to, so why have only
one of the four take all four down when SIGTERM is the signal ?.
>(usually the process with the lowest PID), but the thread manager
>(usually main PID +1) has the signal masked.
Here is solution but it is not as good as would be hoped for.
(1) The 1.3 second delay statement can be replaced with a 'Timed Entry
Call':
AARM 9.7.2 Timed Entry Calls:
http://www.adaic.org/standards/95aarm/html/AA-9-7-2.html
-- A protected object stops blocking when SIGTERM was receieved
select
Signals.Shutdown;
goto ... -- exit program
or
delay 1.3;
end select;
...
protected Signals is
procedure SIGTERM_Handler; -- unblocks the Shutdown barrier
pragma Interrupt_Handler (SIGTERM_Handler);
pragma Attach_Handler (SIGTERM_Handler,
Ada.Interrupts.Names.SIGTERM);
If the delay was much bigger than 1.3 secs, and also C's exit() was used
to close the program, then the program would readily be stuck in memory
as a zombie, at least in Linux and Linux emulators.
If exit() is not used then the Timed Entry Call is more likely to be
used.
G. A. Craig Carey
http://www.ijs.co.nz/ada_95.htm
^ permalink raw reply [relevance 1%]
* Re: ANNOUNCE: Free GNU Ada Run-Time Book (version 1.0)
@ 2002-12-16 21:07 1% javiermirandag
0 siblings, 0 replies; 133+ results
From: javiermirandag @ 2002-12-16 21:07 UTC (permalink / raw)
porton@ex-code.com (Victor Porton) wrote:
>In article <mailman.1040061302.21020.comp.lang.ada@ada.eu.org>,
> Javier Miranda <javiermirandag@netscape.net> writes:
>> porton@ex-code.com wrote:
>>
>>>In article <mailman.1040039941.9447.comp.lang.ada@ada.eu.org>,
>>> Javier Miranda <javiermirandag@netscape.net> writes:
>>>
>>>>Victor Porton wrote:
>>>>
>>>>
>>>I'm just a user. So will this book benefit me as a GNAT user
>>>except of that I would possibly learn something new about
>>>system programming in general?
>>>
>>>
>> You will learn why your program run.
>
>We are more interested in the cases why it does not run
>like possible bad interinfluences of Ada tasks and POSIX
>threads...
Victor,
That's is another thing you can read in the book (chapters 2 and 3).
In addition, in chapter 4 you can learn how protected objects are
implemented (with POSIX mutexes), and in chapter 6 you can learn
how the POSIX signals are handled by the Run-Time to implement
the Ada interrupts semantics.
In general, understanding the underlying technology helps you
writing better programs.
-- Javier Miranda
----------------------------------------------------------------
A Detailed Description of the GNU Ada Run-Time (J.Miranda, 2002)
Free book available at:
http://www.iuma.ulpgc.es/users/jmiranda
----------------------------------------------------------------
__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
^ permalink raw reply [relevance 1%]
* Re: On-Screen Elapsed Time Display?
2002-10-11 18:54 1% On-Screen Elapsed Time Display? Dr Nancy's Sweetie
@ 2002-10-11 19:32 0% ` Jeffrey Carter
0 siblings, 0 replies; 133+ results
From: Jeffrey Carter @ 2002-10-11 19:32 UTC (permalink / raw)
Dr Nancy's Sweetie wrote:
> I searched Google a few times for this, and didn't seem to find it,
> but maybe I just couldn't think of the Right Magic Keywords. So
> this is probably a stupid newbie question that's been answered 100
> times. (Maybe the next person to search on the keywords I came up
> with will find this article and the helpful replies.)
>
> I have written a game, and thought it might be more interesting with
> "best times" file, so people can compete with each other. It's
> easy enough to add in something like this:
>
> type Time_T is new Long_Integer;
> Start_Time, Win_Time: Time_T;
> procedure Time ( Time : in out Time_T);
> pragma Import (C, Time);
You could also use Ada.Calendar (or Ada.Real_Time if that's not accurate
enough :).
>
> and then set Win_Time when the player wins, subtract, and figure out
> how long it took.
>
> What I don't see easily (and maybe I'm just blind) is a good way to
> get a display on the screen (the game uses ncurses) during play.
> I can update the clock every time someone pushes a key, of course,
> but that's kinda lame.
>
> What I probably need is some Ada version setitimer(). Then it's
> just a matter of set up a function that displays the clock, hook the
> function to SIGALRM, and set the timer to 900ms. I found the pragma
> "Attach_Handler", and also found SIGALRM in Ada.Interrupts.Names.
> But what's the Ada equivalent of "setitimer();"?
>
> I can import setitimer(), and make Ada versions of struct timerval
> and itimerval, but that's starting to feel like I'm overusing C,
> and depending on Unixisms (which is bad for portability).
>
> What is the Right Thing to do? I'm using GNAT, if that makes any
> difference.
Maybe you want another task that updates the time display every so often
using "delay until". Then, of course, you have 2 tasks writing to the
display, so you need to protect it, but that's simple enough. Create a
protected queue on which tasks can put Strings to be displayed and the
position at which to display them, then have a 3rd task that takes
things off this queue and does the display. Have the queue block the
display task if the queue is empty.
When dealing with an inherently concurrent problem, things are usually
simpler if you use high-level concurrency constructs.
--
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
^ permalink raw reply [relevance 0%]
* On-Screen Elapsed Time Display?
@ 2002-10-11 18:54 1% Dr Nancy's Sweetie
2002-10-11 19:32 0% ` Jeffrey Carter
0 siblings, 1 reply; 133+ results
From: Dr Nancy's Sweetie @ 2002-10-11 18:54 UTC (permalink / raw)
I searched Google a few times for this, and didn't seem to find it,
but maybe I just couldn't think of the Right Magic Keywords. So
this is probably a stupid newbie question that's been answered 100
times. (Maybe the next person to search on the keywords I came up
with will find this article and the helpful replies.)
I have written a game, and thought it might be more interesting with
"best times" file, so people can compete with each other. It's
easy enough to add in something like this:
type Time_T is new Long_Integer;
Start_Time, Win_Time: Time_T;
procedure Time ( Time : in out Time_T);
pragma Import (C, Time);
and then set Win_Time when the player wins, subtract, and figure out
how long it took.
What I don't see easily (and maybe I'm just blind) is a good way to
get a display on the screen (the game uses ncurses) during play.
I can update the clock every time someone pushes a key, of course,
but that's kinda lame.
What I probably need is some Ada version setitimer(). Then it's
just a matter of set up a function that displays the clock, hook the
function to SIGALRM, and set the timer to 900ms. I found the pragma
"Attach_Handler", and also found SIGALRM in Ada.Interrupts.Names.
But what's the Ada equivalent of "setitimer();"?
I can import setitimer(), and make Ada versions of struct timerval
and itimerval, but that's starting to feel like I'm overusing C,
and depending on Unixisms (which is bad for portability).
What is the Right Thing to do? I'm using GNAT, if that makes any
difference.
Thanks,
Darren
Darren Provine ! kilroy@elvis.rowan.edu ! http://www.rowan.edu/~kilroy
"Everybody writes that we have no chance, but, you know, the horse can't
read." -- Wilson Brown, trainer of Kentucky Derby entry It'sallinthechase,
May 2002 (odds 50-1 against)
^ permalink raw reply [relevance 1%]
* Re: implementation approach
@ 2002-07-31 13:59 2% ` SteveD
0 siblings, 0 replies; 133+ results
From: SteveD @ 2002-07-31 13:59 UTC (permalink / raw)
"Mark" <ma740988@pegasus.cc.ucf.edu> wrote in message
news:a5ae824.0207301854.3295f3a2@posting.google.com...
[snip]
>
> I suspect I'll need two semaphores on both processors. Once the flag
> gets passed from processor B to processor A, the routine in A will
> enter the semaphore command the device, release the flag, etc.
>
> Thanks in advance
In Ada an interrupt is associated with a protected procedure in a protected
type. An example of how to set this up is in the LRM C.3.2(28).
I haven't done any Ada Interrupt handling myself, but I believe this is the
way it's done.
With Ada.Interrupts;
Package Body Interrupt_Test Is
Protected Type Device_Interface(Int_Id : Ada.Interrupts.Interrupt_ID) Is
Procedure Handler;
Pragma Attach_Handler( Handler, Int_Id );
Entry Wait_Interrupt;
Private
Occurred : Boolean := False;
End Device_Interface;
Protected Body Device_Interface Is
Procedure Handler Is
Begin
Occurred := TRUE;
End Handler;
Entry Wait_Interrupt When Occurred Is
Begin
Occurred := False;
End Wait_Interrupt;
End Device_Interface;
Device_1_Driver : Device_Interface( 1 );
Task Relay Is
End Relay;
Task Body Relay Is
Begin
Loop
Device_1_Driver.Wait_Interrupt;
-- Do something when the interrupt occurs
End Loop;
End Relay;
End Interrupt_Test;
I hope this helps,
SteveD
^ permalink raw reply [relevance 2%]
* ACT announces availability of GNAT 3.14p
@ 2002-01-31 2:49 1% Robert Dewar
0 siblings, 0 replies; 133+ results
From: Robert Dewar @ 2002-01-31 2:49 UTC (permalink / raw)
Ada Core Technologies (ACT) has made available at the NYU
site (ftp://cs.nyu.edu/pub/gnat) GNAT 3.14p builds for the
following targets:
MS Windows (NT/2K)
Sparc Solaris (2.5.1 through 2.8)
GNU Linux (Redhat 6.2)
The above are the official platforms, but in practice the
NT version works reasonable well on Win 98 and Win ME and
other versions of GNU Linux including Debian GNU/Linux are
known to be compatible with this version of GNAT.
These are the only public versions that ACT plans to build.
As always, the releases contain the full sources, and we
invite volunteers to create builds for other platforms. We
also draw attention to the availability of source snapshots
for the current development version of GNAT (similar to the
3.15 release, but on GCC 3, rather than GCC 2). The above
public versions are still based on ACT's 2.8.1 GCC version.
These versions are provided without any warranty or
guarantee of any kind, and no support of any kind is
available for these public versions from ACT. They are
provided as a service for use by students, hobbyists and
researchers who need access to a high quality Ada 95
system.
If you need a supported commercial Ada 95 compiler, we
recommend the use of our GNAT Pro product. In particular,
we do not recommend the use of the public version for
formal evaluation purposes. Contact sales@gnat.com
or sales@act-europe.fr for further details on GNAT Pro,
including the availability of evaluation versions.
Robert Dewar
Ada Core Technologies
The following is a list of new features available in 3.14
as compared with 3.13.
GNAT 3.14p NEW FEATURES LIST
============================
Copyright (c) 2001, Ada Core Technologies
This file contains a complete list of new features in
version 3.14p of GNAT. A full description of all GNAT
features can be found in the GNAT User Guide and GNAT
Reference Manual.
NF-314-5827-001 New -u switch for gnatmake
The command gnatmake -u only recompiles the main file when
needed. Gnatmake can now be used as the main and only
interface to the compiler since a single compilation can be
launched with "gnatmake -u -f".
NF-314-6806-001 Source reference pragmas read by gnatchop
The gnatchop utility now recognizes and respects existing
source reference pragmas that it finds in the input file,
so that the output files always properly reflect the
original source file.
NF-314-6813-011 Asis queries to evaluate static expressions
A new set of queries is added to package Asis.Extensions.
These queries allows an ASIS application to evaluate the
value of a discrete static expressions and to get the low
and high bound of a static 'Range attribute. The results
are returned as string images of expression values, The
'Pos value is returned for enumeration expressions. See
specification of Asis.Extensions for more details.
NF-314-7001-006 Better messages on non-visible entities
The warnings for non-visible entities have been improved to
exclude implicit entities, and entities declared in the
private part of GNAT internal units. This results in more
helpful error messages for undefined variables.
NF-314-7008-003 New package GNAT.Sockets
This package provides a high level interface to the sockets
API. Most of the features are implemented. This high
level and portable interface is based on the
GNAT.Sockets.Thin API which is a thin binding to the OS
sockets API.
NF-314-7110-008 New package GNAT.Most_Recent_Exception
This package provides subprograms giving access to the
exception occurrence, or exception occurrence access for
the most recently raised exception. Unlike the routines in
GNAT.Current_Exceptions, these routines do not have to be
called statically from within an exception handler.
NF-314-7207-004 Issue error for bad Source_Reference pragma
The Source_Reference pragma is (and always has been)
required to be the first line of the file. This is now
clearly documented, and a diagnostic is issued if the first
Source_Reference pragma is not the first line in the file.
NF-314-7207-006 Warn when Duration unexpectedly used
A new warning has been added when a universal fixed
expression is interpreted as type Standard.Duration.
Although this is correct according to RM semantics, it is
almost always suspicious and represents an unintended
meaning.
NF-314-7215-008 Improve msg for missing WITH of predef unit
The error message handling for cases of forgotten WITH's of
predefined library routines has been improved.
NF-314-7314-004 Remove useless initialization checks
Initialization procedures for arrays were doing unnecessary
subscript range checks, that have now been suppressed,
since an out of range condition is impossible in this
context.
NF-314-7418-008 New switch for gnatchop to exit on errors
The new -x gnatchop switch causes gnatchop to exit on
detecting parse errors. Now gnatchop also sets the exit
status to indicate errors.
NF-314-7506-010 Improve message for access param comparison
A comparison of an access parameter with null is illegal.
This was always caught by GNAT but with a confusing error
message that complained about the types of the operands.
Now a specific error mesage is given pointing out that it
is not allowed for an access parameter to be null in the
first place.
NF-314-7509-002 Improve warning for possibly null values
The warning for possibly null values has been improved to
be more precise and to catch some previously uncaught
cases.
NF-314-7515-007 Multiple Source_Reference pragmas allowed
It is now permitted for a single file to have more than one
Source_Reference pragma. All pragmas must refer to the
same original file, but the sections referenced need not be
contiguous. This permits correct processing of files with
configuration pragmas that are chopped using gnatchop with
the -c and -r switches.
NF-314-7516-012 Better warning messages for Storage_Error
In some cases, a warning about possible storage error was
posted on the offending statement in a generic template.
Now the message is always on the relevant instantiation
with a pointer to the generic template location.
NF-314-7524-009 GNAT version string is in executable
The executable now contains a string identifying the GNAT
version in the form "GNAT Version: xxx(xxx)" where
xxx(xxx) is the version number. The external name of this
constant is __gnat_version.
NF-314-7530-009 Consistency checking for -gnatE mode
Units compiled with -gnatE and without -gnatE can be mixed
under certain conditions, now properly documented in the
GNAT Users Guide. The binder now checks that the rules for
safe mixing are properly followed.
NF-314-7606-012 Improve equality ambiguity error messages
In the case of ambiguous operands for equality, -gnatf now
gives details on the possible resolutions discovered by the
compiler, making it easy to diagnose the cause of this
error in non-obvious situations.
NF-314-7607-007 Improved control for NT temporary files
Under NT, it is now possible to control where temporary
files are created. First, the TMP environment variable is
checked, and if this is set, it specifies the directory to
be used. If TMP is not set, then c:\temp is used. If both
of these checks fail, then, and only then, is the current
working directory used.
NF-314-7611-007 Warnings for WITH of internal GNAT unit
The only units that should be WITH'ed by application
programs are those that are documented in the RM or in the
GNAT documentation. Any WITH of an internal GNAT
implementation unit not documented in one of these two
locations now generates a warning. This warning can be
controlled individually by use of the -gnatwi/-gnatwI
switches. It is on by default.
NF-314-7614-005 Avoid use of a-types.h in runtime
The use of a-types.h is now avoided in building the runtime
library. This reduces unnecessary symbol table and debug
information
NF-314-7619-008 Access to source related information
A new package GNAT.Source_Info provides some useful utility
subprograms that provide access to source code informations
known at compile time, such as file name, line number and
enclosing entity.
NF-314-7620-002 More flexible source file naming
The Source_File_Name pragma has been enhanced so that it
can provide general pattern driven rules for constructing
file names. The scheme is powerful enough to accomodate
all common schemes for deriving file names from unit name
that we are aware of, and in particular it supports
standard schemes used by other Ada 95 compilers. This
means that for most purposes the large set of
Source_File_Name pragmas can be replaced by two pragmas,
giving pattern rules for bodies and specs.
NF-314-7622-004 New packages for CGI programming
A new package GNAT.CGI provides basic services for CGI
(Common Gateway Interface) programming. A subsidiary
package GNAT.CGI.Cookies provides facilities for dealing
with "cookies" (data kept in Web client software). A third
package GNAT.CGI.Debug provides debugging facilities.
Between them, these packages enable an easy interface for
Web programming from Ada.
NF-314-7626-013 Automatic backtraces during exception
handling
A new package GNAT.Exception_Traces is now available for
platforms on which the backtrace features is implemented.
This provides a feature for enabling automatic output of
backtraces upon exception occurrences. Two options are
available, enabling traces either for every occurrence or
only for occurrences that are not caught by a user defined
handler. The latter is typically useful to get traces when
a task dies because of an unhandled exception.
NF-314-7708-001 New Setenv procedure in GNAT.OS_Lib.
A procedure Setenv has been added in GNAT.OS_Lib. This
procedure can be used to add or remove environment
variables for the current and child process. This is not
yet supported under VMS, but is fully supported for all
other GNAT ports.
NF-314-7709-004 New unit GNAT.AWK (AWK style file parsing)
A new package GNAT.AWK (file g-awk.ads) provides AWK-like
file parsing with an easy interface for parsing one or more
files containing formatted data. The file is viewed as a
database where each record is a line and a field is a data
element in this line.
NF-314-7711-001 New function Paren_Count in GNAT.Regpat
A new function Paren_Count is now provided in GNAT.Regpat
to return the maximum number of parentheses pairs in the
compiled regular-expression.
NF-314-7712-005 Support for honoring gcc -fno-common
The -fno-common gcc command line option is now recognized.
The use of this option causes the allocation of
uninitialized global variables to be moved to the bss
section of the object file, rather than generating them as
common blocks. This solves problems caused by the presence
of a symbol both in a library and in an explicitly linked
object file.
NF-314-7713-002 Improved error message placement
The error message noting that only subtype marks can be
used in a generic array formal are now more accurately
placed and point specifically to the offending construct.
NF-314-7713-003 Front-end inlining
The -gnatN switch enables front-end inlining. In this
compilation mode, the front-end replaces a call to a
subprogram that has an Inline pragma by the expanded body
of the subprogram, provided the body is short enough. This
supplements the inlining performed by the GCC back-end.
NF-314-7717-001 Task_Name pragma provided to set task name
A new pragma Task_Name can be used in a task definition to
specify the name used for a task for debugging purposes and
by Ada.Task_Identification.Image. The argument is the task
name, and can be an expression referencing the task
discriminants, allowing different names to be given to
different instances of the same task type.
NF-314-7718-001 Linker_Options extensions now documented
The documentation (GNAT Reference Manual) has been enhanced
to contain full documentation of the GNAT implementation of
the Linker_Options pragma. GNAT allows multiple arguments,
and also allows the use of ASCII.NUL to separate arguments
in a single string.
NF-314-7718-003 New warning option to detect hiding
New flags -gnatwh/-gnatWH are provided to enable/disable
checking for the case where an inner entity hides an outer
one. This is of course legal, but in some environments
such hiding is discouraged, and this warning option (which
is by default off) can be used to enforce this requirement.
Note that the common case of one character identifiers such
as I,J,K is excluded from consideration.
NF-314-7721-002 Improved range analysis for subtraction
The circuit for range analysis for subtraction has been
enhanced. This eliminates some range checks, and some
additional warnings at compile time for cases where the
result is known to be out of range.
NF-314-7721-003 Implement range analysis 'Length
Range analysis for the Length attribute has been added,
resulting in elimination of some range checks, and also
some additional warnings at compile time for cases where
the result is known to be out of range
NF-314-7722-016 Improved error msg for name conflict
The error message for a conflict between an enumeration
literal and a later declared constant of the same name has
been improved.
NF-314-7723-005 GLIDE xref works even if compile errors
The new switch -gnatQ can be used to force generation of an
ALI file even if there are compile errors. This is most
useful in connection with GLIDE and similar tools, since it
means that cross-reference information is available even
after compiler errors.
NF-314-7723-012 Unreferenced labels generate warnings
In -gnatwu mode, GNAT now diagnoses labels that are not
referenced other than by their initial occurrence.
NF-314-7731-012 New unit GNAT.Dynamic_Tables
A new package GNAT.Dynamic_Tables provides a resizable
one-dimensional array. It is similar to GNAT.Table except
that the table type is a declared type, so that it can be
used in more general contexts.
NF-314-7801-005 Warning for aliased discriminanted objects
GNAT now generates a warning for an assignment to an
aliased discriminated object that is known to generate a
constraint error at run time.
NF-314-7802-002 GLIDE can go to any file in error message
When an error message from the compiler includes several
file:line references, it is now possible to click on any of
them to display the appropriate file, instead of just the
first one.
NF-314-7814-013 x86 stack traceback for foreign threads
Under x86 targets it is possible to get the stack traceback
through a foreign thread. This is true for unhandled
exceptions and for GNAT.Traceback services.
NF-314-7817-001 GNAT now compatible with Solaris 2.8
GNAT is now fully compatible with Solaris 2.8. This
includes proper building and operation of the florist
package (which did need some modifications to be 2.8
compatible).
NF-314-7820-008 Better 'Valid handling for large subtypes
If an object of a discrete type has a larger size than the
base type (e.g. from the use of a component clause in a
record representation clause), then 'Valid will check all
the bits of the object (previously the code simply use part
of the field, which was an allowable implementation
according to the RM, but nevertheless surprising).
NF-314-7821-010 ASIS tutorial is available
A simple hands-on ASIS tutorial is added to the ASIS
distribution. It consists of two parts. One part is based
on the asistant tool and the task is to get the initial
experience with using ASIS queries. Another part is based
on the ASIS application templates and the task is to
implement simple ASIS tools starting from these templates.
For all the tasks full documented solutions are provided.
NF-314-7821-008 ASIS application templates are available
A set of ASIS application templates is added as a part of
the ASIS distribution. This set contains the Ada
components which are the same or very similar for many
ASIS-based tools. These templates may be used as a "quick
start" for ASIS beginners.
NF-314-7822-009 Dynamic elaboration checks improved
Elaboration checks are suppressed for calls to subprograms
in packages to which a pragma Elaborate applies. The cases
of Elaborate_All and Elaborate_Body already suppressed the
check, but checks were not suppressed for Elaborate.
NF-314-7826-009 gnatdll supports binder arguments
Gnatdll now supports the -bargs parameter passing arguments
to the binder. For example, this can be used to build a
DLL with stack tracebacks stored in the exception
occurences (gnatbind -E option).
NF-314-7826-010 pragma Comment restriction removed
The placement of pragma Comment is now unrestricted. This
pragma can appear anywhere within the main unit, including
as the first line of the file.
NF-314-7827-011 Control of warnings for address overlays
The warning switch -gnatwo turns on overlay warnings for
address clauses where implict initialization can cause the
overlaid memory to be clobbered. The swich -gnatwO turns
off these warnings. The warnings have been implemented for
a while. What is new is allowing them to be selectively
turned off (the default is that this warning is enabled).
NF-314-7829-002 Control over validity checking is provided
GNAT now provides a new switch -gnatVx that allows you to
control the level of validity checking. The options are
n/d/f for none/default/full. None means no checking for
invalid data, default (which is the default setting)
provides sufficient checking to meet the requirements of
the RM, and full provides extensive validity checking,
particularly useful when used with Normalize_Scalars.
NF-314-7829-003 New warning for hiding loop variables
A common mistake for those familiar with other languages is
to fail to realize that a for loop implicitly declares the
loop variable, and programmers provide a useless and unused
outer level variable definition with the same name. GNAT
now specifically detects this situation and provides an
explicit warning.
NF-314-7830-008 ASIS Corresponding_Name_Definition_List
The Asis.Expressions.Corresponding_Name_Definition_List
query in ASIS for GNAT is now fully implemented.
NF-314-7830-014 New warning for overlay by access type
The warning for possible unexpected initialization has been
extended to include access types. The warning is generated
if an access type has an address clause causing overlay,
and there is no pragma Import, so that initialization to
null will take place. Note that NF-314-7827-011 gives the
capability of controlling such warnings. Note also that
GNAT 3.13p had a (now corrected error) that caused such
expected initializations to be omitted.
NF-314-7906-017 New package Ada.Interrupts.Signal
A new package Ada.Interrupts.Signal (file a-intsig.ads) has
been created to provide an easier and more portable way of
generating Ada95 interrupts.
NF-314-7910-004 Uniform behavior for Slice subprograms
In packages Ada.Strings.Bounded/Ada.Strings.Unbounded, the
Slice function now returns with the bounds of the slice
expressions, rather than with a lower bound of 1. This was
discussed in the ISO WG9 ARG, and it was agreed that this
was the preferable approach. This change also improves the
efficiency of these two functions.
NF-314-7914-009 Optimization for object declarations
If an object is declared with an unconstrained nominal type
and the expression is a function call, it is in general
necessary to compute the result of the call first and then
copy that result into the object, after deter- mining the
bounds. GNAT now suppresses that copy in many cases. The
copy is still used if the type is controlled, if it is
classwide, or if the object is declared at the library
level.
NF-314-7918-012 Enhanced variant of Spawn in GNAT.OS_Lib
In the package GNAT.OS_Lib, a new Spawn function now
returns the exit status of the executed command as an
Integer value. The existing Spawn procedure only gives a
boolean result.
NF-314-7924-003 Immediate output switch (-gnate) replaced
The immediate output switch -gnate is no longer defined,
reflecting the fact that this is intended only for use in
diagnostic mode following a compiler crash. In those cases
where this is needed, the effect can be obtained by use of
the -gnatdO debug switch. The purpose of this change is to
avoid accidental use of this switch, which disables many
useful error message circuits.
NF-314-7925-003 Protected types visible in entities menu
In addition to subprograms, types and tasks, the entities
menu in GLIDE now includes an entry for protected objects
and types. This is also available in the speedbar panel.
NF-314-7926-006 Allow SPARK annotations in -gnatyc mode
The -gnatyc mode now allows comments starting with --x
where x is any special character in the lower half of the
ASCII range (16#21#..16#2F#,16#3A#..16#3F#). This in
particular allows the --# comments that appear as
annotations in the Praxis SPARK language.
NF-314-7929-004 Value_Size and Object_Size output by -gnatR
The -gnatR switch now outputs Value_Size and Object_Size
separately for types where these two values are different.
If the values are the same, then the output simply lists
this common value as the Size value.
NF-314-7930-001 Value_Size and Object_Size for all types.
The Value_Size and Object_Size can now be separately
specified for composite types (records and arrays). The
meaning is as for scalar types. The Value_Size is used for
unchecked conversion and packing purposes, and the
Object_Size is used for allocation of objects.
NF-314-7930-006 New attribute Standard'Wchar_T_Size
This attribute returns the size of the C type wchar_t,
which may differ from the Ada Wide_Character type. The
attribute is primarily intended for the construction of the
wchar_t type in Interfaces.C.
NF-314-7930-007 Changed children of System to be pure
Many more packages in the System hierarchy have been marked
pure. This change documents that the functions in those
packages are in fact side-effect free, which gives the
compiler more optimization opportunities.
NF-314-7931-001 Additional in-place assignments for
aggregates
Assignments of the form: S (1 .. N) := (others => Expr);
are now performed in place, without generating a temporary
for the aggregate (as long as Expr is independent of S, of
course). In addition, array assignments where the
right-hand side is an aggregate with only an others clause
are performed in place even if the bounds of the array are
non-static.
NF-314-7931-002 Improved handling of enumeration image
tables
The handling of enumeration type image tables (for support
of the Value, Image, and Width attributes for enumeration
types has been improved). The tables are now generated
statically, and are significantly smaller than they were
previously (1-4 bytes overhead per entry instead of 12-15).
NF-314-7931-003 NT Win32Ada binding reformatted for -gnaty
The sources of Win32Ada binding were reformatted to meet
the style requirements for compiling with the -gnaty
switch.
NF-314-8001-002 The -gnatg switch is now fully documented
The -gnatg switch is the GNAT internal implementation
switch. It is intended only for use by GNAT itself. The
documentation now fully describes this switch and explains
why it should not be used by application programs.
NF-314-8004-004 Unchecked_Conversion now fully documented
The GNAT Reference Manual now contains complete
documentation on the approach used by GNAT in handling
unchecked conversions where the sizes of the source and
target types are different.
NF-314-8006-002 Improved output for representation
information
The -gnatR switch now takes an optional parameter which can
have the value 0,1,2. No representation output is
generated in -gnatR0 mode. In -gnatR1 (same as -gnatR),
representation information is generated for arrays and
records. For -gnatR2, representation information for all
user declared types and objects is generated.
NF-314-8010-003 Detect duplicate Value/Object_Size clauses
The appearence of more than one Value_Size or Object_Size
clause for a single entity, which was previously allowed
(with the earlier one being ignored), is now detected as an
error, which seems more appropriate and more consistent
with the treatment of duplicate Size clauses.
NF-314-8010-005 Spell checking in GLIDE
The standard ispell command can now be used to spell check
the comments while editing an Ada source file. The
checking only applies to comments and not to Ada source
code other than comments.
NF-314-8010-012 More flexible GNAT.Threads.Create_Thread
Create_Thread now returns the task id so that this value is
easily known on the client side.
NF-314-8012-002 New warning for unexpected rounding
Warn in cases where the static evaluation rules of Ada as
described in RM 4.9(38) result in different rounding than
would have been obtained at runtime. This rule is a rather
surprising one, and has caused confusion in the past.
NF-314-8014-002 Additional information on unused entities
Warning messages on unused entities (generated by compiling
with -gnatwu) now indicate the kind (variable, function,
etc) of the entity to which the warning applies.
Cross-references are now generated when an entity appears
as a default actual in an instantiation. This inhibits
warnings if the entity is not used explicitly elsewhere,
and is also used by tools that rely on xref information
(e.g. GLIDE).
NF-314-8019-001 Documentation on variant object size
An extensive section has been added to the GNAT Reference
manual describing how GNAT treats the Size attribute when
applied to variant record objects.
NF-314-8022-004 Improved documentation for -gnato switch
More extensive documentation is provided for the -gnato
switch that enables overflow checking, emphasizing that
overflow checking is off by default, and explaining the
rationale behind treating overflow checks differently from
other kinds of range checks.
NF-314-8023-003 Document Size Limit
GNAT enforces a maximum Size of objects of 2**31-1, which
since Size is in bits, corresponds to a size of 256
megabytes. This limit has always been enforced, but it is
now properly documented in the GNAT Reference Manual.
NF-314-8023-005 Improved documentation for GNAT.Task_Lock
The documentation for GNAT.Task_Lock has been enhanced to
make it clear that calling Lock multiple times from the
same task works as expected for nested use of Lock/Unlock.
NF-314-8024-002 C_Pass_By_Copy convention now standardized
The implementation of the C_Pass_By_Copy convention has
been modified to be consistent with the agreed
specification in AI95-00131, which is part of the official
technical corrigendum for Ada 95. For GNAT, the
modification is that now C_Pass_By_Copy is rejected for any
entities other than record types and subtypes. Convention
C can always be used instead for other entities (GNAT used
to treat C_Pass_By_Copy as identical to C for other
entities).
NF-314-8025-009 Documentation of GNAT Library Units
The GNAT Reference Manual now contains complete reference
documentation for all GNAT specific units in the GNAT,
System, Interfaces, and System. This includes several
units that have been present in GNAT, but not previously
documented, including System.Address_Image (to convert
Address values to strings) and Ada.Command_Line.Remove (for
logically removing command line arguments).
NF-314-8028-002 SIGUSR1/SIGUSR2 now handled in GNU/Linux
Using native threads (aka LinuxThreads), it was not
possible to handle the SIGUSR1 and SIGUSR2 signals. This
limitation has now been removed. This change affects all
versions of GNAT for GNU/Linux including Debian GNU/Linux
and also Redhat Linux.
NF-314-8030-011 New style-check for exit of named loop
The -gnatye switch now includes checking for missing exit
labels. It will now cause a warning to be posted if an
exit statement appears which refers to a labeled loop but
the statement does not include the label.
NF-314-8030-014 Improved output from gnatbind -e switch
The output now excludes all output for gnat internal units.
The dependency information for internal units is of
interest only for implementors, and tends to be voluminous
and useless for normal use. A -de debug flag is introduced
to provide the old behavior for system implementors use.
NF-314-8031-012 More extensive misspelling warnings
The error messages for undefined variables now include
additional cases where a suggestion of a possible
misspelling is provided. This message now includes cases
where the entity is in a with'ed package and has explicit
qualification.
NF-314-8031-013 Nested package bodies included in -gnatR
The output from the -gnatR switch now includes declarations
that appear in nested package bodies.
NF-314-8031-019 Clear labeling of output in -gnatR output
The output from the -gnatR switch now makes it clear
whether the unit for which representation information is
listed is a spec or a body.
NF-314-8101-005 Alignment warnings for bad address clauses
It is the program's responsibility to ensure that the value
in an address clause is consistent with (i.e. a multiple
of) the alignment of the object to which it is applied, and
in general this cannot be checked at compile time. However
it is possible to post warnings in some cases where the
value is known at compile time and is clearly wrong, and
this is now done.
NF-314-8104-007 New Glide variable
ada-prj-gnatfind-switches
This variable can be customized to change the default
switches used for gnatfind when you select the menu item
"Show All References". For example this can be used to add
the -a switch, in case you often work with read-only ALI
files.
NF-314-8105-007 New convention Win32 equivalent to Stdcall
The convention Win32 is now recognized as equivalent to
Stdcall or DLL (all three conventions are identical in
effect and considered to be conformant). This eases
porting of code from other compilers that use this
convention name.
NF-314-8106-010 New unit Ada.Exceptions.Is_Null_Occurrence
This GNAT addition to the Ada hierarchy allows a program to
test if an occurrence is the null occurrence
(Null_Occurrence) without enerating an exception. This
capability is not present in the predefined subprograms in
Ada.Exceptions.
NF-314-8106-010 Warnings for useless type conversions
A warning can be generated for type conversions of the form
a(b) where b is a simple entity name which is of type a
(i.e. the conversion has no effect). This warning is
normally off but can be set on by the use of
@code{-gnatwr}.
NF-314-8106-011 Warnings for useless assignments
A warning can be generated for assignments of the form a :=
a; (i.e. assignments of a variable to itself) which are
obviously useless. This warning is normally off but can be
set on by the use of @code{-gnatwr}.
NF-314-8108-006 Warnings for accidental hiding by child
unit
A warning is generated when a child unit in the context of
a parent hides a compilation unit of the same name. For
example, Foo.Ada, if it appears in the context of the body
of Foo, will hide an occurrence of the predefined Ada in
the same context, which can lead to surprising visibility
errors later on.
NF-314-8108-004 Better error messages for bad array
aggregate
If an array aggregate is missing elements (e.g. it has the
index values 1,2,8,9 and is missing 3 .. 7), the error
messages will now give a full list of missing values.
NF-314-8114-002 Named numbers included in -gnatwu check
The warning option -gnatwu (check unreferenced entities)
now includes named numbers, so unreferenced named numbers
will now also cause warnings to be generated.
NF-314-8114-016 Better msg placement for with'ed unit not
found
In some cases, the error message for a WITH that directly
or indirectly lead to a file not found could be placed on a
location other than the WITH statement. It is now always
placed in the most convenient place.
NF-314-8116-001 Support for wide char to string conversions
The library units System.Wch_Con and System.Wch_Cnv provide
a method for converting between wide characters and the
corresponding string representation, using any of the
implemented methods for encoding.
NF-314-8118-003 Backtrace decorators for automatic
backtraces
GNAT.Exception_Traces now includes a backtrace decoration
facility, allowing customization of the way the set of
addresses for a backtrace is output. A typical use of this
feature is to provide a function that returns the symbolic
information associated with each address, as computed by
GNAT.Traceback.Symbolic.
NF-314-8120-006 Improved dead code detection
The warning circuitry for unreachable code has been
improved. Now an IF or CASE statement, all of whose
statement sequence end with some transfer of control is
recognized, and code after such a statement is flagged as
dead code with an appropriate warning.
NF-314-8127-007 Improved parser error messages
Some improvements in parser error messages have been made.
If "|" is used in an expression in an inappropriate manner,
the parser suggests that "or" may have been intended. If a
component is declared in the visible part of a protected
object, the diagnostic reminds that such components can
only be in the private part.
NF-314-8203-008 Default thread library is now LinuxThreads
Under the GNU/Linux operating system, the default tasking
run time is now based on the native LinuxThreads library.
The alternate FSU threads implementation is still available
as an alternative (see file README.TASKING for more
details). This change applies to all versions of GNU
Linux, including Redhat Linux.
NF-314-8205-001 New package Ada.Characters.Wide_Latin_1
This package provides definitions analogous to those in the
RM defined package Ada.Characters.Latin_1 except that the
type of the constants is Wide_Character instead of
Character. The provision of this package is in accordance
with RM (A.3(27)). Note: this package has been available
for some time, but was not properly documented, so from a
formal point of view was not available to application
programs, but now it is a first class citizen which is
fully documented.
NF-314-8213-003 More flexible placing of address clause
Previously when an address clause and Import pragma were
given for a subprogram, the pragma was required to be given
first. There is now no restriction on the ordering.
NF-314-8214-004 Style violations are now warnings not
errors
Style errors resulting from the use of a pragma Style_Check
or the -gnaty flag are now treated as warnings rather than
errors, which means that an object file can be created if
there are no other errors, and that also the compiler will
find semantic problems even if there are syntactic style
errors. If the previous behavior of treating these as
errors is desired, the -gnatwe flag can be used.
NF-314-8218-005 New Elaboration_Checks pragma
A new configuration pragma Elaboration_Checks can be used
to select the RM dynamic model of elaboration or the GNAT
default static model. This may be used in gnat.adc for
partition wide application, or within sources for unit by
unit control. See also feature NF-314-7530-009.
NF-314-8218-009 More efficient memory allocation
The GNAT run-time file a-raise.c can now easily be
recompiled with lock suppression to improve the efficiency
of memory allocation and deallocation if certain conditions
are met. See the comment on NO_LOCK in a-raise.c itself
for details.
NF-314-8220-005 Generic sort packages in GNAT now Pure
The units GNAT.Heap_Sort_G (g-hesorg.ads),
GNAT.Bubble_Sort_G (g-busorg.ads) are now Pure instead of
Preelaborate, allowing them to be with'ed and instantiated
by Pure clients.
NF-314-8220-006 Automatic float control for Float
Input-Output
Floating-point conversion in Text_IO no longer relies on
the floating-point processor being correctly set. This
means that the need for explicit calls to GNAT.Float_Reset
is limited to programs which explicitly use
Long_Long_Float. This feature is especially helpful on NT,
where system services of all kinds seem to reset the
floating-processor into low precision mode.
NF-314-8225-001 Project file capability for gnatmake
The gnatmake utility is now project file aware, and can be
used with the new GNAT Project Files (see new documentation
section in the users guide). It now accepts the new
switches -Pproject, -vPx and -Xname=value.
NF-314-8226-007 Better handling of invalid enum opnds for
Image
The Image function for enumeration types yielded rubbish
strings for abnormal and invalid operands (e.g. created by
unchecked conversions). A validity check (subject to
control by the -gnatV switch) is now performed so that an
exception (Constraint_Error) is raised for an invalid
operand.
NF-314-8230-001 Style check option for ordered subprograms
The -gnatyo switch (ORDERED_SUBPROGRAMS in the VMS version)
activates a style check that subprogram bodies within a
given scope (e.g. a package body) must be in alphabetical
order.
NF-314-8302-004 Project file capability for gnatls
The gnatls utility is now project aware, and can be used
with the new GNAT Project Files (see new documentation
section in the users guide). It now accepts the new
switches -Pproject, -vPx and -Xname=value.
NF-314-8304-001 RPM packages are now provided for GNU/Linux
Under GNU/Linux, GNAT is now provided as either a
compressed tar file as before, or as RPM packages which
means that the installation is simplified on various
versions of GNU/Linux, including Redhat Linux, and Debian
GNU/Linux.
NF-314-8305-003 Better folding of attributes of objects
The Alignment, Size, First, Last, Length, and
Component_Size attributes applied to objects are now
treated as compile time constants if the value can be
determined by the front end.
NF-314-8317-003 Floating-point range checks now catch
NaN's.
In GNAT, Machine_Overflows is False for floating-point
types, which means that operations such as 0.0/0.0 can
generate NaN's. The RM does not require that NaN's be
caught by subsequent range checks, but it is certainly
convenient if this is the case, and GNAT has now been
modified so that NaN's will always fail any range check and
cause Constraint_Error to be raised.
NF-314-8322-016 Program units now distinguished by gnatxref
The cross-reference section of the ali file now
distinguishes between generic and non-generic units, and
between functions, packages and procedures. The gnatxref
utility has been enhanced to take advantage of this new
information and now distinguishes these different kinds of
units in identification of entities.
NF-314-8323-004 Additional documentation on elaboration
issues.
A new section has been added to the users guide, entitled
"Additional Elaboration Order Considerations", which
discusses the issue of elaboration ordering requirements
that are not dictated by the language, but rather arise out
of extra-lingual logic requirements of the program.
NF-314-8328-012 Better handling of max size of variant
record
If a discriminant range is wider than it needs to be (e.g.
we have a Natural discriminant, which is used as the upper
bound of an array whose maximum bound is 10), then GNAT now
uses the maximum array bound in computing the maximum size
of the record, at least in most simple cases. In any case
it is a good idea to use a discriminant range that reflects
the range of actual valid values.
NF-314-8330-008 End positions of constructs now in ali file
The cross-reference information in the ALI file now
includes all labels on END lines, and also marks the end of
specs and bodies of tasks, subprograms, packages, protected
types, blocks, loops, entries and accept bodies. This
information is provided in the output from gnatxref.
NF-314-8407-012 Objects and types distinguished by gnatxref
The cross-reference output output by gnatxref distinguishes
type and object entities (for example an entity is labeled
as an "integer type" or "integer object", rather than
simply being identified as "Type: integer" in both cases).
NF-314-8409-001 Tree output can be forced with -gnatQ
-gnatt
It is now possible to force tree output using a combination
of the -gnatQ and -gnatt switches (it may also be
appropriate to use -gnatq in this context). This allows
the use of ASIS on some illegal programs, though if the
error is severe enough to cause a malformed tree, ASIS may
blow up when presented such a tree.
NF-314-8411-002 Boolean types now distinguished by gnatxref
The cross-reference section of the ali file now
distinguishes between boolean types and other enumeration
types, and the gnatxref utility has been enhanced to take
advantage of this new information and now distinguishes
these types in the entity identification information.
NF-314-8412-006 New option for gnatlink for object list
file
The switch -f for gnatlink forces the generation of a
separate file containing a list of objects for the linker,
even if the threshhold for command line length is not
exceeded. This is useful to get around some cases of
unexpectedly exceeding this limit (e.g. due to system
environment issues that reduce the limit). The switch can
only be used on targets for which linker object list files
are implemented. In addition the limit for generation of
such files on Tru Unix (Alpha) has been reduced to 10_000,
since on some systems the previous limit (30_000) was too
high.
NF-314-8412-010 New file routines in GNAT.OS_Lib
A new routine has been added into GNAT.OS_Lib to rename a
file. All routines dealing with files now have two
implementations: one using the String type and one using
an address to specify the filename. This is a general
clean up to fix inconsistencies.
NF-314-8413-005 Stream size now taken from first subtype
Previously GNAT was using the size of the base type to
determine the number of storage units for use by stream
routines for elementary types. This is now changed to meet
the new recommendations of AI-195, which suggest using the
size of the first subtype. GNAT now uses the size of the
first subtype for this determination.
NF-314-8420-006 New tasking run time under Solaris
Under Solaris Sparc, GNAT now comes with a new tasking run
time based on posix threads (rts-pthread). This run time
has the advantage of being mostly shared across all POSIX
compliant thread implementations, and also provides under
Solaris 8 the semantics of PTHREAD_PRIO_PROTECT and
PTHREAD_PRIO_INHERIT. The predefined Ceiling_Locking
policy for pragma Locking_Policy is used to specify
PTHREAD_PRIO_PROTECT, and a new implementation defined
policy, Inheritance_Locking, can be used to specify the use
of PTHREAD_PRIO_INHERIT.
NF-314-8430-004 Enhanced style checking for references
For cases in which there is a separate body entity
(packages, subprograms, entries, tasks, protected types,
accept statements, subprogram formals), the switch -gnatyr
now checks the casing of the body entity to make sure that
it is the same as that of the spec entity.
NF-314-8509-011 New package GNAT.Expect
This package provides a set of subprograms similar to what
is available with the standard Tcl Expect tool, allowing
you to easily spawn and communicate with an external
process. You can use this package to send commands or
inputs to the process, and compare the output with some
expected regular expression.
NF-314-8514-003 Improved error message for access
discriminants
When declaring a self-referential structure as a limited
record that contains a discriminated component that points
to the enclosing record, a common mistake is to define the
type of the component as having a discriminant with a
general access type, rather than as a proper access
discriminant. This results in an accessibility violation
(RM 3.10.2 (21)). The new message indicates that the error
is in the discriminant declaration itself.
NF-314-8522-001 Solaris programs do not depend on
libthread.so
On the Solaris operating system, for programs that do not
use tasking, the generated executables no longer depend on
libthread.so so that a link can be successfuly completed
without requiring this library to be present.
NF-314-8526-003 Record'Size evaluated at compile time
In the case where the size of a record type is specified
using a size representation attribute clause, the front end
now folds the attribute reference at compile time. The
result is still not a static expression, but the quality of
code is improved, and in addition, representation clauses
(such as component clauses) that require values and types
to be statically known at compile time are permitted in
additional cases as a result of this change.
^ permalink raw reply [relevance 1%]
* Re: Use of entries using Ravenscar
@ 2001-12-20 13:52 2% ` Jimmy Dubén
0 siblings, 0 replies; 133+ results
From: Jimmy Dubén @ 2001-12-20 13:52 UTC (permalink / raw)
> You couldn't provide an actual code example? I've been playing with
> the Ravenscar profile for a few months now and have never had any
> problem with it.
Okidoki.. here goes.
I have three different files below (sorry, I could not send them
along...).
One procedure that uses the PO, and then a package with the PO that
has the entry.
Originally the code was intended to catch a signal but that did not
work with ravenscar either. Strange since I think it is statically
attached.
Pragma(Ravenscar) not shown here (used in gnat.adc next to Makefile)
<<<<<<<<<<<<CODE>>>>>>>>>>>>
>>>>>>>>test_entry.adb
with Ada.Real_Time, Ada.Text_IO, Signal_Handler_Test;
use Ada.Real_Time, Ada.Text_IO, Signal_Handler_Test;
procedure Test_Entry is
Period : constant Duration := 5.0;
Next_Time : Time;
begin
loop
Next_Time := Clock + To_Time_Span (Period);
delay until Next_Time;
Protected_Signal_Handler_Test.Read;
end loop;
end Test_Entry;
>>>>>>>>>signal_handler_test.ads
with
Ada.Interrupts,
Ada.Text_IO,
Ada.Interrupts.Names;
use
Ada.Interrupts,
Ada.Text_IO,
Ada.Interrupts.Names;
package Signal_Handler_Test is
protected Protected_Signal_Handler_Test is
--*F
--* Read entry ...
--*E
entry Read;
--*F
--* Report that signal USR1 has occured
--*E
procedure Something_Arrived;
-- Attach this certain procedure to the correct signal
-- NOT ANY MORE
--pragma Attach_Handler(Something_Arrived, SIGUSR1);
private
-- Whether or not there is anything to "read"
Exists_Something : Boolean := False;
No_Of_Something : Integer := 0;
end Protected_Signal_Handler_Test;
end Signal_Handler_Test;
>>>>>>>>>signal_handler_test.adb
package body Signal_Handler_Test is
protected body Protected_Signal_Handler_Test is
entry Read when Exists_Something is
begin
-- Decrement message counter
No_Of_Something := No_Of_Something - 1;
Put_Line("Read: Something is = " & No_Of_Something'img);
-- (Possibly) allow others to use the entry again
Exists_Something := No_Of_Something > 0;
end Read;
procedure Something_Arrived is
begin
Ada.Text_IO.Put_Line("Something_Arrived: A message has
arrived.");
-- Increment something counter
No_Of_Something := No_Of_Something + 1;
Put_Line("Something_Arrived: Something is = " &
No_Of_Something'img);
-- A something is available now
Exists_Something := True;
end Something_Arrived;
end Protected_Signal_Handler_Test;
end Signal_Handler_Test;
>>>>>>>>>>>>>NO MORE CODE<<<<<<<<<<<<<<
In the system I'm working with we, among other things, want to catch a
signal from a CAN-driver to be able to do a non-blocking read. (We
can't find good drivers to our CAN-module that is working with Linux
2.4.15)
^ permalink raw reply [relevance 2%]
* Re: no Ada.Interrupts?
2001-11-02 14:10 3% no Ada.Interrupts? Zebylon
2001-11-02 15:12 2% ` Wes Groleau
@ 2001-11-02 16:43 2% ` Jacob Sparre Andersen
1 sibling, 0 replies; 133+ results
From: Jacob Sparre Andersen @ 2001-11-02 16:43 UTC (permalink / raw)
Zebylon:
> When I imported some files made in GNAT to Rational Apex Ada I encountered
> some problems.
> The compiler gives me this error status after compilation:
>
> *** ada.interrupts.1.ada is not in view imported by dh_ethernet.1.ada
> >>> Line 56: Interrupt_Id : in Ada.Interrupts.Interrupt_Id;
> *** Ada is undefined
> ++* dh_ethernet.1.ada has failed to install in
> H:/Workarea/Labbar/ApexLabs/EhDriver.ss/Driver1.wrk
> ++* 1 unit could not be installed
> --- 34 units were examined
> ::: [end of rada]
> ::: [rada job has finished]
>
> what is the meaning of this?
It could be that Rational Apex Ada does not implement the
system programming annex. Have you checked the
documentation?
Jacob
--
"an OS that is almost, but not quite, entirely unlike
Windows"
^ permalink raw reply [relevance 2%]
* Re: no Ada.Interrupts?
2001-11-02 14:10 3% no Ada.Interrupts? Zebylon
@ 2001-11-02 15:12 2% ` Wes Groleau
2001-11-02 16:43 2% ` Jacob Sparre Andersen
1 sibling, 0 replies; 133+ results
From: Wes Groleau @ 2001-11-02 15:12 UTC (permalink / raw)
Zebylon wrote:
> When I imported some files made in GNAT to Rational Apex Ada I encountered
> some problems.
> The compiler gives me this error status after compilation:
>
> *** ada.interrupts.1.ada is not in view imported by dh_ethernet.1.ada
> >>> Line 56: Interrupt_Id : in Ada.Interrupts.Interrupt_Id;
> *** Ada is undefined
> ++* dh_ethernet.1.ada has failed to install in
> H:/Workarea/Labbar/ApexLabs/EhDriver.ss/Driver1.wrk
> ++* 1 unit could not be installed
> --- 34 units were examined
> ::: [end of rada]
> ::: [rada job has finished]
Pull down menu Control -> Show -> Imports.
Look under "closure imports"
select "systems_programming.ss"
click "add import"
click "OK"
if "systems_programming.ss" is not there, select "lrm.ss"
click "add import"
click on the item in the "new imports" box
click "remove"
in the box next to the "Add:" button, change
"lrm.ss" to "systems_programming.ss"
after either of these, it will compile OK.
--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau
^ permalink raw reply [relevance 2%]
* no Ada.Interrupts?
@ 2001-11-02 14:10 3% Zebylon
2001-11-02 15:12 2% ` Wes Groleau
2001-11-02 16:43 2% ` Jacob Sparre Andersen
0 siblings, 2 replies; 133+ results
From: Zebylon @ 2001-11-02 14:10 UTC (permalink / raw)
When I imported some files made in GNAT to Rational Apex Ada I encountered
some problems.
The compiler gives me this error status after compilation:
*** ada.interrupts.1.ada is not in view imported by dh_ethernet.1.ada
>>> Line 56: Interrupt_Id : in Ada.Interrupts.Interrupt_Id;
*** Ada is undefined
++* dh_ethernet.1.ada has failed to install in
H:/Workarea/Labbar/ApexLabs/EhDriver.ss/Driver1.wrk
++* 1 unit could not be installed
--- 34 units were examined
::: [end of rada]
::: [rada job has finished]
what is the meaning of this?
^ permalink raw reply [relevance 3%]
* Re: Handling signals in ADA
2001-03-16 21:06 1% ` Florian Weimer
@ 2001-03-17 1:00 0% ` David C. Hoos, Sr.
0 siblings, 0 replies; 133+ results
From: David C. Hoos, Sr. @ 2001-03-17 1:00 UTC (permalink / raw)
Remember that in the context of the original inquirer's question,
he was using an OS with Unix-style signals, so he couldn't have been
talking about a DOS implementation where Unix-style signals
do not exist.
I have yet to see an Ada95 compiler targeted to a platform with
Unix-style signals that does not support the correspondence between
signals and interrupts. Perhaps there is one or more, but I've not
seen them. Do you know of any?
"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87u24t4e5y.fsf@deneb.enyo.de...
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>
> > > The standard Ada library does not support signals. Typical Ada
> > > programs use other communication mechanisms, and a verbatim
> > > translation is not possible. If you need signal handling because it's
> > > required by your environment, have a look at POSIX.5.
> >
> > This answer is just plain wrong. The following program demonstrates
> > the use of signals in Ada, using only language-defined units.
>
> There is no requirement in the standard that Ada interrupts are
> mapped to C signals. I believe that there are quite a number of
> implementations where no such correspondence exists (it would make
> sense for a DOS implementation, for example).
^ permalink raw reply [relevance 0%]
* Re: Handling signals in ADA
2001-03-16 1:27 2% ` David C. Hoos, Sr.
2001-03-16 1:48 1% ` Jeffrey Carter
@ 2001-03-16 21:06 1% ` Florian Weimer
2001-03-17 1:00 0% ` David C. Hoos, Sr.
1 sibling, 1 reply; 133+ results
From: Florian Weimer @ 2001-03-16 21:06 UTC (permalink / raw)
"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
> > The standard Ada library does not support signals. Typical Ada
> > programs use other communication mechanisms, and a verbatim
> > translation is not possible. If you need signal handling because it's
> > required by your environment, have a look at POSIX.5.
>
> This answer is just plain wrong. The following program demonstrates
> the use of signals in Ada, using only language-defined units.
There is no requirement in the standard that Ada interrupts are
mapped to C signals. I believe that there are quite a number of
implementations where no such correspondence exists (it would make
sense for a DOS implementation, for example).
^ permalink raw reply [relevance 1%]
* Re: Handling signals in ADA
2001-03-15 18:48 1% ` David Starner
@ 2001-03-16 17:17 2% ` Robert A Duff
0 siblings, 0 replies; 133+ results
From: Robert A Duff @ 2001-03-16 17:17 UTC (permalink / raw)
dvdeug@x8b4e53cd.dhcp.okstate.edu (David Starner) writes:
> Someone else posted a literal translation*. The question is, what do you
> want to do? For most Ada programming, signals aren't the right tool for
> the job. Tasks and exceptions can handle many signal uses; others may
> take a little more thought to rewrite, but it's usually better to
> program in the language you're programming in, than force a design for C
> into Ada. (As a side note, SIGUSR1 is not always safe to use in an Ada
> program - GNAT in the standard (ACT) configuration uses it for
> threading.)
I don't think using signals constitutes "a design for C". Signals are
an operating system feature. Many operating systems have similar
features ("per-process interrupts" or "asynchronous system traps" or
whatever). That includes operating systems that are not so (evilly)
C-centric as Unix.
Anyway, if you want interface to signals, use a protected object with a
pragma Attach_Handler, and the various related features. I have done
this, for example, to catch control-C interrupts -- portably to both
Unix and Windows.
> * To properly use SIGUSR1, you could write a one line C function
> returning SIGUSR1 and import it, or write a compile time program that
> finds the value of SIGUSR1 and includes it. If you're using GNAT, you
> should check out Ada.Interrupts.Names and System.OS_Interface, which
> also tell you all the reserved signals.
You should check out Ada.Interrupts.Names even if you're *not* using
GNAT -- this package is standard (although its contents are obviously
system dependent).
- Bob
^ permalink raw reply [relevance 2%]
* Re: Handling signals in ADA
2001-03-16 1:27 2% ` David C. Hoos, Sr.
@ 2001-03-16 3:06 2% ` (null)
1 sibling, 0 replies; 133+ results
From: (null) @ 2001-03-16 3:06 UTC (permalink / raw)
In article <87y9u6k7s6.fsf@deneb.enyo.de>,
Florian Weimer <fw@deneb.enyo.de> wrote:
>Tomas Hlavaty <hlavaty@labe.felk.cvut.cz> writes:
>
>> Hi, could you help me with translating following C code to ADA?
>
>
>The standard Ada library does not support signals. Typical Ada
>programs use other communication mechanisms,
Yes, but typical Unix programs use signals.
Florist will have what you want. You can find those at
ftp://ftp.cs.fsu.edu/pub/PART
Alternatively if you're using the gnat compiler you can the facilities
in Ada.Interrupts. Here's an example-
-- cut here --
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Interrupts.names;
with Interrupt_Handler; use Interrupt_Handler;
pragma Unreserve_All_Interrupts;
procedure When_Is_It_Over is
Fat_Lady: Singer(Ada.Interrupts.Names.SIGINT);
begin
loop
New_Line;
delay 1.0;
Put("It ain't over...");
exit when Fat_Lady.Sings;
end loop;
Put_Line(" until the fat lady sings.");
end When_Is_It_over;
-- cut here --
with Ada.Interrupts;
package Interrupt_Handler is
protected type Singer (Id: Ada.Interrupts.Interrupt_Id) is
function Sings return Boolean;
procedure Handler;
pragma Attach_Handler(Handler, Id);
private
Done: Boolean := False;
end Singer;
end;
-- cut here --
package body Interrupt_Handler is
protected body Singer is
function Sings return Boolean is
begin
return Done;
end Sings;
procedure handler is
begin
done := True;
end handler;
end Singer;
end;
--
=======================================================================
Life is short. | Craig Spannring
Bike hard, ski fast. | cts@internetcds.com
--------------------------------+------------------------------------
^ permalink raw reply [relevance 2%]
* Re: Handling signals in ADA
2001-03-16 1:27 2% ` David C. Hoos, Sr.
@ 2001-03-16 1:48 1% ` Jeffrey Carter
2001-03-16 21:06 1% ` Florian Weimer
1 sibling, 0 replies; 133+ results
From: Jeffrey Carter @ 2001-03-16 1:48 UTC (permalink / raw)
"David C. Hoos, Sr." wrote:
>
> pragma Attach_Handler
> (Handle_SIGINT, Ada.Interrupts.Names.SIGINT);
> pragma Attach_Handler
> (Handle_SIGUSR1, Ada.Interrupts.Names.SIGUSR1);
> pragma Attach_Handler
> (Handle_SIGUSR2, Ada.Interrupts.Names.SIGUSR2);
Since the constants declared in Ada.Interrupts.Names are
implementation-defined, the most you can say is that this works on
certain compilers & OS's, which you should list.
--
Jeff Carter
"Go and boil your bottoms."
Monty Python & the Holy Grail
^ permalink raw reply [relevance 1%]
* Re: Handling signals in ADA
@ 2001-03-16 1:27 2% ` David C. Hoos, Sr.
2001-03-16 1:48 1% ` Jeffrey Carter
2001-03-16 21:06 1% ` Florian Weimer
2001-03-16 3:06 2% ` (null)
1 sibling, 2 replies; 133+ results
From: David C. Hoos, Sr. @ 2001-03-16 1:27 UTC (permalink / raw)
"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87y9u6k7s6.fsf@deneb.enyo.de...
> Tomas Hlavaty <hlavaty@labe.felk.cvut.cz> writes:
>
> > Hi, could you help me with translating following C code to ADA?
>
> The programming language is called 'Ada'.
>
> > -- How to translate it to ADA?
>
> The standard Ada library does not support signals. Typical Ada
> programs use other communication mechanisms, and a verbatim
> translation is not possible. If you need signal handling because it's
> required by your environment, have a look at POSIX.5.
This answer is just plain wrong. The following program demonstrates
the use of signals in Ada, using only language-defined units.
Now. to be sure, because Ada restricts interrupt handlers to being
parameterless protected procedures, it is not possible to
pass parameter like what can be done under UNIX with the
standard C runtime, for example.
But the "standard Ada library" _DOES_ support signals.
-- begin source code
package body Signal_Handlers
is
SIG_INT_Received : Boolean := False;
function SIGINT_RECEIVED return BOOLEAN
is
begin
return SIG_INT_Received;
end SIGINT_Received;
protected body Signals
is
procedure Handle_SIGINT
is
begin
Ada.Text_IO.Put_Line ("SIGINT received..; Terminating.");
SIG_INT_Received := True;
end Handle_SIGINT;
procedure Handle_SIGUSR1
is
begin
Ada.Text_IO.Put_Line ("SIGUSR1 received and handled.");
end Handle_SIGUSR1;
procedure Handle_SIGUSR2
is
begin
Ada.Text_IO.Put_Line ("SIGUSR2 received and handled.");
end Handle_SIGUSR2;
end Signals;
end Signal_Handlers;
with Ada.Interrupts.Names;
with Ada.Text_IO;
package Signal_Handlers
is
pragma Unreserve_All_Interrupts;
function SIGINT_Received return Boolean;
protected Signals is
procedure Handle_SIGINT;
procedure Handle_SIGUSR1;
procedure Handle_SIGUSR2;
private
pragma Attach_Handler
(Handle_SIGINT, Ada.Interrupts.Names.SIGINT);
pragma Attach_Handler
(Handle_SIGUSR1, Ada.Interrupts.Names.SIGUSR1);
pragma Attach_Handler
(Handle_SIGUSR2, Ada.Interrupts.Names.SIGUSR2);
end Signals;
end Signal_Handlers;
with Ada.Text_IO;
with Signal_Handlers;
procedure Test_Signal_Handler
is
begin
loop
exit when Signal_Handlers.SIGINT_Received;
Ada.Text_IO.Put_Line ("I'm alive...");
delay 1.0;
end loop;
end Test_Signal_Handler;
.
^ permalink raw reply [relevance 2%]
* Re: Handling signals in ADA
@ 2001-03-15 18:48 1% ` David Starner
2001-03-16 17:17 2% ` Robert A Duff
1 sibling, 1 reply; 133+ results
From: David Starner @ 2001-03-15 18:48 UTC (permalink / raw)
On Tue, 13 Mar 2001 12:09:03 +0100, Tomas Hlavaty
<hlavaty@labe.felk.cvut.cz> wrote:
>Hi, could you help me with translating following C code to ADA?
Someone else posted a literal translation*. The question is, what do you
want to do? For most Ada programming, signals aren't the right tool for
the job. Tasks and exceptions can handle many signal uses; others may
take a little more thought to rewrite, but it's usually better to
program in the language you're programming in, than force a design for C
into Ada. (As a side note, SIGUSR1 is not always safe to use in an Ada
program - GNAT in the standard (ACT) configuration uses it for
threading.)
However, sometimes the external enviroment hands a signal you have to
handle. In which case, my solution would be to write a little C
encapsulating all the signal details and call it. You could also check
out the Ada packages listed below, or look up Florist, a free Ada Posix
binding.
* To properly use SIGUSR1, you could write a one line C function
returning SIGUSR1 and import it, or write a compile time program that
finds the value of SIGUSR1 and includes it. If you're using GNAT, you
should check out Ada.Interrupts.Names and System.OS_Interface, which
also tell you all the reserved signals.
--
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and
laughs at me. In fact, I'd be rather honored." - Joseph_Greg
^ permalink raw reply [relevance 1%]
* Re: Interrupts service
2001-01-05 12:28 2% Interrupts service Szygula
@ 2001-01-05 13:20 0% ` Marc A. Criley
0 siblings, 0 replies; 133+ results
From: Marc A. Criley @ 2001-01-05 13:20 UTC (permalink / raw)
What is this program supposed to do? How does what it is doing differ
from what you expect? What compiler are you using? On what platform?
It is much easier to help if you provide that kind of information when
you ask a question like this.
Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com
Szygula wrote:
>
> WHAT'S WRONG IN THIS PROGRAM ???
>
> with Text_Io, Ada.Calendar, Ada.Integer_Text_Io;
> use Text_Io, Ada.Calendar, Ada.Integer_Text_Io;
> with Ada.Interrupts;
> use Ada.Interrupts;
>
> with Ada.Interrupts.Names;
> use Ada.Interrupts.Names;
> with System; use System;
> with system.storage_elements; use system.storage_elements;
>
> procedure program is
>
> type Parameterless_Handler is access protected procedure;
>
> protected type Sygnal(p:Interrupt_ID)is
>
> procedure Steruj;
> pragma Interrupt_handler(Steruj);
> pragma Attach_Handler(Steruj,p);
> end Sygnal;
>
> protected body sygnal is
>
> procedure Steruj is
> begin
> Put("przerwanie");
> end steruj;
>
> end sygnal;
>
> begin
> null;
>
> end program;
>
> I NEED INFORMATION OF INTERRUPTS IN ADA95.
> thanks.
>
> szygula@szygula.prv.pl
> POLAND
^ permalink raw reply [relevance 0%]
* Interrupts service
@ 2001-01-05 12:28 2% Szygula
2001-01-05 13:20 0% ` Marc A. Criley
0 siblings, 1 reply; 133+ results
From: Szygula @ 2001-01-05 12:28 UTC (permalink / raw)
WHAT'S WRONG IN THIS PROGRAM ???
with Text_Io, Ada.Calendar, Ada.Integer_Text_Io;
use Text_Io, Ada.Calendar, Ada.Integer_Text_Io;
with Ada.Interrupts;
use Ada.Interrupts;
with Ada.Interrupts.Names;
use Ada.Interrupts.Names;
with System; use System;
with system.storage_elements; use system.storage_elements;
procedure program is
type Parameterless_Handler is access protected procedure;
protected type Sygnal(p:Interrupt_ID)is
procedure Steruj;
pragma Interrupt_handler(Steruj);
pragma Attach_Handler(Steruj,p);
end Sygnal;
protected body sygnal is
procedure Steruj is
begin
Put("przerwanie");
end steruj;
end sygnal;
begin
null;
end program;
I NEED INFORMATION OF INTERRUPTS IN ADA95.
thanks.
szygula@szygula.prv.pl
POLAND
^ permalink raw reply [relevance 2%]
* Re: How to lock keys.
@ 2000-12-15 23:56 2% ` Alexander Antonenko
0 siblings, 0 replies; 133+ results
From: Alexander Antonenko @ 2000-12-15 23:56 UTC (permalink / raw)
>>>>> "F" == Freelancer writes:
F> I'm using ObjectAda and programming console programs in win98. I was
F> wondering if someone could tell me how to lock out any keys that I don't
F> want in my program.
F> For example : I would like to lock out CTRL+C so that it doesn't
F> terminate the program.
You can try something like this:
System.Interrupts.Block_Interrupt(
System.Interrupts.Interrupt_Id(Ada.Interrupts.Names.SIGINT));
I don't know will this work in windows and with compilers other than
GNAT. In any case see packages Ada.Interrupts & System.Interrupts.
F> Thanks for your help! :)
--
Alexander Antonenko
mailto:alexa@i.com.ua
mailto:aga@mix.meow.kiev.ua
I suppose you think I think I know it all
-- Ozzy
^ permalink raw reply [relevance 2%]
* ANNOUNCEMENT - GNAT 3.13p availability
@ 2000-08-08 0:00 1% Bernard Banner
0 siblings, 0 replies; 133+ results
From: Bernard Banner @ 2000-08-08 0:00 UTC (permalink / raw)
To: comp.lang.ada
Announcing GNAT version 3.13p
Ada Core Technologies announces the availability of version
3.13p of GNAT. This version of GNAT is derived from GNAT
Professional version 3.13a1, and like previous public
versions of GNAT is made freely available with the specific
intention of supporting student use and academic research
use of the Ada 95 language.
The public version of 3.13p is available for the following
targets in binary form:
Sparc Solaris
x86 Linux
Windows 95/98/NT/2000
These versions may be obtained from the usual download
sites for public GNAT releases. Check cs.nyu.edu ftp
directories pub/gnat for details.
The following are new features in version 3.13p
The package GNAT.Regpat has been enhanced to provide an almost full support
for Perl-like regular expressions, including several new constructs.
On unix systems, it is now possible to install GNAT at any location
without setting any environment variable.
A warning is issued for the use of Import/Export_Valued_Procedure if
the default Ada convention is used, since it makes no sense to use
convention Ada for such a procedure, the only point of the feature
is to interface with foreign convention procedures. This prevents
hard to find errors resulting in incorrect behavior at run time.
A new style switch -gnatyn (STANDARD_CASING in the VMS version) checks
that all entities from package Standard are cased in a manner consistent
with the way this package is presented in the Ada Reference Manual.
A simple way of interfacing with C++ is now documented in the user's
guide and has been added to the examples directory.
A new gnatmake switch (-s) causes recompilation of a file if its
compilation options (e.g. optimization level) have changed.
A new gnatdll switch (-k) removed Stdcall @nn suffix from the
import library's exported names.
A new GNAT library package (GNAT.Float_Control in file g-flocon.ads)
provides an interface for resetting the floating-point processor into
the required mode.
A new GNAT library package (GNAT.Exceptions in file g-except.ads)
provides a mechanism for raising predefined exceptions with messages
from Pure units.
A new pragma, Suppress_Debug_Info, provides for suppressing debugging
information for selected entities.
Additional optimization circuits in aggregate handling result in many
more aggregate assignments being handled in place, instead of generating
an extra temporary.
The GNAT Reference manual now contains summary documentation of the GNAT
library routines. The primary documentation is still in the specs of the
relevant packages, but the document summarizes what facilities are
available.
The package Ada.Strings.Unbounded.Text_IO is now documented in the
GNAT reference manual.
A new package Ada.Strings.Wide_Unbounded.Wide_Text_IO has been added
to provide Wide_Text_IO facilities for Unbounded_Wide_String.
The -mlongcall switch as well as the __shortcall__ attribute is now provided
on all powerpc ports. See the GCC documentation for more details.
The Linker_Options pragma can now take multiple options, which are
guaranteed to apear in the sequence given in the pragma.
The gnatbind -E option (stack tracebacks) is now supported under
Windows NT.
New switches -gnatwa and -gnatwA are available to turn all
optional warnings on/off respectively.
The syntax for the -gnatw warning switch now allows a string of
options after the w. For example -gnatwaLe turns on all optional
warnings except elaboration warnings and considers warnings to be
errors.
The generated code for many slice assignments has been improved, resulting
in considerably improved execution time on most targets.
The generated code for multi-dimensional arrays has been improved,
significantly improving performance in many situations.
The compiler now does a much more effective job of suppressing checks
in array references in loops where the arrays involved are parameters
that are unconstrained array types, or pointers to unconstrained arrays.
On VxWorks cross-compilers, a new package called Interfaces.VxWorks provides
provides a limited binding to the VxWorks API. In particular, it interfaces
with the VxWorks hardware interrupt facilities.
The package GNAT.Regexp no longer has any size limitation, and can handle
complex regular expressions.
A new warning switch -gnatwc turns on warnings for relational and
membership operators appearing in statements (e.g. if statements)
whose results are known at compile time to be always true or
always false.
A new pragma Style_Checks allows selection of style checks in a manner
similar to the existing compiler switch, and also allows the style
checks to be temporarily turned off and then turned back on again.
The binary releases now contain the necessary headers to compile the
C files in the runtime without having to do a full build of GNAT from
sources.
Makefile.adalib now also recompiles the C part of the GNAT run time,
providing the ability to rebuild completely the GNAT libraries with the
binary distribution.
Makefile.adalib is now available for cross compilers, as well as the
native versions of GNAT
The -gnatwu switch now also provides warnings about possible access to
uninitialized out parameters.
The -gnatyk switch (check identifier casing) error messages now contain
a source location reference to the definition of the relevant identifier.
It is now permissible to specify the non-default Bit_Order for record
subtypes. Component clauses for such types must either specify an
integral number of bytes, or the component must lie entirely within
one byte. Note that, in accordance with the RM, no reordering of bytes
is done, the only effect is to renumber bits. This feature is therefore
only of limited use in dealing with big/little-endian interfacing.
Default_Bit_Order is now static. This is strictly a violation of the RM
requirement that it be non-static, but everyone agrees this was a mistake,
and an AI is expected to "fix" this mistake. Other Ada 95 compilers are
already consistent with this modified interpreation of the RM.
Florist has been ported to Solaris 7 and HP-UX 11.00
GNAT now fully supports HP-UX 11.00, including a dual tasking run time
that provides access to the DCE run time for compatibility with HP-UX 10.20,
and to the POSIX pthread run time.
Interrupt handling on HP-UX has been rewritten to provide a more powerful
and less restrictive signal handling. In particular, the signals SIGIO and
SIGPIPE can now be handled via Ada.Interrupts.
The listing generated by the -gnatR switch now includes alignment values
for array and record types.
The NT version of GNAT now generates object files that are fully compatible
with the standard Microsoft linker, so this linker can be used instead of
the GNU ld program to build NT executables.
The default stack size on NT for tasking program has been reduced to 8Mb
(instead of 32Mb). This increase the default maximum number of tasks
from approximately 60 to a value around 250.
The gnathtml tool can now read the list of files to convert from a file,
eliminating the command line length problem on some systems.
The parent type of derived types is now recorded in the cross-reference
section of the ali files. The new ali format is backward compatible with
the previous one.
The gnatfind and gnatxref tools have been extended to display the parent
type of derived types. Furthermore gnatfind is now able to display the full
type derivation informations for a specific type.
Shared libraries are now provided as an option (via the -shared gnatbind
switch) on four additional targets: Solaris x86, Solaris sparc, Linux and
SCO UnixWare.
New restrictions No_Implicit_Conditionals and No_Implicit_Loops have
been added for greater control over generated code. This is particularly
useful in a safety-critical/certification environment using GNORT (GNAT
with no run time)
The performance of the elementary trigononmetric functions has been
substantially improved.
A new section has been added to the GNAT Reference Manual providing
a complete description of the set of representation pragmas and
pragmas that are accepted by GNAT, and their effect.
The implementation of the ASIS Data Decomposition Annex is now complete,
with all queries fully supported.
More static checking is now done for pragma Restrictions (No_Recursion),
and most common cases are now detected and flagged as illegalities.
A new package GNAT.Calendar is provided. It deals with Hour, Minute,
Seconds, Day_Of_Week, Day_In_Year, Week_In_Year. There is also two
functions to do conversions between Duration and C timeval struct.
A new package GNAT.Calendar.Time_IO is provided. This package implements
formatted output of Ada.Calendar.Time. The format string uses a format
similar to the one used by the date UNIX command.
The gnatdll tool now accepts the -I switch to search source and
object files in specified directories.
The optimization of checks has been significantly improved, and many
unnecessary checks, particularly in connection with type conversions and
the use of the pos operator, have been removed.
The traceback stored in the exception occurrence (using the gnatbind -E
switch) now gives accurate values in the case of a reraise.
The structure used to hold task data has been split to allow restricted
tasking implementations to use less storage for each task created.
Enumeration representation clauses for types derived from Boolean
are now fully supported.
Variable shift instructions are now generated for multiplications or
divisions by powers of 2 (e.g. x * 2 ** y, where y is Natural).
External symbol names and debugging symbols are now more fully qualified.
This avoids some peculiar naming conflicts for example in the case where
there is a child package and nested package with the same name, and also
improves the behavior of gdb when fully qualified names are given.
An extended form of the Source_File_Name pragma permits handling the
unusual case where a subunit and child unit have identical qualified
names. This is unusual, but is allowed by the rules of the language,
although both versions cannot appear in a single partition.
The OpenVMS version of GNAT now fully supports the use of mixed-case
external names. This solves a number of compatibility problems in
this area, which could show up as unexpected duplicate names.
A new pragma External_Name_Casing is provided for controlling the
casing of external names. This is primarily for use in OpenVMS systems,
but is available in all implementations.
A new pragma Extensions_Allowed (ON | OFF) is provided for local control
of whether language extensions are allowed. This pragma may also be used
as a configuration pragma (e.g. in the gnat.adc file) to control the use
of extensions for a series of compilations.
The -gnatwu flag now separately checks specs to make sure that a with in
a spec is now actually used in the spec. If the with is used only in the
body, the warning suggests moving it to the body.
The renaming of a constant was implemented as the declaration of a local
variable whose initial value was the constant being renamed. This avoids
an indirection, but is inefficient if the constant being renamed is large.
This optimization is now restricted to objects that fit in registers.
^ permalink raw reply [relevance 1%]
* Re: Announcing GNAT version 3.13
@ 2000-03-15 0:00 1% ` Robert Dewar
0 siblings, 0 replies; 133+ results
From: Robert Dewar @ 2000-03-15 0:00 UTC (permalink / raw)
NEW FEATURES IN GNAT 3.13
GNAT version 3.13 includes the first release of GLIDE, the
new integrated development environment that builds on and
extends our previous tools work. GLIDE provides a fully
integrated editor and debugger environment, and supports
multiple graphical debuggers, including a new improved gdbtk
and a version of ddd adapted for use with GNAT.
The GLIDE editor (based on ada-mode for Emacs)
includes many new features. Among them are:
Gnatdist configuration files are automatically edited
in Ada-mode.
Support for big projects with hundreds of directories
by getting rid of the command line length limit on some
systems, as well as easier ways to enter a long list of
directories in the project file.
The cross-references to and within the standard runtime
are automatically handled.
Full contextual menus are provided with the right mouse
button.
Multiple exception files for automatic casing can now
be specified, for instance one system-wide, one
project-wide and a user-specific one.
The project file editor is displayed through tabbed
dialogs, with full contextual help on the fields.
Indentation is now easier to configure since the
ada-mode can explain which variable was used to
indent a specific line.
Under unix systems, it is now possible to install GNAT at
any location without setting any environment variable.
A warning is issued for the use of
Import/Export_Valued_Procedure if the default Ada convention
is used, since it makes no sense to use convention Ada for
such a procedure, the only point of the feature is to
interface with foreign convention procedures. This prevents
hard to find errors resulting in incorrect behavior at run
time.
A new style switch -gnatyn (STANDARD_CASING in the VMS
version) checks that all entities from package Standard are
cased in a manner consistent with the way this package is
presented in the Ada Reference Manual.
A simple way of interfacing with c++ is now documented in
the user's guide and has been added to the examples
directory.
A new gnatmake switch (-s) causes recompilation of a file if
its compilation options (e.g. optimization level) have
changed.
A new gnatdll switch (-k) removed Stdcall @nn suffix from
the import library's exported names.
A new GNAT library package (GNAT.Float_Control in file
g-flocon.ads) provides an interface for resetting the
floating-point processor into the required mode.
A new GNAT library package (GNAT.Exceptions in file
g-except.ads) provides a mechanism for raising predefined
exceptions with messages from Pure units.
A new pragma, Suppress_Debug_Info, provides for suppressing
debugging information for selected entities.
Additional optimization circuits in aggregate handling
result in many more aggregate assignments being handled in
place, instead of generating an extra temporary.
The GNAT Reference manual now contains summary documentation
of the GNAT library routines. The primary documentation is
still in the specs of the relevant packages, but the
document summarizes what facilities are available.
The package Ada.Strings.Unbounded.Text_IO is now documented
in the GNAT reference manual.
A new package Ada.Strings.Wide_Unbounded.Wide_Text_IO has
been added to provide Wide_Text_IO facilities for
Unbounded_Wide_String.
The -mlongcall switch as well as the __shortcall__ attribute
is now provided on all powerpc ports. See the GCC
documentation for more details.
The Linker_Options pragma can now take multiple options,
which are guaranteed to apear in the sequence given in the
pragma.
The gnatbind -E option (stack tracebacks) is now supported
under Windows ix86.
New switches -gnatwa and -gnatwA are available to turn all
optional warnings on/off respectively.
The syntax for the -gnatw warning switch now allows a string
of options after the w. For example -gnatwaLe turns on all
optional warnings except elaboration warnings and considers
warnings to be errors.
The generated code for many slice assignments has been
improved, resulting in considerably improved execution time
on most targets.
The generated code for multi-dimensional arrays has been
improved, significantly improving performance in many
situations.
The compiler now does a much more effective job of
suppressing checks in array references in loops where the
arrays involved are parameters that are unconstrained array
types, or pointers to unconstrained arrays.
On VxWorks cross-compilers, a new package called
Interfaces.VxWorks provides provides a limited binding to
the VxWorks API. In particular, it interfaces with the
VxWorks hardware interrupt facilities.
The package GNAT.Regexp no longer has any size limitation,
and can handle complex regular expressions.
A new warning switch -gnatwc turns on warnings for
relational and membership operators appearing in statements
(e.g. if statements) whose results are known at compile
time to be always true or always false.
A new pragma Style_Checks allows selection of style checks
in a manner similar to the existing compiler switch, and
also allows the style checks to be temporarily turned off
and then turned back on again.
The binary releases now contain the necessary headers to
compile the C files in the runtime without having to do a
full build of GNAT from sources.
Makefile.adalib now also recompiles the C part of the GNAT
run time, providing the ability to rebuild completely the
GNAT libraries with the binary distribution.
Makefile.adalib is now available for cross compilers, as
well as the native versions of GNAT
The -gnatwu switch now also provides warnings about possible
access to uninitialized out parameters.
The -gnatyk switch (check identifier casing) error messages
now contain a source location reference to the definition of
the relevant identifier.
It is now permissible to specify the non-default Bit_Order
for record subtypes. Component clauses for such types must
either specify an integral number of bytes, or the component
must lie entirely within one byte. Note that, in accordance
with the RM, no reordering of bytes is done, the only effect
is to renumber bits. This feature is therefore only of
limited use in dealing with big/little-endian interfacing.
Default_Bit_Order is now static. This is strictly a
violation of the RM requirement that it be non-static, but
everyone agrees this was a mistake, and an AI is expected to
"fix" this mistake. Other Ada 95 compilers are already
consistent with this modified interpreation of the RM.
Florist has been ported to Solaris 7 and HP-UX 11.00
GNAT now fully supports HP-UX 11.00, including a dual
tasking run time that provides access to the DCE run time
for compatibility with HP-UX 10.20, and to the POSIX pthread
run time.
Interrupt handling on HP-UX has been rewritten to provide a
more powerful and less restrictive signal handling. In
particular, the signals SIGIO and SIGPIPE can now be handled
via Ada.Interrupts.
The listing generated by the -gnatR switch now includes
alignment values for array and record types.
The NT version of GNAT now generates object files that are
fully compatible with the standard Microsoft linker, so this
linker can be used instead of the GNU ld program to build NT
executables.
The default stack size on NT for tasking program has been
reduced to 8Mb (instead of 32Mb). This increase the default
maximum number of tasks from approximately 60 to a value
around 250.
The gnathtml tool can now read the list of files to convert
from a file, eliminating the command line length problem on
some systems.
The parent type of derived types is now recorded in the
cross-reference section of the ali files. The new ali
format is backward compatible with the previous one.
The gnatfind and gnatxref tools have been extended to
display the parent type of derived types. Furthermore
gnatfind is now able to display the full type derivation
informations for a specific type.
Shared libraries are now provided as an option (via the
-shared gnatbind switch) on four additional targets:
Solaris x86, Solaris sparc, Linux and SCO UnixWare.
New restrictions No_Implicit_Conditionals and
No_Implicit_Loops have been added for greater control over
generated code. This is particularly useful in a
safety-critical/certification environment using GNORT (GNAT
with no run time)
The performance of the elementary trigononmetric functions
has been substantially improved.
A new section has been added to the GNAT Reference Manual
providing a complete description of the set of
representation pragmas and pragmas that are accepted by
GNAT, and their effect.
The implementation of the ASIS Data Decomposition Annex is
now complete, with all queries fully supported.
More static checking is now done for pragma Restrictions
(No_Recursion), and most common cases are now detected and
flagged as illegalities.
A new package GNAT.Calendar is provided. It deals with
Hour, Minute, Seconds, Day_Of_Week, Day_In_Year,
Week_In_Year. There is also two functions to do conversions
between Duration and C timeval struct.
A new package GNAT.Calendar.Time_IO is provided. This
package implements formatted output of Ada.Calendar.Time.
The format string uses a format similar to the one used by
the date UNIX command.
The gnatchop utility now recognizes and respect existing
source reference pragmas that it finds in the input file, so
that the output files always properly reflect the original
source file.
The gnatdll tool now accepts the -I switch to search source
and object files in specified directories.
The optimization of checks has been significantly improved,
and many unnecessary checks, particularly in connection with
type conversions and the use of the pos operator, have been
removed.
The traceback stored in the exception occurrence (using the
gnatbind -E switch) now gives accurate values in the case of
a reraise.
The structure used to hold task data has been split to allow
restricted tasking implementations to use less storage for
each task created.
Enumeration representation clauses for types derived from
Boolean are now fully supported.
Variable shift instructions are now generated for
multiplications or divisions by powers of 2 (e.g. x * 2 **
y, where y is Natural).
External symbol names and debugging symbols are now more
fully qualified. This avoids some peculiar naming conflicts
for example in the case where there is a child package and
nested package with the same name, and also improves the
behavior of gdb when fully qualified names are given.
An extended form of the Source_File_Name pragma permits
handling the unusual case where a subunit and child unit
have identical qualified names. This is unusual, but is
allowed by the rules of the language, although both versions
cannot appear in a single partition.
The OpenVMS version of GNAT now fully supports the use of
mixed-case external names. This solves a number of
compatibility problems in this area, which could show up as
unexpected duplicate names.
A new pragma External_Name_Casing is provided for
controlling the casing of external names. This is primarily
for use in OpenVMS systems, but is available in all
implementations.
A new pragma Extensions_Allowed (ON | OFF) is provided for
local control of whether language extensions are allowed.
This pragma may also be used as a configuration pragma (e.g.
in the gnat.adc file) to control the use of extensions for a
series of compilations.
The -gnatwu flag now separately checks specs to make sure
that a with in a spec is now actually used in the spec. If
the with is used only in the body, the warning suggests
moving it to the body.
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 1%]
* more information on OS and compiler
2000-01-06 0:00 1% question about COM2 Alexander Van Hecke
@ 2000-01-07 0:00 0% ` Alexander Van Hecke
0 siblings, 0 replies; 133+ results
From: Alexander Van Hecke @ 2000-01-07 0:00 UTC (permalink / raw)
I was asked to give more information on the OS I intend to run this program
on : It should run on MS-DOS. I use the gnat compiler on Windows 98 (which
can generate DOS code right?). Any help greatly appreciated.
"Alexander Van Hecke" <alexke@hotmail.com> wrote in message
news:3874C02F.53CE5769@hotmail.com...
> hi all,
>
> I have a question about a program I am writing in Ada. The program
> should do the following (I know, it's not much :-)) : you type a number
> (INTEGER) on computer 1, this computer sends the number to computer 2
> via nullmodem connected to COM2, you type a number on computer 2, and
> send this number back to computer 1. both computers do some
> calculations with these numbers and then give some output. I have been
> trying to write a device driver for the serial port communication, but
> I'm stuck. I don't know what the Interrupt_ID is for serial
> communication : in the function Attach_Handler you must pass your
> interrupt handler routine and the interrupt ID. I don't know what this
> is for serial communication, and when I look on the internet, I only
> find examples in C (interrupt ID for serial port is 0xC or 0xB or
> something like that : it doesn't work in Ada). The ultimate goal is to
> write a package that contains two routines : Send_Number(..) and
> Get_Number(...). The numbers that must be sent should be several (> 2)
> bytes, so they should probably be split. Allthough I know my way around
> with C, I have no previous experience with Ada. Does anybody know the
> solution to this problem? I will attach my code as it is right now.
> Any comments / suggestions are very welcome!
>
> Thanks in advance,
> alex
>
>
>
----------------------------------------------------------------------------
----
> -- dit is de Serial_Device_Driver package
> -- let op : we werken met COM2!
> -- dwz : TX en RX buffer op 2F8H
> -- divisor latch register op 2F8H en 2F9H
> -- line control register op 2FBH
> -- line status register op 2FDH
>
> package Serial_Device_Driver is
> type 2bits is range 0..3;
> procedure Get_Number(getal : out INTEGER);
> procedure Send_Number(getal : in INTEGER);
>
> private :
> for 2bits'Size use 2; -- er mogen slechts 2 bits voor gebruikt worden;
>
> end Serial_Device_Driver;
>
> with Ada.Interrupts.Names, System, System.Storage_Elements;
> use Ada.Interrupts.Names, System, System.Storage_Elements;
>
> package body Serial_Device_Driver is
> Bits_In_Word : constant := 16;
> Bits_In_Byte : constant := 8;
> Word : constant := 2;
> type Flag in (Down, Set);
>
> type Line_Control_Register is
> record
> DL_access : Flag; -- divisor latch access bit
> break_control : Flag; -- set break control
> stick_parity : Flag; -- stick parity
> even_parity : Flag; -- even parity select
> parity_enable : Flag; -- parity enable
> stop_bits : Flag; -- stop bits
> word_length : 2bits; -- word length : zet op 11
> end record;
>
> -- nu specifieren we de layout
>
> for Line_Control_Register use
> record
> DL_acces at 0*Word range 7..7;
> break_control at 0*Word range 6..6;
> stick_parity at 0*Word range 5..5;
> even_parity at 0*Word range 4..4;
> parity_enable at 0*Word range 3..3;
> stop_bits at 0*Word range 2..2;
> word_length at 0*Word range 0..1;
> end record;
>
> for Line_Control_Register'Size use Bits_In_Byte; -- het register is 8 bits
> for Line_Control_Register'Alignment use Word;
> for Line_Control_Register'Bit_order us Low_Order_First; -- LSB = 0;
>
>
> type Line_Status_Register is
> record
> TSR_empty : Flag; -- Trans-shift-register empty
> THR_empty : Flag; -- Trans-hold-register empty
> Break_Int : Flag; -- Break interrupt indicator
> Framing_err : Flag; -- Framing error indicator
> Par_err : Flag; -- Parity error indicator
> Overrun_err : Flag; -- Overrun error indicator
> rec_data_ready : Flag; -- Receiver data ready
> end record;
>
> -- nu specifieren we de layout
>
> for Line_Status_Register use
> record
> TSR_empty at 0*Word range 6..6;
> THR_empty at 0*Word range 5..5;
> Break_Int at 0*Word range 4..4;
> Framing_err at 0*Word range 3..3;
> Par_err at 0*Word range 2..2;
> Overrun_err at 0*Word range 1..1;
> rec_data_ready at 0*Word range 0..0;
> end record;
>
> for Line_Status_Register'Size use Bits_In_Byte; -- het register is 8 bits
> for Line_Status_Register'Alignment use Word;
> for Line_Status_Register'Bit_order us Low_Order_First; -- LSB = 0;
>
> -- als bit 7 van het line control register 1 is, dan zijn de adressen 3F8H
en 3F9H voor
> -- het divisor latch register
> -- als bit 7 van het line control register 0 is, dan zijn de adressen 3F8H
en 3F9H voor
> -- het verzenden en ontvangen van data
> -- we moeten dus eerst op allebei de computers bit 7 van het line control
register op
> -- 1 zetten, zodat we de baudsnelheid kunnen selecteren;
> -- als dit gedaan is, zetten we bit 7 van het line control register op 0,
zodat we
> -- de adressen 3F8H en 3F9H kunnen gebruiken als dataregister.
>
> type Divisor_Latch_Register is
> record
> baud_rate : INTEGER;
> end record;
>
> -- specifieren van de layout
>
> for Divisor_Latch_Register use
> record
> baud_rate at 0*Word range 0..15;
> end record;
>
>
> for Divisor_Latch_Register'Size use Bits_In_Word; -- het register is 16
bits
> for Divisor_Latch_Register'Alignment use Word;
> for Divisor_Latch_Register'Bit_order us Low_Order_First; -- LSB = 0;
>
> type Data_Register is INTEGER; -- alle mogelijke getallen kunnen voorkomen
in het data register
> for Data_Register'Size use Bits_In_Word;
>
> Contr_Reg_Addr: constant Address := To_Address(16#2FB#);
> Stat_Reg_Addr : constant Address := To_Address(16#2FD#);
> Latch_Reg_Addr : constant Address := To_Address(16#2F8#);
> Data_Reg_Addr : constant Address := To_Address(16#2F8#);
> Serial_Priority : constant Interrupt_Priority := 63;
>
> Control_Reg : aliased Line_Control_Register;
> for Control_Reg'Address use Contr_Reg_Addr;
>
> Status_Reg : aliased Line_Status_Register;
> for Status_Reg'Address use Stat_Reg_Addr;
>
> Latch_Reg : aliased Divisor_Latch_Register;
> for Latch_Reg'Address use Latch_Reg_Addr;
>
> Data_Reg : aliased Data_Register;
> for Data_Reg'Address use Data_Reg_Addr;
>
>
> -- nu de interrupt interface nog schrijven
>
> protected type Interrupt_Interface(Int_Id : Interrupt_Id;
> Cr : access Line_Control_Register;
> Sr : access Line_Status_Register;
> Lr : access Divisor_Latch_Register;
> Dr : access Data_Register) is
>
> entry Read(getal : out INTEGER); -- het uitlezen van een getal
> entry Write(getal : in INTEGER); -- het schrijven van een getal
> private :
> entry Done(getal : out INTEGER);
> procedure Handler;
> pragma Attach_Handler(Handler, Int_Id)
> pragma Interrupt_Priority(Serial_Priority)
> Interrupt_Occurred : Boolean := False;
> Next_Request : Boolean := True;
> end Interrupt_Interface;
>
> Serial_Interface : Interrupt_Interface(Names.Serial, Control_Reg'Address,
> Status_Reg'Address, Latch_Reg'Address, Data_Reg'Address);
>
> protected body Interrupt_Interface is
>
> entry Read(getal : out INTEGER) when Next_Request is
> Shadow_Register : Control_Register;
> begin
> -- shadow register invullen
> -- en copieren naar controle register
> -- data lezen
>
> Interrupt_Occurred := False;
> Next_Request := False;
> requeue Done;
> end Read;
>
> entry Write(getal : in INTEGER) when not Next_Request is
> Shadow_Register : ???
> begin
> ???
> end Write;
>
> procedure Handler is
> begin
> Interrupt_Occurred := True;
> end Handler;
>
> entry Done(getal : out INTEGER) when Interrupt_Occurred is
> begin
> Next_Request := True;
> -- uitlezen van de data in het getal;
> -- checken op errors?
> end Done;
>
> end Interrupt_Interface;
>
> procedure Get_Number(getal : out INTEGER) is
> begin
> Serial_Interface.Read(getal);
> end Get_Number;
>
> procedure Send_Number(getal : in INTEGER) is
> begin
> -- opsplitsen van getal in afzonderlijke groepjes van 2 bytes!
> -- in het datareg kunnen maar 16 bits tegelijk
> Serial_Interface.Write(getal);
> end Send_Number;
> end Serial_Device_Driver;
>
^ permalink raw reply [relevance 0%]
* question about COM2
@ 2000-01-06 0:00 1% Alexander Van Hecke
2000-01-07 0:00 0% ` more information on OS and compiler Alexander Van Hecke
0 siblings, 1 reply; 133+ results
From: Alexander Van Hecke @ 2000-01-06 0:00 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
hi all,
I have a question about a program I am writing in Ada. The program
should do the following (I know, it's not much :-)) : you type a number
(INTEGER) on computer 1, this computer sends the number to computer 2
via nullmodem connected to COM2, you type a number on computer 2, and
send this number back to computer 1. both computers do some
calculations with these numbers and then give some output. I have been
trying to write a device driver for the serial port communication, but
I'm stuck. I don't know what the Interrupt_ID is for serial
communication : in the function Attach_Handler you must pass your
interrupt handler routine and the interrupt ID. I don't know what this
is for serial communication, and when I look on the internet, I only
find examples in C (interrupt ID for serial port is 0xC or 0xB or
something like that : it doesn't work in Ada). The ultimate goal is to
write a package that contains two routines : Send_Number(..) and
Get_Number(...). The numbers that must be sent should be several (> 2)
bytes, so they should probably be split. Allthough I know my way around
with C, I have no previous experience with Ada. Does anybody know the
solution to this problem? I will attach my code as it is right now.
Any comments / suggestions are very welcome!
Thanks in advance,
alex
[-- Attachment #2: Serial_Device_Driver.ada --]
[-- Type: text/plain, Size: 6159 bytes --]
-- dit is de Serial_Device_Driver package
-- let op : we werken met COM2!
-- dwz : TX en RX buffer op 2F8H
-- divisor latch register op 2F8H en 2F9H
-- line control register op 2FBH
-- line status register op 2FDH
package Serial_Device_Driver is
type 2bits is range 0..3;
procedure Get_Number(getal : out INTEGER);
procedure Send_Number(getal : in INTEGER);
private :
for 2bits'Size use 2; -- er mogen slechts 2 bits voor gebruikt worden;
end Serial_Device_Driver;
with Ada.Interrupts.Names, System, System.Storage_Elements;
use Ada.Interrupts.Names, System, System.Storage_Elements;
package body Serial_Device_Driver is
Bits_In_Word : constant := 16;
Bits_In_Byte : constant := 8;
Word : constant := 2;
type Flag in (Down, Set);
type Line_Control_Register is
record
DL_access : Flag; -- divisor latch access bit
break_control : Flag; -- set break control
stick_parity : Flag; -- stick parity
even_parity : Flag; -- even parity select
parity_enable : Flag; -- parity enable
stop_bits : Flag; -- stop bits
word_length : 2bits; -- word length : zet op 11
end record;
-- nu specifieren we de layout
for Line_Control_Register use
record
DL_acces at 0*Word range 7..7;
break_control at 0*Word range 6..6;
stick_parity at 0*Word range 5..5;
even_parity at 0*Word range 4..4;
parity_enable at 0*Word range 3..3;
stop_bits at 0*Word range 2..2;
word_length at 0*Word range 0..1;
end record;
for Line_Control_Register'Size use Bits_In_Byte; -- het register is 8 bits
for Line_Control_Register'Alignment use Word;
for Line_Control_Register'Bit_order us Low_Order_First; -- LSB = 0;
type Line_Status_Register is
record
TSR_empty : Flag; -- Trans-shift-register empty
THR_empty : Flag; -- Trans-hold-register empty
Break_Int : Flag; -- Break interrupt indicator
Framing_err : Flag; -- Framing error indicator
Par_err : Flag; -- Parity error indicator
Overrun_err : Flag; -- Overrun error indicator
rec_data_ready : Flag; -- Receiver data ready
end record;
-- nu specifieren we de layout
for Line_Status_Register use
record
TSR_empty at 0*Word range 6..6;
THR_empty at 0*Word range 5..5;
Break_Int at 0*Word range 4..4;
Framing_err at 0*Word range 3..3;
Par_err at 0*Word range 2..2;
Overrun_err at 0*Word range 1..1;
rec_data_ready at 0*Word range 0..0;
end record;
for Line_Status_Register'Size use Bits_In_Byte; -- het register is 8 bits
for Line_Status_Register'Alignment use Word;
for Line_Status_Register'Bit_order us Low_Order_First; -- LSB = 0;
-- als bit 7 van het line control register 1 is, dan zijn de adressen 3F8H en 3F9H voor
-- het divisor latch register
-- als bit 7 van het line control register 0 is, dan zijn de adressen 3F8H en 3F9H voor
-- het verzenden en ontvangen van data
-- we moeten dus eerst op allebei de computers bit 7 van het line control register op
-- 1 zetten, zodat we de baudsnelheid kunnen selecteren;
-- als dit gedaan is, zetten we bit 7 van het line control register op 0, zodat we
-- de adressen 3F8H en 3F9H kunnen gebruiken als dataregister.
type Divisor_Latch_Register is
record
baud_rate : INTEGER;
end record;
-- specifieren van de layout
for Divisor_Latch_Register use
record
baud_rate at 0*Word range 0..15;
end record;
for Divisor_Latch_Register'Size use Bits_In_Word; -- het register is 16 bits
for Divisor_Latch_Register'Alignment use Word;
for Divisor_Latch_Register'Bit_order us Low_Order_First; -- LSB = 0;
type Data_Register is INTEGER; -- alle mogelijke getallen kunnen voorkomen in het data register
for Data_Register'Size use Bits_In_Word;
Contr_Reg_Addr: constant Address := To_Address(16#2FB#);
Stat_Reg_Addr : constant Address := To_Address(16#2FD#);
Latch_Reg_Addr : constant Address := To_Address(16#2F8#);
Data_Reg_Addr : constant Address := To_Address(16#2F8#);
Serial_Priority : constant Interrupt_Priority := 63;
Control_Reg : aliased Line_Control_Register;
for Control_Reg'Address use Contr_Reg_Addr;
Status_Reg : aliased Line_Status_Register;
for Status_Reg'Address use Stat_Reg_Addr;
Latch_Reg : aliased Divisor_Latch_Register;
for Latch_Reg'Address use Latch_Reg_Addr;
Data_Reg : aliased Data_Register;
for Data_Reg'Address use Data_Reg_Addr;
-- nu de interrupt interface nog schrijven
protected type Interrupt_Interface(Int_Id : Interrupt_Id;
Cr : access Line_Control_Register;
Sr : access Line_Status_Register;
Lr : access Divisor_Latch_Register;
Dr : access Data_Register) is
entry Read(getal : out INTEGER); -- het uitlezen van een getal
entry Write(getal : in INTEGER); -- het schrijven van een getal
private :
entry Done(getal : out INTEGER);
procedure Handler;
pragma Attach_Handler(Handler, Int_Id)
pragma Interrupt_Priority(Serial_Priority)
Interrupt_Occurred : Boolean := False;
Next_Request : Boolean := True;
end Interrupt_Interface;
Serial_Interface : Interrupt_Interface(Names.Serial, Control_Reg'Address,
Status_Reg'Address, Latch_Reg'Address, Data_Reg'Address);
protected body Interrupt_Interface is
entry Read(getal : out INTEGER) when Next_Request is
Shadow_Register : Control_Register;
begin
-- shadow register invullen
-- en copieren naar controle register
-- data lezen
Interrupt_Occurred := False;
Next_Request := False;
requeue Done;
end Read;
entry Write(getal : in INTEGER) when not Next_Request is
Shadow_Register : ???
begin
???
end Write;
procedure Handler is
begin
Interrupt_Occurred := True;
end Handler;
entry Done(getal : out INTEGER) when Interrupt_Occurred is
begin
Next_Request := True;
-- uitlezen van de data in het getal;
-- checken op errors?
end Done;
end Interrupt_Interface;
procedure Get_Number(getal : out INTEGER) is
begin
Serial_Interface.Read(getal);
end Get_Number;
procedure Send_Number(getal : in INTEGER) is
begin
-- opsplitsen van getal in afzonderlijke groepjes van 2 bytes!
-- in het datareg kunnen maar 16 bits tegelijk
Serial_Interface.Write(getal);
end Send_Number;
end Serial_Device_Driver;
^ permalink raw reply [relevance 1%]
* Re: Interrupt Handlers using GNAT-VxWorks?
1999-10-16 0:00 2% ` Toshitaka Kumano
@ 1999-10-18 0:00 0% ` Robert Dewar
0 siblings, 0 replies; 133+ results
From: Robert Dewar @ 1999-10-18 0:00 UTC (permalink / raw)
In article <38076AEB.11FA6168@cityfujisawa.ne.jp>,
toots@kama.melco.co.jp wrote:
>
> As you may know, GNAT limits "Ada Interrupts" only to
> "signals" probably because of portability, although that
> feature could be an obtacle for those who write codes using
> many user defined vectors.
Actually there is no fundamental reason for this limitation.
If you need to handle interrupts directly and you are using
GNATWorks, please contact report@gnat.com to discuss your
requirements.
Robert Dewar
Ada Core Technologies
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 0%]
* Re: Interrupt Handlers using GNAT-VxWorks?
1999-10-14 0:00 1% Interrupt Handlers using GNAT-VxWorks? John Arnsparger
1999-10-14 0:00 0% ` Rick Stikkers
1999-10-15 0:00 2% ` Martin Gangkofer
@ 1999-10-16 0:00 2% ` Toshitaka Kumano
1999-10-18 0:00 0% ` Robert Dewar
2 siblings, 1 reply; 133+ results
From: Toshitaka Kumano @ 1999-10-16 0:00 UTC (permalink / raw)
To: John Arnsparger
Dear John,
John Arnsparger wrote:
>
> I am trying to attach an interrupt handler (procedure) to Vector #29
> (decimal) on the mvme167
> board using Ada95 "protected" constructs. I have tried
> Ada.Interrupts.Attach_Handler,
> which results in "Program_Error: Trying to overwrite a static Interrupt
> Handler" with a dynamic handler".
>
> I have also tried the "pragma Attach_Handler", which produces a run-time
> error saying
> "Unitialized Interrupt".
>
> Both of these were declared in package bodies.
>
> Does anyone have any helpful hints or examples of successfully doing this
> with GNAT-Works m68K? Or pointers to better references than the LRM? :-)
How about a workaround as follows ?
1. Export the proteced procedure to C function with the pragma Export.
2. Write C wrapper to install the C function with "intConnect ()".
3. Import the wrapper as an Ada procedure with the pragma Import.
4. Call the procedure at an appropriate timing, e.g. in the elaboration
of the package body.
X. Of course, unmasking must be considered in other portion of codes.
P.S.
"Ada Interrupts" and "Interrupts in a CPU" are different things.
"Ada Interrupts" is rather a programmer model than real H/W interrupts,
and the relation between two is undefined in ARM, and implementaion
defined.
As you may know, GNAT limits "Ada Interrupts" only to "signals"
probably because of portability, although that feature could be
an obtacle for those who write codes using many user defined vectors.
Sorry for my poor English.
--
^ permalink raw reply [relevance 2%]
* Re: Interrupt Handlers using GNAT-VxWorks?
1999-10-14 0:00 1% Interrupt Handlers using GNAT-VxWorks? John Arnsparger
1999-10-14 0:00 0% ` Rick Stikkers
@ 1999-10-15 0:00 2% ` Martin Gangkofer
1999-10-16 0:00 2% ` Toshitaka Kumano
2 siblings, 0 replies; 133+ results
From: Martin Gangkofer @ 1999-10-15 0:00 UTC (permalink / raw)
In article <7u500m$e96@niven.ksc.nasa.gov>,
"John Arnsparger" <jarnspar@ems.jsc.nasa.gov> wrote:
> I am trying to attach an interrupt handler (procedure) to Vector #29
> (decimal) on the mvme167
> board using Ada95 "protected" constructs. I have tried
> Ada.Interrupts.Attach_Handler,
> which results in "Program_Error: Trying to overwrite a static
Interrupt
> Handler" with a dynamic handler".
>
> I have also tried the "pragma Attach_Handler", which produces a
run-time
> error saying
> "Unitialized Interrupt".
>
> Both of these were declared in package bodies.
>
> Does anyone have any helpful hints or examples of successfully doing
this
> with GNAT-Works m68K? Or pointers to better references than the LRM?
:-)
>
> Thanks.
>
> John M. Arnsparger
> Lockheed Martin Space Operations
> e-mail john.arnsparger1@jsc.nasa.gov
> Phone (281) 244 9693
> Fax (281) 244 9681
>
>
I actually have had the same problem using APEX/Tornado on top of
VxWorks. As I remember there was a package named
ada.interrupts.rational.handler.dependent.1.ada
This package contains a handler table, which selects, which interrupts
are legal interrupts and which are not. On illegal interrupts a
Program_Error is raised. Unfortunately, after I made this change, the
problem did relax (I think before I got a Program_Error on call to any
routine in Ada.Interrupts), but there were still Program_Errors raised
when I tried to attach an interrupt handler.
RATIONAL support obviously was not not able to solve this problem, which
was critical to the project I was working on, within half a year! So I
was forced to do a bloody, unstable workaround using a C procedure and
Vxworks interrupt service connect.
This experience was one reason for us to select gnat for our next
project starting end of the year. Therefore I would be happy if you
could keep me informed via email or this newsgroup, whether or gnat
support (ACT) could solve the problem.
--
Martin Gangkofer, System Engineer
ESG Elektroniksystem und -Logistik GmbH, Dept.EF-E
eMail: mgangkof@esg-gmbh.de
Tel: +49 89 9216 2176
Sent via Deja.com http://www.deja.com/
Before you buy.
^ permalink raw reply [relevance 2%]
* Interrupt Handlers using GNAT-VxWorks?
@ 1999-10-14 0:00 1% John Arnsparger
1999-10-14 0:00 0% ` Rick Stikkers
` (2 more replies)
0 siblings, 3 replies; 133+ results
From: John Arnsparger @ 1999-10-14 0:00 UTC (permalink / raw)
I am trying to attach an interrupt handler (procedure) to Vector #29
(decimal) on the mvme167
board using Ada95 "protected" constructs. I have tried
Ada.Interrupts.Attach_Handler,
which results in "Program_Error: Trying to overwrite a static Interrupt
Handler" with a dynamic handler".
I have also tried the "pragma Attach_Handler", which produces a run-time
error saying
"Unitialized Interrupt".
Both of these were declared in package bodies.
Does anyone have any helpful hints or examples of successfully doing this
with GNAT-Works m68K? Or pointers to better references than the LRM? :-)
Thanks.
John M. Arnsparger
Lockheed Martin Space Operations
e-mail john.arnsparger1@jsc.nasa.gov
Phone (281) 244 9693
Fax (281) 244 9681
^ permalink raw reply [relevance 1%]
* Re: Interrupt Handlers using GNAT-VxWorks?
1999-10-14 0:00 1% Interrupt Handlers using GNAT-VxWorks? John Arnsparger
@ 1999-10-14 0:00 0% ` Rick Stikkers
1999-10-15 0:00 2% ` Martin Gangkofer
1999-10-16 0:00 2% ` Toshitaka Kumano
2 siblings, 0 replies; 133+ results
From: Rick Stikkers @ 1999-10-14 0:00 UTC (permalink / raw)
I was able to attach to an interrupt using a task entry. This code worked
with the Verdix Ada-83 cross compiler running in SUNOS 4.1.4 with a target of
a VME 68040 processor. Hopefully it will work for you.
Rick
clock_interrupt_vector : constant := 16#44#;
task timer_tick is
entry start;
entry tick_isr;
for tick_isr use at SYSTEM.address'ref( clock_interrupt_vector );
pragma passive( interrupt, 16#0700# );
end timer_tick;
John Arnsparger wrote:
> I am trying to attach an interrupt handler (procedure) to Vector #29
> (decimal) on the mvme167
> board using Ada95 "protected" constructs. I have tried
> Ada.Interrupts.Attach_Handler,
> which results in "Program_Error: Trying to overwrite a static Interrupt
> Handler" with a dynamic handler".
>
> I have also tried the "pragma Attach_Handler", which produces a run-time
> error saying
> "Unitialized Interrupt".
>
> Both of these were declared in package bodies.
>
> Does anyone have any helpful hints or examples of successfully doing this
> with GNAT-Works m68K? Or pointers to better references than the LRM? :-)
>
> Thanks.
>
> John M. Arnsparger
> Lockheed Martin Space Operations
> e-mail john.arnsparger1@jsc.nasa.gov
> Phone (281) 244 9693
> Fax (281) 244 9681
^ permalink raw reply [relevance 0%]
* Re: capturing parallel port interrupt?
1999-09-08 0:00 1% capturing parallel port interrupt? Josh Highley
@ 1999-09-09 0:00 0% ` Tarjei Jensen
0 siblings, 0 replies; 133+ results
From: Tarjei Jensen @ 1999-09-09 0:00 UTC (permalink / raw)
Josh Highley wrote :
> I've searched deja.com, the GNAT manual, and the ARM but I can't seem to
>figure this out. I'm using Jerry van Dijk's io_ports package to control the
>pins of the parallel port. I'd like to attach an interrupt to pin 10 (ACK).
>I tried Jerry's DOS_interrupts package but it's for GNAT 3.10 and the link
>failed. I also looked through the ada.interrupts package but I'm not sure
>how to go about finding the system ID for the parallel interrupt. Any code,
>explanations or links would be greatly appreciated.
It might be that you will have to read up on the PC architecture. I would not
be surprised if you have to twiddle the bits by hand.
The bit twiddling includes finding out how to enable interrupts on the system
interrupt controller and how to massage the parallell port hardware to generate
the required interrupt.
Perhaps the PC Hardware Bible (or a functional equivalent) includes enough
information to do the job.
Greetings,
^ permalink raw reply [relevance 0%]
* capturing parallel port interrupt?
@ 1999-09-08 0:00 1% Josh Highley
1999-09-09 0:00 0% ` Tarjei Jensen
0 siblings, 1 reply; 133+ results
From: Josh Highley @ 1999-09-08 0:00 UTC (permalink / raw)
I've searched deja.com, the GNAT manual, and the ARM but I can't seem to
figure this out. I'm using Jerry van Dijk's io_ports package to control the
pins of the parallel port. I'd like to attach an interrupt to pin 10 (ACK).
I tried Jerry's DOS_interrupts package but it's for GNAT 3.10 and the link
failed. I also looked through the ada.interrupts package but I'm not sure
how to go about finding the system ID for the parallel interrupt. Any code,
explanations or links would be greatly appreciated.
Thanks,
Josh
joshhighley@hotmail.com
^ permalink raw reply [relevance 1%]
* Re: Interrupt Handler Problems
@ 1999-07-09 0:00 1% ` Charles H. Sampson
0 siblings, 0 replies; 133+ results
From: Charles H. Sampson @ 1999-07-09 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4018 bytes --]
In article <3784D1A2.5B40939C@pwfl.com>,
Marin David Condic <diespammer@pwfl.com> wrote:
>I wrote:
>>
>> We're having a terrible time getting our code running in the new
>> environment. The killer problem of the moment is interrupt handlers.
>> (We have a lot of them.) Our handlers have been modified into protected
>> procedures, as required by Green Hills, but they don't seem to be seeing
>> the interrupts. Green Hills assures us that interrupts are enabled when
>> the main program begins executing. However, when we enable them our-
>> selves in a little test program, its interrupt handler begins working.
>> When we enable them in our "real" code, VxWorks blows up with a
>> workQPanic. The three vendors are now in a finger-pointing contest (the
>> Navy term is ruder), each claiming that it's not their fault, it must be
>> caused by one of the others.
>>
>
>I've had similar problems with connecting to interrupts with other
>compilers. Here's a couple of things to check: The interrupt handling
>routines are generally considered to be a kind of "task", if you will,
>in that compilers often create some sort of memory heap for them. If you
>have a lot of handlers and the memory reserved for each is by default
>large, you can blow the available memory and be standing there doing
>nothing with an unhandled exception. This could be why your little test
>program works fine, but the same thing scaled up to the "real" system
>won't run.
I doubt that absolute memory usage is a problem, but we'll probably
check it at some point. Thanks.
>Also, it would help to know exactly how the RTK connects your ISRs to
>the interrupts. Do you get a "hard" connection where the address of your
>ISR is directly placed in the interrupt service vector? Or does the RTK
>step into the middle of it so that first the RTK is called, then
>(eventually) your ISR? The former is easier to deal with usually because
>you don't have to guess about what might be going on between the
>interrupt and you.
An interrupt handler in VxWorks is not a task, it is a very re-
stricted procedure (void function in the documentation; VxWorks is very
Unix-like). Even working at the VxWorks/C level, the address of the in-
terrupt handler is not put directly into the vector. Instead, when the
call to set up a handler is made, VxWorks puts a little wrapper around
it. The wrapper does such things as setting up the stack and saving and
restoring registers. Green Hills Ada might also put a wrapper around
the protected procedure, but their documentation implies not.
>Can you post a sample of the code that demonstrates how the ISR is coded
>& how you are connecting to the interrupts?
Because of the restrictions on interrupt handlers under VxWorks,
ours are absolutely minimal. The technique for attaching the handler is
pure Ada. Here is an example (vertical white space removed):
protected Handler_Object is
procedure Start;
procedure Handler;
pragma Interrupt_Handler (Handler);
entry Release_For_Processing;
private
Interrupt_Occurred : Boolean := False;
end Handler_Object;
protected body Handler_Object is
procedure Start is
begin
Ada.Interrupts.Attach_Handler (Handler�Access, Vector_No);
end Start;
procedure Handler is
begin
Interrupt_Occurred := True;
end Handler;
entry Release_For_Processing when Interrupt_Occurred is
begin
Interrupt_Occurred := False;
end Release_For_Processing;
end Handler_Object;
A call to Start is made to attach the handler. Associated with the
handler is a high priority task that we call an interrupt processor. It
hangs on the Release_For_Processing entry until an interrupt occurs and
then does whatever is necessary to respond to the interrupt.
Charlie
--
******
For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".
^ permalink raw reply [relevance 1%]
* Interrupt problem in GNAT
@ 1999-05-19 0:00 2% Joerg Kienzle
0 siblings, 0 replies; 133+ results
From: Joerg Kienzle @ 1999-05-19 0:00 UTC (permalink / raw)
Hi,
I am running gnat 3.11w on Solaris, and I am trying to use interrupts to
perform a periodic operation. I have declared the following package:
with Ada.Interrupts; use Ada.Interrupts;
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
package Clocks is
protected Clock is
procedure Tick;
pragma Interrupt_Handler (Tick);
pragma Attach_Handler (Tick, SIGALRM);
end Clock;
end Clocks;
And the body:
package body Clocks is
protected body Clock is
procedure Tick is
begin
-- Do something here
end Tick;
end Clock;
end Clocks;
As you can see in the spec, I am trying to attach the Tick procedure
to the SIGALRM signal. In my main procedure, I use the operating
system functions timer_create and timer_settime to tell the OS to
send SIGALRM to my process every x seconds.
This works; the process gets a SIGALRM signal, but my handler function
in not called! Instead, "Alarm clock" is printed on the terminal and
the process exits...
The same thing happens if I use the "alarm" function to send
the SIGALRM signal:
with Interfaces.C;
with Clocks;
procedure Main is
procedure Alarm (Sec : C.Unsigned);
pragma Import (C, Alarm, "alarm");
procedure Set_Alarm (I : in Natural);
procedure Set_Alarm (I : in Natural) is
begin
Alarm (C.Unsigned (I));
end Set_Alarm;
begin
Set_Alarm (5);
while True loop
null;
end loop;
end Main;
I tried other signals, but I still doesn't work.
What am I doing wrong?
- J�rg
--
---------------------------------------------------------------------------
- Joerg Kienzle - Swiss Federal Institue of Technology - CH-1015
Lausanne -
- email : Joerg.Kienzle@epfl.ch WWW :
http://lglwww.epfl.ch/~jkienzle/ -
- phone : ++41 21 693 42 37 fax : ++41 21 693 50
79 -
^ permalink raw reply [relevance 2%]
* Re: Ada83 and Ada95 interrupt handling
@ 1999-03-05 0:00 2% ` Robert A Duff
0 siblings, 0 replies; 133+ results
From: Robert A Duff @ 1999-03-05 0:00 UTC (permalink / raw)
Armin <ArminSchmidle@swol.de> writes:
> I am porting an Ada83 application to Ada95. In Ada83 there was a
> construction
> known as interrupt entry.
...
> How can I do the same thing in Ada95 ?
I just happened to be working on some examples of interrupt handling for
our (Averstar's) AdaMagic for SHARC implementation, which we validated
last month.
When using a protected procedure as an interrupt handler, there are (at
least) two ways to make the handler notify a task that the interrupt has
occurred. You can have the task wait on an entry of the same protected
object as the interrupt handler. Or, you can use suspension objects.
Here's an extract from the documentation I wrote:
...
Example 2.
The second example prints the following:
Hello from Interrupt_Test_With_Entries main procedure.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Goodbye from Interrupt_Test_With_Entries main procedure.
Waiting_Task: Got interrupt.
Goodbye from Waiting_Task.
----------------------------------------------------------------
-- This example illustrates how an interrupt handler (a protected
-- procedure) may communicate with a task using an entry. The interrupt
-- handler is called when the interrupt occurs, and it causes the
-- entry's barrier to become True. The task waits by calling the entry;
-- it is blocked until the barrier becomes True.
-- In this example, we simulate 10 interrupts, and we have a task
-- (Waiting_Task) that waits for 10 interrupts by calling the entry.
-- Each interrupt triggers one call to the entry to proceed. In this
-- example, the only information being transmitted back to the waiting
-- task is the fact that the interrupt has occurred.
-- In a real program, the protected object might have additional
-- operations to do something to some external device (e.g. initiate
-- some I/O). This might cause the device to generate an interrupt.
-- The interrupt would not be noticed until after this operation
-- returns, even if the device generates the interrupt right away;
-- that's because of the priority rules. Also, the interrupt handler
-- might get some information from the device, save it locally in the
-- protected object, and then the entry body might pass this information
-- back to the task via an 'out' parameter.
-- In other words, a protected object used in this way acts as a "device
-- driver", containing operations to initiate I/O operations, to wait
-- for operations to complete, and to handle interrupts. Anything that
-- needs to be done while masking the interrupt of the device should be
-- part of the protected object.
-- Note that if multiple device drivers are needed for similar devices,
-- it is convenient to declare a protected type, and declare multiple
-- objects of that type. Discriminants can be used to pass in
-- information specific to individual devices.
----------------------------------------------------------------
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
with System.RTS.Temp_IO; use System.RTS.Temp_IO;
package Interrupt_Test_With_Entries is
-- Empty.
end Interrupt_Test_With_Entries;
----------------------------------------------------------------
package Interrupt_Test_With_Entries.Handlers is
pragma Elaborate_Body;
protected Handler_PO is
procedure Handler; -- The interrupt handler.
pragma Attach_Handler(Handler, SFT0I);
-- SFT0I is declared in Ada.Interrupts.Names.
entry Await_Interrupt;
-- Each time Handler is called,
-- this entry is triggered.
private
Interrupt_Occurred: Boolean := False;
end Handler_PO;
end Interrupt_Test_With_Entries.Handlers;
----------------------------------------------------------------
package body Interrupt_Test_With_Entries.Handlers is
protected body Handler_PO is
procedure Handler is
begin
Interrupt_Occurred := True;
end Handler;
entry Await_Interrupt when Interrupt_Occurred is
begin
Interrupt_Occurred := False;
end Await_Interrupt;
end Handler_PO;
end Interrupt_Test_With_Entries.Handlers;
----------------------------------------------------------------
package Interrupt_Test_With_Entries.Waiting_Tasks is
pragma Elaborate_Body; -- So the body is allowed.
end Interrupt_Test_With_Entries.Waiting_Tasks;
----------------------------------------------------------------
with Interrupt_Test_With_Entries.Handlers; use Interrupt_Test_With_Entries.Handlers;
package body Interrupt_Test_With_Entries.Waiting_Tasks is
task Waiting_Task;
task body Waiting_Task is
begin
for I in 1..10 loop
Handler_PO.Await_Interrupt;
Put_Line("Waiting_Task: Got interrupt.");
end loop;
Put_Line("Goodbye from Waiting_Task.");
end Waiting_Task;
end Interrupt_Test_With_Entries.Waiting_Tasks;
----------------------------------------------------------------
with System.Machine_Intrinsics;
with Interrupt_Test_With_Entries.Waiting_Tasks;
-- There are no references to this package; this with_clause is here
-- so that task Waiting_Task will be included in the program.
procedure Interrupt_Test_With_Entries.Main is
procedure Generate_Interrupt(Interrupt : Ada.Interrupts.Interrupt_ID) is
-- This uses machine code intrinsics to simulate a hardware
-- interrupt, by generating an interrupt in software.
use System.Machine_Intrinsics;
-- This sets the N'th bit in IRPTL, where N is the interrupt number,
-- which causes the interrupt to happen; see page 3-26 of the
-- ADSP-2106x SHARC Users' Manual, Second Edition.
-- We want to use the BIT SET instruction, so it's atomic,
-- but that instruction requires an immediate value;
-- we can't calculate 2**N and use that as the mask;
-- hence the rather repetitive code below.
procedure Gen_0 is
pragma Inline(Gen_0);
begin
Asm("BIT SET IRPTL 0x00000001;");
end Gen_0;
procedure Gen_1 is
pragma Inline(Gen_1);
begin
Asm("BIT SET IRPTL 0x00000002;");
end Gen_1;
procedure Gen_2 is
pragma Inline(Gen_2);
begin
Asm("BIT SET IRPTL 0x00000004;");
end Gen_2;
procedure Gen_3 is
pragma Inline(Gen_3);
begin
Asm("BIT SET IRPTL 0x00000008;");
end Gen_3;
procedure Gen_4 is
pragma Inline(Gen_4);
begin
Asm("BIT SET IRPTL 0x00000010;");
end Gen_4;
procedure Gen_5 is
pragma Inline(Gen_5);
begin
Asm("BIT SET IRPTL 0x00000020;");
end Gen_5;
procedure Gen_6 is
pragma Inline(Gen_6);
begin
Asm("BIT SET IRPTL 0x00000040;");
end Gen_6;
procedure Gen_7 is
pragma Inline(Gen_7);
begin
Asm("BIT SET IRPTL 0x00000080;");
end Gen_7;
procedure Gen_8 is
pragma Inline(Gen_8);
begin
Asm("BIT SET IRPTL 0x00000100;");
end Gen_8;
procedure Gen_9 is
pragma Inline(Gen_9);
begin
Asm("BIT SET IRPTL 0x00000200;");
end Gen_9;
procedure Gen_10 is
pragma Inline(Gen_10);
begin
Asm("BIT SET IRPTL 0x00000400;");
end Gen_10;
procedure Gen_11 is
pragma Inline(Gen_11);
begin
Asm("BIT SET IRPTL 0x00000800;");
end Gen_11;
procedure Gen_12 is
pragma Inline(Gen_12);
begin
Asm("BIT SET IRPTL 0x00001000;");
end Gen_12;
procedure Gen_13 is
pragma Inline(Gen_13);
begin
Asm("BIT SET IRPTL 0x00002000;");
end Gen_13;
procedure Gen_14 is
pragma Inline(Gen_14);
begin
Asm("BIT SET IRPTL 0x00004000;");
end Gen_14;
procedure Gen_15 is
pragma Inline(Gen_15);
begin
Asm("BIT SET IRPTL 0x00008000;");
end Gen_15;
procedure Gen_16 is
pragma Inline(Gen_16);
begin
Asm("BIT SET IRPTL 0x00010000;");
end Gen_16;
procedure Gen_17 is
pragma Inline(Gen_17);
begin
Asm("BIT SET IRPTL 0x00020000;");
end Gen_17;
procedure Gen_18 is
pragma Inline(Gen_18);
begin
Asm("BIT SET IRPTL 0x00040000;");
end Gen_18;
procedure Gen_19 is
pragma Inline(Gen_19);
begin
Asm("BIT SET IRPTL 0x00080000;");
end Gen_19;
procedure Gen_20 is
pragma Inline(Gen_20);
begin
Asm("BIT SET IRPTL 0x00100000;");
end Gen_20;
procedure Gen_21 is
pragma Inline(Gen_21);
begin
Asm("BIT SET IRPTL 0x00200000;");
end Gen_21;
procedure Gen_22 is
pragma Inline(Gen_22);
begin
Asm("BIT SET IRPTL 0x00400000;");
end Gen_22;
procedure Gen_23 is
pragma Inline(Gen_23);
begin
Asm("BIT SET IRPTL 0x00800000;");
end Gen_23;
procedure Gen_24 is
pragma Inline(Gen_24);
begin
Asm("BIT SET IRPTL 0x01000000;");
end Gen_24;
procedure Gen_25 is
pragma Inline(Gen_25);
begin
Asm("BIT SET IRPTL 0x02000000;");
end Gen_25;
procedure Gen_26 is
pragma Inline(Gen_26);
begin
Asm("BIT SET IRPTL 0x04000000;");
end Gen_26;
procedure Gen_27 is
pragma Inline(Gen_27);
begin
Asm("BIT SET IRPTL 0x08000000;");
end Gen_27;
procedure Gen_28 is
pragma Inline(Gen_28);
begin
Asm("BIT SET IRPTL 0x10000000;");
end Gen_28;
procedure Gen_29 is
pragma Inline(Gen_29);
begin
Asm("BIT SET IRPTL 0x20000000;");
end Gen_29;
procedure Gen_30 is
pragma Inline(Gen_30);
begin
Asm("BIT SET IRPTL 0x40000000;");
end Gen_30;
procedure Gen_31 is
pragma Inline(Gen_31);
begin
Asm("BIT SET IRPTL 0x80000000;");
end Gen_31;
subtype Handleable_Range is Ada.Interrupts.Interrupt_ID
range 0..31; -- These are the only interrupts that
-- actually exist in the hardware.
begin
case Handleable_Range'(Interrupt) is
when 0 => Gen_0;
when 1 => Gen_1;
when 2 => Gen_2;
when 3 => Gen_3;
when 4 => Gen_4;
when 5 => Gen_5;
when 6 => Gen_6;
when 7 => Gen_7;
when 8 => Gen_8;
when 9 => Gen_9;
when 10 => Gen_10;
when 11 => Gen_11;
when 12 => Gen_12;
when 13 => Gen_13;
when 14 => Gen_14;
when 15 => Gen_15;
when 16 => Gen_16;
when 17 => Gen_17;
when 18 => Gen_18;
when 19 => Gen_19;
when 20 => Gen_20;
when 21 => Gen_21;
when 22 => Gen_22;
when 23 => Gen_23;
when 24 => Gen_24;
when 25 => Gen_25;
when 26 => Gen_26;
when 27 => Gen_27;
when 28 => Gen_28;
when 29 => Gen_29;
when 30 => Gen_30;
when 31 => Gen_31;
end case;
end Generate_Interrupt;
begin
-- Generate 10 simulated interrupts, with delays in between.
Put_Line("Hello from Interrupt_Test_With_Entries main procedure.");
for I in 1..10 loop
delay 0.01;
Put_Line("Generating interrupt.");
Generate_Interrupt(SFT0I);
end loop;
Put_Line("Goodbye from Interrupt_Test_With_Entries main procedure.");
end Interrupt_Test_With_Entries.Main;
================================================================
================================================================
Example 3.
The third example prints the following:
Hello from Suspension_Objects_Test main procedure.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Generating interrupt.
Waiting_Task: Got interrupt.
Goodbye from Waiting_Task.
Generating interrupt.
Generating interrupt.
Generating interrupt.
Generating interrupt.
Generating interrupt.
Generating interrupt.
Goodbye from Suspension_Objects_Test main procedure.
-- This example illustrates how an interrupt handler
-- (a protected procedure) may communicate with a task
-- using a suspension object. A suspension object allows a
-- task or interrupt handler to notify another task that some
-- event (in our case, an interrupt) has occurred.
-- Each time the interrupt occurs, the suspension object is set to True.
-- The task waits for this event by calling Suspend_Until_True.
-- In this example, we simulate some interrupts,
-- and we have a task (Waiting_Task) that waits for them
-- using a suspension object called Interrupt_Occurred.
-- Note that if the task is already waiting (the usual case) when the
-- interrupt occurs, Interrupt_Occurred is only set to True momentarily;
-- Suspend_Until_True automatically resets it to False. If the task is
-- not waiting, then the True state will be remembered, and when the
-- task gets around to waiting, it will reset it to False and proceed
-- immediately.
-- Note that only one task can wait on a given suspension object; it's
-- sort of like a protected object with an entry queue of length one,
-- which allows it to be implemented more efficiently. This means that
-- the programmer using suspension objects has to know which task will
-- do the waiting; it's as if that task has a kind of ownership of that
-- particular suspension object.
----------------------------------------------------------------
with Ada.Interrupts.Names; use Ada.Interrupts.Names;
with System.RTS.Temp_IO; use System.RTS.Temp_IO;
package Suspension_Objects_Test is
-- Empty.
end Suspension_Objects_Test;
----------------------------------------------------------------
with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control;
package Suspension_Objects_Test.Handlers is
pragma Elaborate_Body;
protected Handler_PO is
procedure Handler; -- The interrupt handler.
pragma Attach_Handler(Handler, SFT0I);
end Handler_PO;
Interrupt_Occurred: Suspension_Object;
-- Default-initialized to False.
-- Set to True for each interrupt.
end Suspension_Objects_Test.Handlers;
----------------------------------------------------------------
package body Suspension_Objects_Test.Handlers is
protected body Handler_PO is
procedure Handler is
begin
Set_True(Interrupt_Occurred);
end Handler;
end Handler_PO;
end Suspension_Objects_Test.Handlers;
----------------------------------------------------------------
package Suspension_Objects_Test.Waiting_Tasks is
pragma Elaborate_Body; -- So the body is allowed.
end Suspension_Objects_Test.Waiting_Tasks;
----------------------------------------------------------------
with Suspension_Objects_Test.Handlers; use Suspension_Objects_Test.Handlers;
with Ada.Synchronous_Task_Control; use Ada.Synchronous_Task_Control;
package body Suspension_Objects_Test.Waiting_Tasks is
task Waiting_Task;
task body Waiting_Task is
begin
for I in 1..4 loop
Suspend_Until_True(Interrupt_Occurred);
Put_Line("Waiting_Task: Got interrupt.");
end loop;
Put_Line("Goodbye from Waiting_Task.");
end Waiting_Task;
end Suspension_Objects_Test.Waiting_Tasks;
----------------------------------------------------------------
with System.Machine_Intrinsics;
with Suspension_Objects_Test.Waiting_Tasks;
-- There are no references to this package; this with_clause is here
-- so that task Waiting_Task will be included in the program.
procedure Suspension_Objects_Test.Main is
procedure Generate_Interrupt(Interrupt : Ada.Interrupts.Interrupt_ID) is
... -- as in previous example
end Generate_Interrupt;
begin
-- Generate some simulated interrupts, with delays in between.
Put_Line("Hello from Suspension_Objects_Test main procedure.");
for I in 1..10 loop
delay 0.01;
Put_Line("Generating interrupt.");
Generate_Interrupt(SFT0I);
end loop;
Put_Line("Goodbye from Suspension_Objects_Test main procedure.");
end Suspension_Objects_Test.Main;
--
Change robert to bob to get my real email address. Sorry.
^ permalink raw reply [relevance 2%]
* Re: Connecting To Interrupts Using Protected Procedures
@ 1999-02-18 0:00 2% ` Pat Rogers
1999-02-18 0:00 1% ` Marin David Condic
0 siblings, 1 reply; 133+ results
From: Pat Rogers @ 1999-02-18 0:00 UTC (permalink / raw)
Marin wrote:
>>Now Ada95 allows this as per ARM J.7.1 etc. but given that it is
>>considered obsolete, I'd like to do it by the preferred method. So
I've
>>looked at connecting the 1ms interrupt to a protected procedure and
this
>>all looks pretty straightforward. The problem is getting this
protected
>>procedure to periodically kick off the slower cycle task. According
to
>>ARM 9.5.1(8..17) you can't call an entry from there without creating
a
>>bounded error. (Maybe it will run, but only if the system can't
detect
>>it and raise Program_Error.) So how is it that the protected
procedure
>>should communicate to the slower task to start cycling? You want the
>>slower task to be blocked until its time cycle comes around again,
so
>>you would naturally think of some form of entry - but so far as I
can
>>see, I've got no way of legally doing that. I suppose one could poll
a
>>shared variable until the interrupt handler set the flag, but
polling
>>answers are just not practical in this arena. (Ideally, you would
want
>>to implement this with a clock and a delay statement, but the
hardware
>>doesn't support this at the moment.)
and I wrote:
>It sounds like you should have the slower task call and suspend on an
>entry in the interrupt handler protected object, and have the
>interrupt handler procedure set a flag (inside that same PO) that
>allows that entry call to proceed whenever appropriate (ie on the Nth
>cycle). The flag is false until the interrupt handler (procedure)
>determines that it is appropriate for the task to return from the
>call.
Since you asked for a snippet of code:
with System;
with Ada.Interrupts;
package IO is
N : constant := 1000; -- whatever
Device_Priority : constant System.Interrupt_Priority :=
System.Interrupt_Priority'Last; -- whatever
Device_Id : constant Ada.Interrupts.Interrupt_Id := 0; --
whatever
protected Handler is
entry Wait;
pragma Interrupt_Priority( Device_Priority );
private
procedure Handle_Interrupt;
pragma Attach_Handler( Handle_Interrupt, Device_Id );
Count : Integer range 0 .. N := 0;
Enable_Waiting_Caller : Boolean := False;
end Handler;
end IO;
package body IO is
protected body Handler is
entry Wait when Enable_Waiting_Caller is
begin
Count := 0;
Enable_Waiting_Caller := False;
end Wait;
procedure Handle_Interrupt is
begin
-- do stuff, including incrementing Count
if Count = N then
Enable_Waiting_Caller := True;
end if;
end Handle_Interrupt;
end Handler;
end IO;
^ permalink raw reply [relevance 2%]
* Re: Connecting To Interrupts Using Protected Procedures
1999-02-18 0:00 2% ` Pat Rogers
@ 1999-02-18 0:00 1% ` Marin David Condic
0 siblings, 0 replies; 133+ results
From: Marin David Condic @ 1999-02-18 0:00 UTC (permalink / raw)
Pat Rogers wrote:
>
>
> Since you asked for a snippet of code:
>
<snip>
I also received help from David Brown wherein he posted the code
attached. Very similar answers so it seems this is a fairly common way
to go. I appreciate all the help on this. Now the only question we'll
have to answer is how efficient/inefficient the various features may
be...
MDC
===========================================================================
I think this is similar to what you want. Feel free to post this.
I'm having problems with the configuration of my newsreader, and am
having trouble posting.
...
Tick_Divider : constant := 9;
protected Pclock is
entry Wait;
procedure Tick;
pragma Attach_Handler (Tick, Ada.Interrupts.Names.SIGINT);
private
Counter : Natural := 0;
end Pclock;
protected body Pclock is
entry Wait when Counter > Tick_Divider is
begin
Counter := 0;
end Wait;
procedure Tick is
begin
Counter := Counter + 1;
end Tick;
end Pclock;
task Waiter is
end Waiter;
task body Waiter is
begin
loop
Pclock.Wait;
Ada.Text_IO.Put_Line ("Got slower ticks");
end loop;
end Waiter;
==========================================================================
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
Ph: 561.796.8997 Fx: 561.796.4669
***To reply, remove "bogon" from the domain name.***
"Crime does not pay ... as well as politics."
-- A. E. Newman
^ permalink raw reply [relevance 1%]
* Re: Support of Task Interrupt Entries
1998-10-13 0:00 1% ` Charles H. Sampson
@ 1998-10-14 0:00 2% ` Robert I. Eachus
0 siblings, 0 replies; 133+ results
From: Robert I. Eachus @ 1998-10-14 0:00 UTC (permalink / raw)
> The standard can't reasonably define a set of addresses and
>interrupts to support, so that is left to the implementors, who can
>choose none. Of course, the rules of J.7.1 do apply to any interrupt
>entries that are supported.
In article <1998Oct13.183104.3784@nosc.mil> claveman@inetworld.net (Charles H. Sampson) writes:
> Actually, it looks to me like the second sentence of C.3.2(22)
> blesses this compiler's implementation. It says, "This function
> [Ada.Interrupts.Reference] raises Program_Error if attaching task
> entries to interrupts ... is not supported."
> I thought I had read the pertinent sections of the LRM quite
> closely. I even searched around a bit to see if "permitted" had been
> given a specialized, non-standard, meaning. Now, on rereading those
> sections, I see that I missed a crucial point. 1.1.3(16) says that a
> standard-conforming implementation must support each capability
> _required_ by the core language. Since J.7.1(1) says, "Implementations
> _are permitted_ ...," this is obviously not a requirement. All very
> clear, once you see it. Duh!
This is one of those cases where the RM goes as far as it can, and
the marketplace has to take it the rest of the way. The RM can't
require that the hardware has any particular set of interrupts, but it
does require for the SP and RT annexes that the package Ada.Interrupts
be present. Annex J is always required, but since support for
interrupt entries was not required in Ada 83, they are permitted, not
required by the various annexes.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 2%]
* Re: Support of Task Interrupt Entries
1998-10-08 0:00 2% ` Robert I. Eachus
@ 1998-10-13 0:00 1% ` Charles H. Sampson
1998-10-14 0:00 2% ` Robert I. Eachus
0 siblings, 1 reply; 133+ results
From: Charles H. Sampson @ 1998-10-13 0:00 UTC (permalink / raw)
In article <EACHUS.98Oct8150309@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>In article <1998Oct7.183511.17020@nosc.mil> csampson@inetworld.net (me) writes:
>
> > According to LRM 1.1.2(6), Annex J is part of the core language
> > and must therefore be supported by any standard-conforming compiler.
> > However, in J.7.1(1) we have, "Implementations are _permitted_ to allow
> > the attachment of task entries to interrupts via the address clause."
> > Does this mean that they are also permitted to disallow this?
>
> The next paragraph should make it clear:
>
> "The address of the task entry corresponds to a hardware interrupt
>in an implementation-defined manner."
>
> The standard can't reasonably define a set of addresses and
>interrupts to support, so that is left to the implementors, who can
>choose none. Of course, the rules of J.7.1 do apply to any interrupt
>entries that are supported.
>
> > This is an important point to my current project, a real time sys-
> > tem with a very large number of interrupt handlers that is porting from
> > Ada 83 to Ada 95. The validated Ada compiler that we have selected does
> > not support J.7.1.
>
> Do they support the SP Annex? If they don't support the Systems
>Programming annex, it seems to me you need to choose another compiler.
>If they do claim to support the SP annex then you can use
>Ada.Interrupts.Reference to bind interrupts to task entries. (See C.3.2(22))
Actually, it looks to me like the second sentence of C.3.2(22)
blesses this compiler's implementation. It says, "This function
[Ada.Interrupts.Reference] raises Program_Error if attaching task
entries to interrupts ... is not supported."
I thought I had read the pertinent sections of the LRM quite
closely. I even searched around a bit to see if "permitted" had been
given a specialized, non-standard, meaning. Now, on rereading those
sections, I see that I missed a crucial point. 1.1.3(16) says that a
standard-conforming implementation must support each capability
_required_ by the core language. Since J.7.1(1) says, "Implementations
_are permitted_ ...," this is obviously not a requirement. All very
clear, once you see it. Duh!
Charlie
--
******
For an email response, my user name is "sampson" and my host
is "spawar.navy.mil".
^ permalink raw reply [relevance 1%]
* Re: Support of Task Interrupt Entries
@ 1998-10-08 0:00 2% ` Robert I. Eachus
1998-10-13 0:00 1% ` Charles H. Sampson
0 siblings, 1 reply; 133+ results
From: Robert I. Eachus @ 1998-10-08 0:00 UTC (permalink / raw)
In article <1998Oct7.183511.17020@nosc.mil> csampson@inetworld.net (Charles H. Sampson) writes:
> According to LRM 1.1.2(6), Annex J is part of the core language
> and must therefore be supported by any standard-conforming compiler.
> However, in J.7.1(1) we have, "Implementations are _permitted_ to allow
> the attachment of task entries to interrupts via the address clause."
> Does this mean that they are also permitted to disallow this?
The next paragraph should make it clear:
"The address of the task entry corresponds to a hardware interrupt
in an implementation-defined manner."
The standard can't reasonably define a set of addresses and
interrupts to support, so that is left to the implementors, who can
choose none. Of course, the rules of J.7.1 do apply to any interrupt
entries that are supported.
> This is an important point to my current project, a real time sys-
> tem with a very large number of interrupt handlers that is porting from
> Ada 83 to Ada 95. The validated Ada compiler that we have selected does
> not support J.7.1.
Do they support the SP Annex? If they don't support the Systems
Programming annex, it seems to me you need to choose another compiler.
If they do claim to support the SP annex then you can use
Ada.Interrupts.Reference to bind interrupts to task entries. (See C.3.2(22))
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 2%]
* interrupt Handler with EZ2LOAD
@ 1998-07-13 0:00 1% Ramon Costa-Castell�
0 siblings, 0 replies; 133+ results
From: Ramon Costa-Castell� @ 1998-07-13 0:00 UTC (permalink / raw)
Hye,
First of all let me tell that this is the first time
I'm working serously with ADA.
I'm using EZ2LOAD distribution of GNAT307,
and I'm trying to develop and device handler for
and ADC/DAC board (PCL-812PG).
To do this I'm following the device driver template
found in :
Concurrency in ADA
by Alan Burns and Andy Wellings
One of the most important step in this template is when then interrupt
is attached to
my interrupt handler thourgh the instruction:
pragma Attach_Handler(Handler, Int_Id);
The first parameter is the interrupt handler is the interrupt handler
address.
But what is it the second one ?
In the book it says that this is an interrupt identifier is defined in
Ada.Interrupts.Names package, but obviously my card
identifier is not defined there.
How should I define an interrupt identifier for my card,
How this number is related with the IRQ ?
(does anyone has a complete exemple for this platform with the same or
similar board ?)
Thank You in advance for the problems I will
cause.
Best Regards,
Ramon Costa-Castello
^ permalink raw reply [relevance 1%]
* Re: Interrupt handlers and exceptions
@ 1998-06-18 0:00 1% ` Robert I. Eachus
0 siblings, 0 replies; 133+ results
From: Robert I. Eachus @ 1998-06-18 0:00 UTC (permalink / raw)
In article <6lrurs$4fm$1@news2.apple.com> SamuelFigueroa@no_spam.usa.net (Samuel Figueroa) writes:
> Paragraph 7 of Section C.3 of the ARM says that exceptions cannot be
> propagated from interrupt handlers. Does this mean that an interrupt
> handler cannot raise something like Constraint_Error, and expect a task's
> exception handler to be invoked?
Exactly. Consider an interrupt to be like a task whose entries
have no body. If an exception would propagate out of an interrupt
handler, it is silently discarded, just like when an exception
propagates out of a task.
> Is there any way for an interrupt handler to cause a task's
> exception handler to be invoked, or to somehow cause the
> termination of the task that was executing when the interrupt
> occurred? (For the purposes of this discussion, one could envision
> an interrupt handler for page faults, in which one might want to
> raise some exception, and either have the program's exception
> handler take some action, or terminate the program itself.)
The key here is that you don't KNOW from a language point of view
which task caused a handler to be invoked. In the particular example
you use, the interrupt handler can determine which task caused it to
be invoked, but the process for doing that is outside the language.
(For example, on some hardware the interrupt stack is completely
separate from the user stack.)
If you had a situation where the interrupt was directly invoked by
a call, you could wrap the call in a procedure that checked a variable
for a return code, or you could even have the compiler provide another
package like Ada.Interrupts, where the handlers were functions that
provided return codes. However, in your page fault example, there is
noplace for that return code to go.
Having faced this problem in operating systems, the best solution
is to have the page fault handler always succeed. When you get close
to running out of (backing store) memory the interrupt should send a
message to the operating system, write to logs, etc., then return.
Any error handling when you are completely out of memory is, to use an
idiom from Dave Emery, a parachute that opens on impact. There is
nothing you can do then which is better than crashing the machine.
To clarify, the process which ate (almost) all of the memory may
not be the one that reaches for that final kilobyte. If you kill
processes to free space, eventually you will kill the right one, but
by then you will have either corrupted the disk or killed key
processes in the OS. So the choices are to do bad things, then crash,
or crash immediately and hope that the villain can be found in the
dump--if you have a tape to dump to.
Much better is to write the code for recovering from storage
exhaustion, figure out how much memory you need to run it, and
allocate that memory ahead of time. Of course the first thing that
job does, as part of the interrupt handler, is to turn off page fault
interrupts. So, yes, that means you have to have at least one page of
code resident, and then use that to carefully swap in the rest of the
necessary code from disk without using the virtual memory support. I
think I only know of three OSes that ever got this code to work right.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 1%]
* Re: help about handling interrupts
1998-04-07 0:00 1% ` Matthew Heaney
@ 1998-04-07 0:00 1% ` Jerry van Dijk
1 sibling, 0 replies; 133+ results
From: Jerry van Dijk @ 1998-04-07 0:00 UTC (permalink / raw)
Markus Kuhn (Markus.Kuhn@cl.cam.ac.uk) wrote:
: Igor Pascual Sagastagoitia wrote:
: >
: > I am learning ADA95 and I am searching for an example of attaching a
: > procedure when an interrupts rises.
: > I read the RM95 but I dont understand it too well because of my
: > language.
: > I am programming under GNAT 3.10 for a Linux platform.
: Like many of those hardware related questions, this is more a matter
: of your operating system than a matter of Ada. Therefore you should
: look into the Linux kernel first how interrupt handling is
: done there and not into the RM.
Unless Igor was refering to the package Ada.Interrupts, which is
AFAIK not yet supported under Linux, so it would be difficult to
show a working example anyway.
Jerry.
--
-- Jerry van Dijk | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
^ permalink raw reply [relevance 1%]
* Re: help about handling interrupts
@ 1998-04-07 0:00 1% ` Matthew Heaney
1998-04-07 0:00 0% ` Markus Kuhn
1998-04-07 0:00 1% ` Jerry van Dijk
1 sibling, 1 reply; 133+ results
From: Matthew Heaney @ 1998-04-07 0:00 UTC (permalink / raw)
In article <3529047A.44EE08B8@cl.cam.ac.uk>, Markus Kuhn
<Markus.Kuhn@cl.cam.ac.uk> wrote:
>Igor Pascual Sagastagoitia wrote:
>>
>> I am learning ADA95 and I am searching for an example of attaching a
>> procedure when an interrupts rises.
>> I read the RM95 but I dont understand it too well because of my
>> language.
>> I am programming under GNAT 3.10 for a Linux platform.
>
>Like many of those hardware related questions, this is more a matter
>of your operating system than a matter of Ada. Therefore you should
>look into the Linux kernel first how interrupt handling is
>done there and not into the RM.
>
>User processes cannot directly handle interrupts under Linux.
>If you want to write an interrupt handler yourself, you have to
>do this in a loadable kernel module. You can write loadable kernel
>modules in Ada just like you can do this in C. You have to call a
>kernel function at module load time that registers your Ada
>procedure as an interrupt handler, and then the Linux kernel
>will call your Ada procedure whenever this interrupt comes in.
I don't understand this response.
In Ada 95, you attach protected procedure of a protected object to an
interrupt. Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
dedicated to this very topic.
No, the OS doesn't make any difference. The syntax for specifying an
interrupt handler in Ada is the same for all platforms.
Basically, you declare a protected object, and use pragma Attach_Handler to
designate a protected procedure as the interrupt handler.
See also pragma Interrupt_Handler and package Ada.Interrupts.
^ permalink raw reply [relevance 1%]
* Re: help about handling interrupts
1998-04-07 0:00 1% ` Matthew Heaney
@ 1998-04-07 0:00 0% ` Markus Kuhn
0 siblings, 0 replies; 133+ results
From: Markus Kuhn @ 1998-04-07 0:00 UTC (permalink / raw)
Matthew Heaney wrote:
> Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
> >User processes cannot directly handle interrupts under Linux.
> >If you want to write an interrupt handler yourself, you have to
> >do this in a loadable kernel module. You can write loadable kernel
> >modules in Ada just like you can do this in C. You have to call a
> >kernel function at module load time that registers your Ada
> >procedure as an interrupt handler, and then the Linux kernel
> >will call your Ada procedure whenever this interrupt comes in.
>
> I don't understand this response.
>
> In Ada 95, you attach protected procedure of a protected object to an
> interrupt. Section 19.6, INTERRUPT HANDLING, in Norm Cohen's book is
> dedicated to this very topic.
>
> No, the OS doesn't make any difference. The syntax for specifying an
> interrupt handler in Ada is the same for all platforms.
>
> Basically, you declare a protected object, and use pragma Attach_Handler to
> designate a protected procedure as the interrupt handler.
>
> See also pragma Interrupt_Handler and package Ada.Interrupts.
Have you actually tried this under Linux? There is no way this
will work. Unless you do lots of special things (see the documentation
of how to compile a Linux loadable kernel module), GNAT will produce
an ELF output file that can only be started as a normal user
process. And normal user processes CAN NOT handle interrupts
directly. The sections in the RM you quoted have been intended
for compilers for embedded systems, where the Ada runtime library
does everything that on a PC is done by the operating system or
where there is a special real-time operating system used.
All this does not apply for a compiler that produces normal
Unix application programms.
The Ada standard does not make it unnecessary that you get
familiar with the mechanisms of your operating system if you
want to access the hardware directly, including handling
interrupts! One of the main purpose of a time-sharing operating
system is to prevent you from directly accessing the hardware.
The GNAT RM says:
"C.3.1(20-21): Protected Procedure Handlers
Whenever possible, the implementation should allow interrupt handlers to
be called directly by the hardware. Followed on any target where the
underlying operating system permits such direct calls."
Well, any Unix operating system I know is not a platform that
allows procedures in user processes to be called by hardware
interrupts. This has nothing to do with the programming language
used, this is an operating system issue.
Markus
--
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
^ permalink raw reply [relevance 0%]
* Re: type names (was Re: Child package: private type and IO)
1998-03-01 0:00 1% ` Matthew Heaney
@ 1998-03-04 0:00 1% ` Fergus Henderson
0 siblings, 0 replies; 133+ results
From: Fergus Henderson @ 1998-03-04 0:00 UTC (permalink / raw)
mheaney@ni.net (Matthew Heaney) writes:
>blaak@infomatch.com (Ray Blaak) wrote:
>
>>>Objects are the memory locations that store a value of a type.
>>
>>But you are using the word here as a type! (i.e. the set of things that are
>>memory locations that store values).
>
>No. You are confused about what a type is.
No, Ray Blaak is correct here.
>Let's begin by defining what we mean by a type. A type is defined as "A
>set of values, and a set of operations on those values." For example, I
>can define a type
>
>with the name "Integer"
>
>and the set of values
>
> ..., -3, -2, -1, 0, 1, 2, 3, ...
>
>and the set of operations
>
> +: Integer x Integer -> Integer
> -: Integer x Integer -> Integer
> *: Integer x Integer -> Integer
> /: Integer x Integer -> Integer
> =: Integer x Integer -> Boolean
>
>etc
Agreed.
Above, you used the word "Object" to refer to a type with the name "Object",
with the set of values being the different possible memory locations,
and with the set of operations being fetch, store, etc.
Below, you assume that "Object" and "Type" are mutually exclusive;
this is true in Ada, but there are other languages for which it is not true.
>A type refers to the set of values, NOT the objects. An object is a memory
>location inside a computer, that stores a value, a value we interpret as
>having a certain type. So when we declare an object,
>
>O : T;
>
>we're allocating a memory cell, and we're interpreting the value of the
>data in that cell as being of type T. The means the memory cell designated
>by object O will only contain certain values, and that only certain
>operations may be applied to the value in that cell.
>
>The memory cell designated by object O isn't really interesting. It's the
>data in that cell that's interesting. And it's the data in the cell that
>"is of type T," not the object itself.
No, the object itself "is [an lvalue] of type T".
To say otherwise would imply that objects are untyped, that
only values are typed, and that it is therefore possible to
store a value of any type in a given object. This is true
for some untyped languages, but it is not true in Ada.
>It is completely wrong to name a type "Object."
Well, I don't particularly like this convention much myself;
but I think "completely wrong" is overstating the case.
>Yes, it's true we often say "Object O has type T," but we really mean "O is
>the name of a memory cell containing a value of type T."
No. What we really mean is "O has type n<T>",
where "n<T>" is a (parametric) type whose operations
include "fetch" (syntactically implicit in Ada) and "store" (`:=').
"n<T>" might be better named "name<T>", "lvalue<T>", or even "object<T>".
>>>A type should be named using a noun phrase, such as
>>>type Singly_Linked_List is ...;
>>
>>I think that style of type names used really depends on if type names are
>>qualified with package names or not.
>
>Of course, a type name should NOT be qualified by a package name. A type
>name is a type name, and a package name is a package name. A package name
>is NOT a type name, and in no way participates in naming a type.
No, a package name surely does participate in naming a type,
for the type's fully-qualified name includes the name of the
package in which it is contained.
>A package is a namespace, and serves only to prevent clashes among
>similarly named types in an otherwise global namespace.
No, packages also provide encapsulation, not just namespace control.
>A package disambiguates type names, but it is itself not a type name.
Agreed.
>To use a package as part of the type, as in
>
>package P is
>
> type Object is ...;
>...
>end P;
>
>The_Object : P.Object;
>
>so that the "real" type name is "P.Object" only confuses the difference
>between a module and a type.
Nonsense!
The package name is P; the type name is P.Object
(though it can be abbreviated as Object, in certain contexts).
What's there to be confused about?
>>Having:
>>
>> package Linked_List is
>> type Linked_List is ...
>> end Linked_List;
>>
>>results in usage like:
>>
>> Employees : Linked_List.Linked_List;
>>
>>which I personally find irritating.
>
>The package is misnamed. A common idiom, and a very OLD idiom in the Ada
>community, is to use the plural of the type name as the package name,
Well, that doesn't help much -- now the usage is
Employees : Linked_Lists.Linked_List;
which is still just as ugly.
>I'm sorry you find this convention irritating. If so, then you can tell
>the language designers that they named the packages
>
>Ada.Characters
>Ada.Interrupts
>Ada.Interrupts.Names
>Ada.Exceptions
>Ada.Numerics
>Ada.Streams
>Ada.Strings
>Interfaces
>Interfaces.C.Pointers
>Interfaces.C.Strings
>System.Address_To_Access_Conversions
>System.Storage_Elements
>System.Storage_Pools
>
>incorrectly, and that the names they chose irritate you.
It's not a question of "correct" or "incorrect", it's a question
of style. The style chosen for the standard library strongly
encourages the use of `use', to avoid unnecessary redundancy in
names like `Ada.Strings.Unbounded.Unbounded_String'.
This is probably not such a bad thing
for the standard library, since experienced Ada programmers
will know the standard library well; but for more general settings,
encouraging the use of `use' may not be such a good idea.
Personally, I quite like the style of naming types `T',
e.g. `Ada.Strings.Unbounded.T'.
>> However a package like:
>>
>> package Linked_List is
>> type Object is ...
>> end Linked_List;
>>
>>results in usage like:
>>
>> Employees : Linked_List.Object;
>>
>>which reads better to me.
>
>It reads better to you because you are confused. You don't understand the
>difference between a module and a type.
Well, it reads better to me too, and I definitely do
understand the difference between a module and a type
(and I think Ray Blaak probably does too).
>If you don't believe that this is the Ada idiom, [...]
I think Ada is big enough for more than one idiom!
--
Fergus Henderson | Designing grand concepts is fun;
fjh@cs.mu.oz.au | finding nitty little bugs is just work.
http://www.cs.mu.oz.au/~fjh | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC 8B 3E 0F 01 E7 5D C4 3F
^ permalink raw reply [relevance 1%]
* Re: type names (was Re: Child package: private type and IO)
@ 1998-03-01 0:00 1% ` Matthew Heaney
1998-03-04 0:00 1% ` Fergus Henderson
0 siblings, 1 reply; 133+ results
From: Matthew Heaney @ 1998-03-01 0:00 UTC (permalink / raw)
In article <6dcio1$fvo$1@berlin.infomatch.com>, blaak@infomatch.com (Ray
Blaak) wrote:
>>Objects are the memory locations that store a value of a type.
>
>But you are using the word here as a type! (i.e. the set of things that are
>memory locations that store values).
No. You are confused about what a type is.
Let's begin by defining what we mean by a type. A type is defined as "A
set of values, and a set of operations on those values." For example, I
can define a type
with the name "Integer"
and the set of values
..., -3, -2, -1, 0, 1, 2, 3, ...
and the set of operations
+: Integer x Integer -> Integer
-: Integer x Integer -> Integer
*: Integer x Integer -> Integer
/: Integer x Integer -> Integer
=: Integer x Integer -> Boolean
etc
A type refers to the set of values, NOT the objects. An object is a memory
location inside a computer, that stores a value, a value we interpret as
having a certain type. So when we declare an object,
O : T;
we're allocating a memory cell, and we're interpreting the value of the
data in that cell as being of type T. The means the memory cell designated
by object O will only contain certain values, and that only certain
operations may be applied to the value in that cell.
The memory cell designated by object O isn't really interesting. It's the
data in that cell that's interesting. And it's the data in the cell that
"is of type T," not the object itself.
It is completely wrong to name a type "Object." There are 2 reasons:
1) It confuses the difference between a memory cell (which merely stores a
value) and the value itself. "Type" refers to a set of values, and to the
operations you can perform to manipulate those values.
"Type" does NOT refer to the memory cell containing a value. The term we
use to refer to a memory cell containing a value is "Object."
Yes, it's true we often say "Object O has type T," but we really mean "O is
the name of a memory cell containing a value of type T."
The name "T" is the name we've bound to the TYPE, not to the object. So
"T" is the name by which we refer to a set of values and a set of
operations. The name "O" is the name we bind to an OBJECT, not a type;
that is, "O" refers to a memory cell.
So when you name a type "Object," it's confusing because the term "Object"
refers to a memory cell. But a type is NOT a memory call, it's a set of
values.
2) It confuses the difference between a module and a type.
In Ada, module and type are ORTHOGONAL language features. This really
confuses a lot of people, and I have no idea why.
The Ada language construct for a module is a package. A package is NOT a
type. A package which exports a type declaration merely demarcates the
"primitive" operations of a type among all the operations that have the
type as a parameter or return value.
The Ada language construct for a type comprises 2 parts:
a) a type declaration, which binds a name to the type, specifies its class,
and specifies the set of values as a range (or implied range).
b) subprogram declarations, which take parameters of the type, or return
values of the type.
Consider this example:
package P is
type T is range 1 .. 4;
procedure Op1 (O : T);
function Op2 (F : Float) return T;
end P;
with P;
package Q is
procedure Op3 (O : P.T);
end Q;
Let's analyze this piece by piece.
The declaration
type T is range 1 .. 4;
a) specifies the type class, here Integer
b) specifies the set of values (having the Integer class) for the type,
here 1, 2, 3, 4
c) binds a name to the type, here "T"
d) specifies primitive operations that are "predefined" for this class of
type, here
+: T x T -> T
+: T -> T
-: T x T -> T
-: T -> T
=: T x T -> Boolean
etc
The operations Op1 and Op2 are also "primitive" operations of the type
whose name is T. We say they are "user-defined," in contrast to the
"predefined" primitive operations as addition, subtraction, etc.
They are primitive because they take a parameter of the type (Op1) and
return a value of the type (Op2), and they are declared in the same package
(P) as the type declaration.
By contrast, the operation Op3 is NOT a "primitive" operation of the type
whose name is T. Even though Op3 takes a parameter of type P.T, it is not
primitive because it is not declared in the same package as the type
declaration.
We make the distinction between primitive and non-primitive operations
because only the former are "inherited" during a derivation. For example,
with P;
package R is
type NT is new P.T;
procedure Op4 (O : NT);
end R;
The primitive operations of type R.NT are "+", "-", "*", "/", etc, and Op1,
Op2, and Op4. Op1 and Op2 (and addition, etc) are inherited from T, and a
new primitive operation, Op4, was added too.
Note the Op3 is NOT an operation of type NT, because Op3 is not a primitive
operation of type T.
And by the way, while I'm on the subject, a "class" in other languages as
C++, Eiffel, and Java maps to an Ada tagged type. It does NOT map to an
Ada package. To convert the C++ declaration
class Stack ...;
to Ada, you have to do this:
package Stacks is
type Stack is ...; -- this is the "class Stack"
>>So when refer to an object's type as "Object," then how do you refer to the
>>object?
>
>Perhaps as An_Object, or The_List, or The_Set, or even Value. An even better
>approach is to use names from the domain, like maybe Employees, or
>Active_Flights, or Current_Account.
An an even better approach is
Account : Bank_Account;
File : Text_File;
Mode : File_Mode;
>>A type should be named using a noun phrase, such as
>>type Singly_Linked_List is ...;
>
>I think that style of type names used really depends on if type names are
>qualified with package names or not.
Of course, a type name should NOT be qualified by a package name. A type
name is a type name, and a package name is a package name. A package name
is NOT a type name, and in no way participates in naming a type.
A package is a namespace, and serves only to prevent clashes among
similarly named types in an otherwise global namespace. A package
disambiguates type names, but it is itself not a type name.
To use a package as part of the type, as in
package P is
type Object is ...;
...
end P;
The_Object : P.Object;
so that the "real" type name is "P.Object" only confuses the difference
between a module and a type.
>Having:
>
> package Linked_List is
> type Linked_List is ...
> end Linked_List;
>
>results in usage like:
>
> Employees : Linked_List.Linked_List;
>
>which I personally find irritating.
The package is misnamed. A common idiom, and a very OLD idiom in the Ada
community, is to use the plural of the type name as the package name, as in
generic
...
package Stacks
type Stack is ...;
...;
end Stacks;
I'm sorry you find this convention irritating. If so, then you can tell
the language designers that they named the packages
Ada.Characters
Ada.Interrupts
Ada.Interrupts.Names
Ada.Exceptions
Ada.Numerics
Ada.Streams
Ada.Strings
Interfaces
Interfaces.C.Pointers
Interfaces.C.Strings
System.Address_To_Access_Conversions
System.Storage_Elements
System.Storage_Pools
incorrectly, and that the names they chose irritate you.
> However a package like:
>
> package Linked_List is
> type Object is ...
> end Linked_List;
>
>results in usage like:
>
> Employees : Linked_List.Object;
>
>which reads better to me.
It reads better to you because you are confused. You don't understand the
difference between a module and a type.
>Note this does not imply that all types should be
>called "Object" either. With this example in particular, it is natural to work
>with objects and references to objects:
>
> type Handle;
> type Object is record
> ...
> Next : Handle;
> Previous : Handle;
> end record;
> type Handle is access Object;
This is another horrible naming convention. The term "handle" loosely
refers to a pointer-to-pointer. Handles are used in memory allocation
schemes to allow you to relocate chunks of memory to reduce fragmentation
(Mac programmers will know what I'm talking about).
The Ada idiom for a name of an access type is T_Access, for example
type Stack is tagged private;
type Stack_Access is access all Stack;
type Stack_Class_Access is access all Stack'Class;
Do not name an access type Handle, because it is not a handle.
Do not name an access type Pointer, because access objects are not
pointers. If they were, then Jean Ichbiah would have chosen the keyword
"pointer" instead of "access," right?
If you don't believe that this is the Ada idiom, then make note of the
names of the types
Ada.Text_IO.File_Access
Ada.Strings.Unbounded.String_Access
Ada.Streams.Stream_IO.Stream_Access
>then one can say things like:
>
> Manager_Subset : Linked_List.Handle;
>
>which is really clear (to me, of course :-).
>
>If one uses use clauses a lot, then of course more descriptive type names are
>better:
>
> data : Linked_List;
Ahh, that's more like it.
Here's an example from a library I'm writing:
package ACL.Lists is ...;
package ACL.Lists.Single is
type Single_List is private;
...;
end ACL.Lists.Single;
package ACL.Lists.Double is
type Double_List is private;
...
end ACL.Lists.Double;
Here's another example you often find in tutorials:
package Bank_Accounts is
type Bank_Account is abstract tagged limited private;
...;
end Bank_Accounts;
package Bank_Accounts.Checking is
type Checking_Account is new Bank_Account with private;
...;
end Bank_Accounts.Checking;
package Bank_Accounts.Savings is
type Savings_Account is new Bank_Account with private;
...
end Bank_Accounts.Savings;
>>A good guideline is, Be consistant with the style in the reference manual.
>>There are NO types in the RM named "Object," so there should be none in
>>your code either.
>
>One shouldn't be so afraid to do something different, if one thinks it is an
>improvement. How else can standards get better?
A bunch of guys from all over the planet with PhDs in computer science
designed the language, and somehow they didn't come up with your "better
idea." Telling, isn't it? If you think it is an improvement, perhaps that
is because there is knowledge that you don't have.
^ permalink raw reply [relevance 1%]
* Help on Interrupt Handlers
@ 1998-02-13 0:00 1% Redmond Urbino
0 siblings, 0 replies; 133+ results
From: Redmond Urbino @ 1998-02-13 0:00 UTC (permalink / raw)
To: adasupport
I am using Object Ada on NT 4.0
Suppose I have a process A which attaches a handler W to interrupt X.
It uses Ada.Interrupts.Attach_Handler.
Now I have another process B, who wants process A to run W.
How do I raise interrupt X such that it would be caught by process A?
In the unix version, we simply used the kill function with A and W as
parameters. I can't find out how to do this in win32 or in object ada.
Any help would be greatly appreciated.
^ permalink raw reply [relevance 1%]
* Re: Aonix bugs
@ 1997-04-17 0:00 1% ` John Harbaugh
0 siblings, 0 replies; 133+ results
From: John Harbaugh @ 1997-04-17 0:00 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]
Stephen Leake wrote:
>
> S�bastien Auclair wrote:
> >
> > ( French if possible )------- ( French if possible )--------- ( French
> > if possible )
> >
> > I'd like to know if their's anyone who could explain me why my
> > "ObjectAda for Windows V7.0.232 from Aonix" doesn't seems to function
> > properly.
>
> I have Aonix at home, and I'm at work now, so I don't know exactly which
> version I have. However, there is a LARGE patch file on the Aonix web
> site, that fixed lots of bugs when I downloaded and installed it. You
> can download it from:
>
> http://www.aonix.com/Support/ada_index.html
>
> >
> > Is there any other Ada 95 compiler available to work with.
> >
>
> gnat works well under Windows 95, although I haven't used it for much
> actual Win32 coding yet. gnat didn't link the first time I tried, and
> Aoniz did, so I gave up on gnat. However, gnat has MUCH better error
> messages for first-time-thru code, so I run all my code thru gnat till
> it compiles, then link with Aonix.
>
> Assuming Aonix is listening, I'll post my pet peeve with error messages:
>
> procedure test is
> procedure foo (A : in Integer; B : in Float);
>
> begin
> foo (1.0, 2);
> end;
>
> This gives an error message "error in procedure call"; it does NOT say
> that parameter 1 should be Integer, but is a real type. gnat gives:
>
> test.adb:4:09: expected type "Standard.integer"
> test.adb:4:09: found type universal real
> gnatmake: "test.adb" compilation error
>
> It is amazing how much nicer Ada feels when you get the gnat message
> instead of the Aonix one (should gnat be capitalized here?).
>
> > Thanks in advance...
>
> You're welcome
> >
> > S�bastien Auclair
> > jg791569@er.uqam.ca
>
> --
> - Stephe
I have been struggling to install the U2A and U2B patch files. It turns
out that all unzip routines are not created equal. Specifically, do not
use PKUnzip! I was directed by Aonix tech. support to use WinZip95.
This finally installed the patch. In many cases, the patch is an
improvement - delay until no longer raises an NYI exception, and you can
call Ada.Interrupts routines without raising exceptions.
However, in some cases, Aonix has traded one set of bugs for another.
For example, running build on a unit requiring recompilation generates
an illegal operation warning, rather than an object file. Also, while
you can create projects in any directory, attempting to link with them
invokes the MS linker which dies with a fatal link error LLNll04: cannot
open file "C:\Ada95\New". The only projects wich now work are those
created in the ObjectAda directory.
ObjectAda is getting better and will be a really nice product, maybe by
V7.1.
^ permalink raw reply [relevance 1%]
* Ada interrupts
@ 1993-01-06 18:39 1% James Mac Leod
0 siblings, 0 replies; 133+ results
From: James Mac Leod @ 1993-01-06 18:39 UTC (permalink / raw)
I am looking for information on how to write interrupts in
Meridian Ada 4.1.4 for serial communications on a 286 PC. I am familiar
with the 8250 UART chip in the 286 and how to initialize it (i.e. the baud
rate, parity, etc). The problem is how the Ada tasks work. I have tried
using entry clauses to both interrupt C and B but neither appear to work.
I have also tried saving the DOS interrupt vector using DOS function call
250C and restoring using 350C. Are these functions only for interrupt C?
If so what are the function calls for interrupt B? A similar program
written in Alsys Ada works on an XT which uses interrupt C. The 286 has a
different serial port address so maybe it should use interrupt B. The port
is at address 2F8H. Any body give me a hand? It would be greatly
appreciated.
Jamie
My EMAIL address is: jmacleod@fox.nstn.ns.ca
Micronav International Inc
P.O.Box 1523 / 104 Marine Drive
Sydport Industrial Park,
Sydney, N.S. Canada B1P 6R7
Tel: 902-564-8833 Fax: 902-564-8764
^ permalink raw reply [relevance 1%]
Results 1-133 of 133 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1993-01-06 18:39 1% Ada interrupts James Mac Leod
1997-04-07 0:00 Aonix bugs S�bastien Auclair
1997-04-08 0:00 ` Stephen Leake
1997-04-17 0:00 1% ` John Harbaugh
1998-02-13 0:00 1% Help on Interrupt Handlers Redmond Urbino
1998-02-14 0:00 Child package: private type and IO johnjohn
1998-02-17 0:00 ` sparre
1998-02-27 0:00 ` Matthew Heaney
1998-03-01 0:00 ` type names (was Re: Child package: private type and IO) Ray Blaak
1998-03-01 0:00 1% ` Matthew Heaney
1998-03-04 0:00 1% ` Fergus Henderson
1998-04-06 0:00 help about handling interrupts Igor Pascual Sagastagoitia
1998-04-06 0:00 ` Markus Kuhn
1998-04-07 0:00 1% ` Matthew Heaney
1998-04-07 0:00 0% ` Markus Kuhn
1998-04-07 0:00 1% ` Jerry van Dijk
1998-06-12 0:00 Interrupt handlers and exceptions Samuel Figueroa
1998-06-18 0:00 1% ` Robert I. Eachus
1998-07-13 0:00 1% interrupt Handler with EZ2LOAD Ramon Costa-Castell�
1998-10-07 0:00 Support of Task Interrupt Entries Charles H. Sampson
1998-10-08 0:00 2% ` Robert I. Eachus
1998-10-13 0:00 1% ` Charles H. Sampson
1998-10-14 0:00 2% ` Robert I. Eachus
1999-02-17 0:00 Connecting To Interrupts Using Protected Procedures Marin David Condic
1999-02-17 0:00 ` Pat Rogers
1999-02-18 0:00 2% ` Pat Rogers
1999-02-18 0:00 1% ` Marin David Condic
1999-02-23 0:00 Ada83 and Ada95 interrupt handling Armin
1999-03-05 0:00 2% ` Robert A Duff
1999-05-19 0:00 2% Interrupt problem in GNAT Joerg Kienzle
[not found] <1999Jul7.160434.10447@nosc.mil>
1999-07-08 0:00 ` Interrupt Handler Problems Marin David Condic
1999-07-09 0:00 1% ` Charles H. Sampson
1999-09-08 0:00 1% capturing parallel port interrupt? Josh Highley
1999-09-09 0:00 0% ` Tarjei Jensen
1999-10-14 0:00 1% Interrupt Handlers using GNAT-VxWorks? John Arnsparger
1999-10-14 0:00 0% ` Rick Stikkers
1999-10-15 0:00 2% ` Martin Gangkofer
1999-10-16 0:00 2% ` Toshitaka Kumano
1999-10-18 0:00 0% ` Robert Dewar
2000-01-06 0:00 1% question about COM2 Alexander Van Hecke
2000-01-07 0:00 0% ` more information on OS and compiler Alexander Van Hecke
2000-03-15 0:00 Announcing GNAT version 3.13 Robert Dewar
2000-03-15 0:00 1% ` Robert Dewar
2000-08-08 0:00 1% ANNOUNCEMENT - GNAT 3.13p availability Bernard Banner
2000-12-15 18:24 How to lock keys Freelancer
2000-12-15 23:56 2% ` Alexander Antonenko
2001-01-05 12:28 2% Interrupts service Szygula
2001-01-05 13:20 0% ` Marc A. Criley
2001-03-13 11:09 Handling signals in ADA Tomas Hlavaty
2001-03-15 18:48 1% ` David Starner
2001-03-16 17:17 2% ` Robert A Duff
2001-03-15 22:05 ` Florian Weimer
2001-03-16 1:27 2% ` David C. Hoos, Sr.
2001-03-16 1:48 1% ` Jeffrey Carter
2001-03-16 21:06 1% ` Florian Weimer
2001-03-17 1:00 0% ` David C. Hoos, Sr.
2001-03-16 3:06 2% ` (null)
2001-11-02 14:10 3% no Ada.Interrupts? Zebylon
2001-11-02 15:12 2% ` Wes Groleau
2001-11-02 16:43 2% ` Jacob Sparre Andersen
2001-12-18 16:28 Use of entries using Ravenscar Jimmy Dubén
2001-12-20 7:54 ` Jimmy Dubén
2001-12-20 8:46 ` martin.m.dowie
2001-12-20 13:52 2% ` Jimmy Dubén
2002-01-31 2:49 1% ACT announces availability of GNAT 3.14p Robert Dewar
2002-07-31 2:54 implementation approach Mark
2002-07-31 13:59 2% ` SteveD
2002-10-11 18:54 1% On-Screen Elapsed Time Display? Dr Nancy's Sweetie
2002-10-11 19:32 0% ` Jeffrey Carter
2002-12-16 21:07 1% ANNOUNCE: Free GNU Ada Run-Time Book (version 1.0) javiermirandag
2003-01-29 15:04 tasking programs built with GNAT insensitive to SIGTERM Oliver Kellogg
2003-01-29 21:54 ` Mark Johnson
2003-02-04 19:55 1% ` Craig Carey
2003-02-22 22:31 2% strange execution error alfonso acosta
2004-01-03 18:52 2% gnat/linux:setitimer TIlman Glotzner
2004-01-05 16:18 ` gnat/linux:setitimer Mark H Johnson
2004-01-15 3:35 2% ` gnat/linux:setitimer Tilman Glotzner
2004-03-25 17:03 1% Signal handler blocks proteced type Lutz Donnerhacke
2004-03-25 17:05 1% Lutz Donnerhacke
2004-03-26 10:00 1% ` Lutz Donnerhacke
2004-06-16 9:29 SIGINT problem under LINUX Radek Kotowicz
2004-06-16 11:13 2% ` Jeff C,
2004-11-24 12:11 1% system interrupt handler programming on a PC under windows Adrien Plisson
2004-11-24 14:55 0% ` Steve
2005-01-17 12:26 1% Catching Ctrl-C SIGINT Christopher Broeg
2005-01-17 14:07 1% Christopher Broeg
2005-01-17 14:13 1% Christopher Broeg
2005-06-15 15:39 1% Interrupt handler seems not to be called in GNAT 3.15p Thorsten
2005-06-16 6:52 0% ` David C. Hoos, Sr.
2005-06-16 8:03 1% ` Egil H. H�vik
2005-06-16 9:36 0% ` Thorsten
2005-08-10 16:01 4% problem with ada.interrupts evangeli
2005-08-10 18:00 1% ` Robert A Duff
2005-08-10 18:19 1% ` jimmaureenrogers
2005-08-25 12:25 2% ` Thierry Pirot
2008-05-27 11:19 Access procedure to pointer Sébastien
2008-05-27 12:05 ` Ludovic Brenta
2008-05-27 17:45 ` Sébastien
2008-05-27 18:26 ` Dmitry A. Kazakov
2008-05-28 9:06 ` Sébastien
2008-05-28 10:13 1% ` Jean-Pierre Rosen
2008-05-28 14:57 0% ` Sébastien
2008-05-28 15:26 1% ` Jean-Pierre Rosen
2008-05-28 21:36 2% ` Adam Beneschan
2008-05-28 23:02 0% ` Sebastien Morand
2008-05-29 0:58 ` Jeffrey R. Carter
2008-05-29 9:06 ` Sébastien
2008-05-29 20:20 1% ` Jeffrey R. Carter
2008-05-28 15:29 2% ` Sébastien
2008-05-28 17:00 0% ` Simon Wright
2009-05-15 16:26 2% Interrupt handler and Ada.Real_Time.Timing_Events Reto Buerki
2009-05-15 16:54 0% ` Adam Beneschan
2009-05-15 16:56 0% ` Ludovic Brenta
2009-05-16 11:05 0% ` Timing Example was " anon
2009-08-05 19:58 Ada and (SIGTERM?) Tomek Walkuski
2009-08-06 1:06 ` Adam Beneschan
2009-08-06 19:30 ` Tomek Wałkuski
2009-08-06 19:57 1% ` Jeffrey R. Carter
2009-08-06 20:00 1% ` okellogg
2010-04-12 4:12 How to exit a loop with keyboard input Jerry
2010-04-12 10:36 ` Jerry
2010-04-12 13:59 1% ` John McCormick
2010-04-13 19:38 0% ` Jerry
2010-10-26 15:52 2% GNAT and SIGTERM (Linux x86_64) Bryan
2010-10-26 16:36 0% ` Yannick Duchêne (Hibou57)
2010-10-27 7:43 7% ` Ludovic Brenta
2011-03-07 9:34 ACCESS TO SYSTEM VARIABLES Emile8
2011-03-07 11:47 ` Georg Bauhaus
2011-03-07 20:14 ` Emile8
2011-03-07 21:32 ` Peter C. Chapin
2011-03-08 17:13 ` Emile8
2011-03-09 18:59 2% ` Emile8
2011-12-10 20:43 2% Interrupts handling in ADA Ada @ BRL
2011-12-10 22:09 0% ` Niklas Holsti
2011-12-11 9:23 ` Dmitry A. Kazakov
2011-12-13 13:11 1% ` Ada BRL
2011-12-12 3:19 0% ` anon
2011-12-13 13:31 0% ` Ada BRL
2013-03-18 20:59 Runtime startup code for the GNAT Runtime...and a bit of humble pie Diogenes
2013-03-19 0:07 ` Diogenes
2013-03-19 10:04 ` Brian Drummond
2013-03-19 12:51 ` Simon Clubley
2013-03-19 23:13 ` Brian Drummond
2013-03-20 0:54 ` Simon Clubley
2013-03-20 11:50 ` Brian Drummond
2013-03-20 13:18 ` Simon Clubley
2013-03-26 11:04 ` Brian Drummond
2013-03-26 22:38 ` Simon Clubley
2013-03-27 11:34 1% ` Brian Drummond
2013-03-27 14:38 0% ` Simon Clubley
2013-03-27 22:58 0% ` Brian Drummond
2014-08-26 22:38 STM32F4 Discovery, communication and libraries roy.emmerich
2014-08-27 13:08 ` Dennis Lee Bieber
2014-08-27 16:03 ` Roy Emmerich
2014-08-28 1:48 ` Dennis Lee Bieber
2014-08-28 10:12 ` Roy Emmerich
2014-08-28 13:00 ` Dmitry A. Kazakov
2014-08-28 16:28 ` Mike Silva
2014-08-28 20:09 ` Dmitry A. Kazakov
2014-08-28 21:17 ` Niklas Holsti
2014-08-29 7:41 ` Dmitry A. Kazakov
2014-08-29 16:31 ` Niklas Holsti
2014-08-29 16:47 ` Roy Emmerich
2014-08-29 19:41 1% ` Niklas Holsti
2014-08-30 22:00 0% ` Roy Emmerich
2015-01-20 22:34 1% Use of expression function in protected type Simon Wright
2015-01-27 16:09 2% gnat ARM - predefined packages RasikaSrinivasan
2015-01-27 16:49 0% ` Bob Duff
2015-01-27 16:49 0% ` Simon Wright
2015-01-27 16:50 ` Simon Wright
2015-01-27 18:29 ` RasikaSrinivasan
2015-01-27 21:55 ` Simon Wright
2015-01-28 7:03 ` Egil H H
2015-01-28 7:52 ` Simon Wright
2015-01-28 8:41 ` J-P. Rosen
2015-01-28 13:11 ` Simon Wright
2015-01-28 17:30 1% ` RasikaSrinivasan
2015-03-03 7:45 GNAT stm34f4 zfp question jan.de.kruyf
2015-03-03 9:20 ` jan.de.kruyf
2015-03-03 17:15 ` Patrick Noffke
2015-03-04 15:22 ` jan.de.kruyf
2015-03-04 18:28 ` Simon Wright
2015-03-18 17:58 2% ` Simon Wright
2015-05-27 19:38 longest path through a task jan.de.kruyf
2015-05-27 20:09 ` Niklas Holsti
2015-05-28 6:54 ` jan.de.kruyf
2015-05-28 16:37 ` Simon Wright
2015-05-28 17:43 ` jan.de.kruyf
2015-05-28 17:52 1% ` Simon Wright
2015-05-28 18:12 0% ` jan.de.kruyf
2015-06-20 18:38 1% GNAT GPL 2015 Troubles RasikaSrinivasan
2015-06-20 19:31 ` Simon Wright
2015-06-21 9:55 ` Stephen Leake
2015-06-21 11:13 ` Simon Wright
2015-06-21 16:00 ` RasikaSrinivasan
2015-06-21 16:21 1% ` Simon Wright
2015-06-23 14:07 0% ` Stephen Leake
2015-06-23 17:07 0% ` Simon Wright
2016-02-07 22:45 1% ANN: Cortex GNAT RTS 20160207 Simon Wright
2016-03-14 17:42 1% ANN: Cortex GNAT RTS 20160314 Simon Wright
2016-05-22 14:20 1% ANN: Cortex GNAT RTS 20160522 Simon Wright
2016-06-25 2:40 1% GNAT bug with protected procedure interrupt handler Daniel King
2016-10-11 17:02 1% Precondition on protected entry Simon Wright
2016-10-12 16:07 1% ` Stephen Leake
2017-07-09 6:54 How to check syntax with GNAT? Victor Porton
2017-07-13 5:47 1% ` Simon Wright
2017-09-16 20:47 2% how to use "in out" for the "self" parameter in a function in a protected object? Frank Buss
2017-10-12 15:16 2% Interrupts & Ravenscar Simon Wright
2017-10-21 1:16 0% ` Randy Brukardt
2017-11-15 14:28 Ada.Real_Time.Time_Last Simon Wright
2017-11-15 20:03 ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-17 9:20 ` Ada.Real_Time.Time_Last Simon Wright
2017-11-17 21:39 ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-18 13:06 ` Ada.Real_Time.Time_Last AdaMagica
2017-11-18 13:18 ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-18 14:15 ` Ada.Real_Time.Time_Last Jeffrey R. Carter
2017-11-18 15:24 1% ` Ada.Real_Time.Time_Last Niklas Holsti
2017-11-18 22:20 0% ` Ada.Real_Time.Time_Last Robert A Duff
2017-11-19 10:50 1% ` Ada.Real_Time.Time_Last Niklas Holsti
2019-01-29 3:39 Ada.Interrpts.Names lyttlec
2019-01-29 10:29 ` Ada.Interrpts.Names Simon Wright
2019-01-29 13:09 2% ` Ada.Interrpts.Names Simon Wright
2019-01-29 14:31 1% ` Ada.Interrpts.Names Simon Wright
2019-02-25 6:51 Ada in command / control systems Jesper Quorning
2019-02-25 8:24 ` Dmitry A. Kazakov
2019-02-25 13:50 ` russ lyttle
2019-02-25 15:25 ` Simon Wright
2019-02-25 19:21 ` russ lyttle
2019-02-26 4:50 ` J-P. Rosen
2019-02-26 15:50 1% ` Simon Wright
2019-02-26 22:10 0% ` lyttlec
2019-02-26 22:39 0% ` Niklas Holsti
2019-04-08 2:13 Understanding GNAT Bare Board Run-time for Cortex-M Daniel Way
2019-04-08 7:46 1% ` Niklas Holsti
2020-04-19 23:53 How to emulate multiple exports Jere
2020-04-20 6:52 2% ` Jeffrey R. Carter
2020-04-20 20:51 0% ` Jere
2021-03-28 19:41 1% Elaboration code, aggregates Simon Wright
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox