question re Ada equivalent of C function

question re Ada equivalent of C function

[David Fisher]

Sorry if this is a bit basic, but learning Ada on one's own can be, er,
challenging.

What are the Ada equivalents of the C functions, inp and outp, used to
read a byte from or send one to a memory address?

Thanks!

David Fisher
Fisher Research Corporation

Re: question re Ada equivalent of C function

[Brian Rogoff]

On Sat, 21 Feb 1998, David Fisher wrote:
> Sorry if this is a bit basic, but learning Ada on one's own can be, er,
> challenging.

You're never alone on comp.lang.ada! :-)

> What are the Ada equivalents of the C functions, inp and outp, used to
> read a byte from or send one to a memory address?

Well, that depends. If you just want to reuse some C routines, I'd suggest 
that you use Interfaces.C and just reuse them. Otherwise, you'll want to 
look at the System and System.Storage_Elements packages for what you want. 
If you want to access a Character at some memory address, say
16#CAFEBABE#, you'd do something like this (boilerplate omitted)

...
Mem_Addr : constant Address := To_Address(16#CAFEBABE#);
Mem_Mapped_Char : Character;
for Mem_Mapped_Char'Address use Mem_Addr;
...

which is surprisingly self-explanatory.

-- Brian

Re: question re Ada equivalent of C function

[Robert Dewar]

Brian says

<<Well, that depends. If you just want to reuse some C routines, I'd suggest
that you use Interfaces.C and just reuse them. Otherwise, you'll want to
look at the System and System.Storage_Elements packages for what you want.
If you want to access a Character at some memory address, say
16#CAFEBABE#, you'd do something like this (boilerplate omitted)

...
Mem_Addr : constant Address := To_Address(16#CAFEBABE#);
Mem_Mapped_Char : Character;
for Mem_Mapped_Char'Address use Mem_Addr;
...

which is surprisingly self-explanatory.
>>

This may be self-explanatory, but has nothing at all to do with the inp
and outp routines, which are accesses to the IO/space (and result in
generation of IN/OUT instructions). Brian was mislead here by the
rather confusing wording of the original question.

Note that a C programmer can do this kind of reading directly from a 
memory address even more easily than an Ada programmer, and certainly
does not need library routines for doing it :-) :-)

Re: question re Ada equivalent of C function

[Brian Rogoff]

On 21 Feb 1998, Robert Dewar wrote:
> This may be self-explanatory, but has nothing at all to do with the inp
> and outp routines, which are accesses to the IO/space (and result in
> generation of IN/OUT instructions). Brian was mislead here by the
> rather confusing wording of the original question.

Yes, I should have asked for clarification. I mapped the question to 
"How do you read and write to integer valued addresses in Ada" which 
isn't at all what was being asked. 

> Note that a C programmer can do this kind of reading directly from a 
> memory address even more easily than an Ada programmer, and certainly
> does not need library routines for doing it :-) :-)

That should have been a clue! 

Well David, as you can see free advice is worth every penny!

-- Brian

Re: question re Ada equivalent of C function

[Jerry van Dijk]

> > What are the Ada equivalents of the C functions, inp and outp, used to
> > read a byte from or send one to a memory address?

> Mem_Addr : constant Address := To_Address(16#CAFEBABE#);
> Mem_Mapped_Char : Character;
> for Mem_Mapped_Char'Address use Mem_Addr;

Careful, that would depend on the processor. On a x86 the I/O ports
are not in the regular address space, that's why C compilers for PC's
often have a separate library functions to access them.

If the original question was indeed refering to a PC environment, then
the answer will depend on the specific compiler and OS used.

Jerry,

Re: question re Ada equivalent of C function

[David Fisher]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

> Careful, that would depend on the processor. On a x86 the I/O ports
> are not in the regular address space, that's why C compilers for PC's
> often have a separate library functions to access them.
>
> If the original question was indeed refering to a PC environment, then
> the answer will depend on the specific compiler and OS used.

The hardware will be a Pentium; the OS will be Linux, the compiler
(presumably) GNAT. Thing is, development is being done with Aonix 7.1 on NT4.

David Fisher
Fisher Research Corporation
frc@stellar1.com

[-- Attachment #2: Card for David Fisher --]
[-- Type: text/x-vcard, Size: 271 bytes --]

begin:          vcard
fn:             David Fisher
n:              Fisher;David
org:            Fisher Research Corporation
email;internet: frc@stellar1.com
title:          Chief Engineer
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard

Re: question re Ada equivalent of C function

[Simon Wright]

David Fisher <frc@stellar1.com> writes:

> The hardware will be a Pentium; the OS will be Linux, the compiler
> (presumably) GNAT.

Check out "A Data Acquisition System For Linux", Dr Dobb's Journal Feb
1998, p.62. You'll need to use "pragma Import" to specify inb() etc.

>                    Thing is, development is being done with Aonix 7.1 on NT4.

Hmm, your (your company's) choice I guess!

Re: question re Ada equivalent of C function

[Simon Wright]

Simon Wright <simon@pogner.demon.co.uk> writes:

> David Fisher <frc@stellar1.com> writes:
> 
> > The hardware will be a Pentium; the OS will be Linux, the compiler
> > (presumably) GNAT.
> 
> Check out "A Data Acquisition System For Linux", Dr Dobb's Journal Feb
> 1998, p.62. You'll need to use "pragma Import" to specify inb() etc.

Actually, inb() and friends seem to be macros. You may know how to use
the "assembler" features of Ada, but if this seems daunting (as it
does to me) you might proceed as follows:

Not at all clear from <asm/io.h> what the type of "port" should be,
but you'll need something like

(C, compiled with at least -O to get gcc to generate the outb instruction)
#include <asm/io.h>
void outb_wrapper(unsigned char val, int port)
{
  outb(val, port);
}

(Ada)
procedure Outb (Val : Interfaces.C.Unsigned_Char; Port : Interfaces.C.Int);
pragma Import (C, Outb, "outb_wrapper");

NB also I've no idea what you may need to do if the code needs to
execute as a driver(*). This would be quite problematic in Ada, I
suspect, unless you can avoid the need for elaboration (I suppose you
could get this to work as the driver initializes? come to think, all
you have to do is call adainit(), adafinal()??? anyone else tried
this?)

(*) In most Unixes you would expect to _have_ to access IO from the
kernel, ie in a driver. The referenced DDJ article says it's possible
from user mode if you're root.

Re: question re Ada equivalent of C function

[Jerry van Dijk]

Talking about accessing I/O addresses,

David Fisher <frc@stellar1.com> schreef in artikel
<34EF6CC6.28EF2D4A@stellar1.com>...

> The hardware will be a Pentium; the OS will be Linux, the compiler
> (presumably) GNAT. Thing is, development is being done with Aonix 7.1 on
NT4.

As both Linux and NT are real operating systems, neither will allow you to
directly
access an IO port from a user program. By messing around with rights and
such
you might be able to pull it off using inline-assembly tricks, but at this
low level
both Linux vs NT and GNAT vs OA are incompatible.

The best solution would be if you would have a device driver for the I/O
you are
trying to access, one for NT and one for Linux.

Unless, of course, you are not trying to access any particular device
connected
to these I/O ports, but need to access I/O ports related to the machine's
operation
itself. Then there might be OS facilities to do this.

As usual when you work so close to the machine, it all depends...

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | email: jdijk@acm.org

Re: question re Ada equivalent of C function

[Robert Dewar]

<<As both Linux and NT are real operating systems, neither will allow you to
directly
access an IO port from a user program. By messing around with rights and
such
you might be able to pull it off using inline-assembly tricks, but at this
low level
both Linux vs NT and GNAT vs OA are incompatible.

>>

Although this may be a valid description of restrictions in NT and Linux,
it is by no means a necessary restriction. In OS/2, you can use inp and
outp from a protected mode program if you use a .DEF file to declare
the IOSEG segment that the run-time library uses to perform
input/output to the port. The code for the segment must be marked
with the IOPL keyword in the .DEF file. FOr more details, have a look
at the OS/2 documentation, or look in the Microsoft C Run-Time
Library Reference document (an excellent source for all sorts of
information on C-callable routines and their compatibility across
systems).

I am not suggesting that everyone move to OS/2, just pointing out that
the chain of reasoning that X is a "real operating system", therefore
X cannot allow you to directly access an IO port is misleading.

Re: question re Ada equivalent of C function

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
> I am not suggesting that everyone move to OS/2, just pointing out that
> the chain of reasoning that X is a "real operating system", therefore
> X cannot allow you to directly access an IO port is misleading.

Linux allows this too, although only if you have root rights. Just
call the iopl() system call then to gain access to the io ports you
need.  

Often it is better design to write a small kernel level driver 
stub though to access the hardware and control it over a device from the
user program. For example it is pretty bad to disable interrupts in
user programs (it is possible with some ugly tricks, but will probably
break on SMP machines) - and often accesses to io ports require that for
race-free operation. Overall doing io port accesses in a kernel level 
driver is better in most cases.

-Andi

Re: question re Ada equivalent of C function

[Nick Roberts]

In addition, if your Ada compiler supports machine code insertions, you
should be able to use these to provide the input/output functions you
require. Consult your compiler's documentation.

Note, however, that many processors these days enable normal (user
application) programs to be prevented from executing 'privileged'
instructions. With such a processor, the operating system may well decide
to stop your program from executing input/output instructions: in this
case, you will have to investigate your operating system's and/or
compiler's provisions for writing device drivers.

Also, of course, even if your program can't be stopped from executing
input/output instructions, executing them in the wrong circumstances could
interact badly with the operating system (or other software), unless you're
running on a 'bare' machine.


== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]


Brian Rogoff <bpr@shell5.ba.best.com> wrote in article
<Pine.BSF.3.96.980221115827.17781A-100000@shell5.ba.best.com>...
> On Sat, 21 Feb 1998, David Fisher wrote:
> > Sorry if this is a bit basic, but learning Ada on one's own can be, er,
> > challenging.
> 
> You're never alone on comp.lang.ada! :-)
> 
> > What are the Ada equivalents of the C functions, inp and outp, used to
> > read a byte from or send one to a memory address?
> 
> Well, that depends. If you just want to reuse some C routines, I'd
suggest 
> that you use Interfaces.C and just reuse them. Otherwise, you'll want to 
> look at the System and System.Storage_Elements packages for what you
want. 
> If you want to access a Character at some memory address, say
> 16#CAFEBABE#, you'd do something like this (boilerplate omitted)
> 
> ...
> Mem_Addr : constant Address := To_Address(16#CAFEBABE#);
> Mem_Mapped_Char : Character;
> for Mem_Mapped_Char'Address use Mem_Addr;
> ...
> 
> which is surprisingly self-explanatory.

question re Ada equivalent of C function

[frc]

>In addition, if your Ada compiler supports machine code insertions, you
>should be able to use these to provide the input/output functions you
>require. Consult your compiler's documentation.

I'd love to, but the Aonix ObjectAda v7.1 compiler that was included
in the textbook was accompanied by a null set of instructions and
documentation. The CD help files are, for someone accustomed to the
copious and accessible documentation provided by MS VC, rather
uninspiring. Cryptic is the word that comes to mind...

David Fisher

Re: question re Ada equivalent of C function

[Robert Dewar]

David Fisher says

<<Sorry if this is a bit basic, but learning Ada on one's own can be, er,
challenging.

What are the Ada equivalents of the C functions, inp and outp, used to
read a byte from or send one to a memory address?

Thanks!

David Fisher
Fisher Research Corporation
>>


First there are no such functions in the C language. They are not even
standard Unix functions, but rather some idiosyncratic library functions
from DOS-like systems.

Second, they do not read and write to/from a memory address, but rather
they access ports on DOS-like systems that allow such port access (ports
are quite different from memory addresses, since they are defined int
the IO space of the machine, rather than the memory space).

Third, if you are on one of these systems and are writing Ada, and want
to do similar highly non-portable target dependent operations, then
there are two approaches:

1. Issue the necessary In/Out instructions directly using either package
Machine code, or, preferable if your compiler supports them, machine
language intrinsics (GNAT supports both styles, see GNAT manual for
details of use).

2. Simpler probably, though less efficient, just interface to the inp and
outp routines using the usual pragma Import (C, ...) mechanism.

Re: question re Ada equivalent of C function

[Corey Ashford]

David Fisher wrote in message <34EEFF9C.1D01FA5D@stellar1.com>...
>Sorry if this is a bit basic, but learning Ada on one's own can be, er,
>challenging.
>
>What are the Ada equivalents of the C functions, inp and outp, used to
>read a byte from or send one to a memory address?
>
>Thanks!
>
>David Fisher
>Fisher Research Corporation
>

There are a number of ways to do this in Ada.  Here's one fairly simple one:

with unchecked_conversion;
with system;

type byte is mod 2*8;
type byte_access is access byte;
function to_byte_access is new unchecked_conversion(system.address,
byte_access);

function inp(addr: system.address) return byte is
begin
    return to_byte_access(addr).all;
end inp;

procedure outp(addr: system.address; value: byte) is
begin
    to_byte_access(addr).all := value;
end outp;

Re: question re Ada equivalent of C function

[Nick Roberts]

Again, this kind of technique is specific to those architectures with
memory-mapped ports, and even so, there could well be further ramifications
(e.g. access rights, interference, etc.).

It also assumes that an access value is the same as an address: this is not
always so! For fooling around in memory, you're better off using the
facilities provided by the standard packages System.Storage_Elements (RM
13.7.1) and System.Address_To_Access_Conversions (RM 13.7.2).

(I always think it's slightly biblical, quoting chapter-and-verse like that
;-)


== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]


Corey Ashford <yeroca7@rocketmail.com> wrote in article
<6cnj5d$bjq$1@usenet.rational.com>...
> 
> David Fisher wrote in message <34EEFF9C.1D01FA5D@stellar1.com>...
> >Sorry if this is a bit basic, but learning Ada on one's own can be, er,
> >challenging.
> >
> >What are the Ada equivalents of the C functions, inp and outp, used to
> >read a byte from or send one to a memory address?
> >
> >Thanks!
> >
> >David Fisher
> >Fisher Research Corporation
> >
> 
> There are a number of ways to do this in Ada.  Here's one fairly simple
one:
> 
> with unchecked_conversion;
> with system;
> 
> type byte is mod 2*8;
> type byte_access is access byte;
> function to_byte_access is new unchecked_conversion(system.address,
> byte_access);
> 
> function inp(addr: system.address) return byte is
> begin
>     return to_byte_access(addr).all;
> end inp;
> 
> procedure outp(addr: system.address; value: byte) is
> begin
>     to_byte_access(addr).all := value;
> end outp;

Re: question re Ada equivalent of C function

[Larry Kilgallen]

In article <34EEFF9C.1D01FA5D@stellar1.com>, David Fisher <frc@stellar1.com> writes:
> Sorry if this is a bit basic, but learning Ada on one's own can be, er,
> challenging.
> 
> What are the Ada equivalents of the C functions, inp and outp, used to
> read a byte from or send one to a memory address?

Speaking as someone who learned Ada on my own, let me suggest that you
avoid the search for "do xyz like language abc" and deal with Ada as
a language unto itself.

In many cases trying mimic the functions of another language means that
you end up writing an an unnatural style (for Ada) and giving up the
more powerful constructs of Ada.  Learn all you can about programming
in a normal Ada style (there are lots of good books available) and
only after you have that mastered should you consider emulating other
languages in very special cases (which certainly exist).

Larry Kilgallen

Re: question re Ada equivalent of C function

[Robert Dewar]

Larry said

<<> What are the Ada equivalents of the C functions, inp and outp, used to
> read a byte from or send one to a memory address?

Speaking as someone who learned Ada on my own, let me suggest that you
avoid the search for "do xyz like language abc" and deal with Ada as
a language unto itself.

>>

Though this is generally a reasonable position, I don't see how it applies
here. The question was how to read and write I/O ports on the PC (I agree
it was asked in a somewhat confusing manner). That seems a perfectly
reasonable question ...

question re Ada equivalent of C function

[frc]

Agreed. What I am after is a means - more than a C transliteration -
of accessing I/O hardware which requires this kind of read/write
functionality. My only basis of description is the C functions that I
have used to do this.

David Fisher

>In many cases trying mimic the functions of another language means that
>you end up writing an an unnatural style (for Ada) and giving up the
>more powerful constructs of Ada.  Learn all you can about programming
>in a normal Ada style (there are lots of good books available) and
>only after you have that mastered should you consider emulating other
>languages in very special cases (which certainly exist).

Linux/POSIX packages for GNAT

[Markus Kuhn]

frc@stellar1.com wrote:
> Agreed. What I am after is a means - more than a C transliteration -
> of accessing I/O hardware which requires this kind of read/write
> functionality. My only basis of description is the C functions that I
> have used to do this.

inp and outp are Intel assembler instructions and you can include
assembler code directly into your Ada program (check the GNAT docs
for details). Under Linux, normal user processes are not allowed to
access the IO ports. Root processes are only allowed to access
the IO ports after they have requested this right from the kernel
with a special system call (for instance the XFree86 X11 server under
Linux does this to set the video modes directly via hardware IO
register access).

What would be nice to have is a Linux Ada package that implements all
those low-level accesses to the operating system and processor (such
as directly making a system call, inp/outp, access to sockets, MMX
functions, etc.), such that not every user of those facilities has
to learn Intel/Alpha/SPARC assembler but can use nice documented
Ada procedures.

It seems the standard packages that come with GNAT only cover
what is defined in the Ada95 RM plus a few GNAT specific extentions.
What is urgently missing for real Linux system development is Linux
low-level access as well as an implementation of the full POSIX.5
Ada API. Has this already been done somewhere or is any work on
this in progress?

How widely implemented is the POSIX.5 API (standardized Ada versions
of the common Unix system calls) anyway?

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/>

Re: Linux/POSIX packages for GNAT

[Robert Dewar]

<<What is urgently missing for real Linux system development is Linux
low-level access as well as an implementation of the full POSIX.5
Ada API. Has this already been done somewhere or is any work on
this in progress?

How widely implemented is the POSIX.5 API (standardized Ada versions
of the common Unix system calls) anyway?
>>


Interesting to see these two paragraphs next to one another. The first
claims it is urgent to implement the full POSIX.5 Ada API. The second
asks how widely implemented this package is.

Perhaps the question should be answered before the urgency is declared :-)

Re: Linux/POSIX packages for GNAT

[Markus Kuhn]

Robert Dewar wrote:
> 
> <<What is urgently missing for real Linux system development is Linux
> low-level access as well as an implementation of the full POSIX.5
> Ada API. Has this already been done somewhere or is any work on
> this in progress?
> 
> How widely implemented is the POSIX.5 API (standardized Ada versions
> of the common Unix system calls) anyway?
> >>
> 
> Interesting to see these two paragraphs next to one another. The first
> claims it is urgent to implement the full POSIX.5 Ada API. The second
> asks how widely implemented this package is.
> 
> Perhaps the question should be answered before the urgency is declared :-)

In case it was not clear what I referred to:

I am at the moment a quite experienced and happy programmer using
a complete ISO C / POSIX.1 conforming development environment (Linux).
I am seriously considering to switch to Ada95, but I will not consider
Ada to be an attractive development language under Linux as long
as I do not know how to get the same rich library/kernel functionality
that I do currently have as a C programmer. The standard packages
required by Ada95 RM are alone not sufficient for real Unix application
development. In production quality application development,
the functionality of the full Linux kernel API should be easily
available. This includes the usual POSIX.1 functionality plus a
number of not-yet-POSIX-standardized functions such as sockets
and symlinks. Sure, I understand that I can always access any
libc function via Ada95 interface pragmas, but it obviously would
be much more convenient to have a native production quality Ada
API such as POSIX.5 available.

I have not yet found a large system (say a good high-performance
HTTP server) completely written in Ada95 for Linux that would
convince me that all the tools for doing such a project are
already available for Linux. A well-supported Ada95 equivalent
of the Linux libc seems to be the critical part.

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/>

Re: Linux/POSIX packages for GNAT

[Robert Dewar]

Markus said

<<I am at the moment a quite experienced and happy programmer using
a complete ISO C / POSIX.1 conforming development environment (Linux).
I am seriously considering to switch to Ada95, but I will not consider
Ada to be an attractive development language under Linux as long
as I do not know how to get the same rich library/kernel functionality
that I do currently have as a C programmer. The standard packages
>>

That's fair enough. There are three possible solutions to your problems:

1. Use pragma Import to call whatever C functions you know and find useful.

2. Use the existing standardized binding to the the Posix functionality

3. Use some other binding that provides this functionality.

Of these, at the present time, 1. is the easiest and the most portable. 
Furthermore, if you already are an experienced user of the Posix interface,
I think you will find this the easiest approach. The standardized binding
is not a completely thin binding, and will require some learning curve,
whereas using approach 1 will require zero learning curve.

<<Sure, I understand that I can always access any
  libc function via Ada95 interface pragmas, but it obviously would
  be much more convenient to have a native production quality Ada
  API such as POSIX.5 available.>>
  
That's the point, this is not at all obvious to me that this is the case,
especially give someone who is familiar with the existing C interface. Indeed
I would have thought it was clearly the case that it is more convenient to
use pragma Import than a thickish binding. An aggressively thin binding might
be more convenient (basically it would save you the trouble of writing the
pragma Imports), but that is not what the standard provides.

I wonder, have you actually studied the Ada standard in coming to your
conclusions about convenience?

Re: Linux/POSIX packages for GNAT

[Markus Kuhn]

Robert Dewar wrote:
> I wonder, have you actually studied the Ada standard in coming to your
> conclusions about convenience?

You mean POSIX.5? Not yet. I have ordered a copy from IEEE and I am
eagerly waiting to see this standard and to find out whether it
is as good as my beloved POSIX.1 for C.

But I will consider your advice seriously to get more comfortable
with interface pragmas and use libc directly for the time being.
I just thought using POSIX.5 would be a cleaner "native Ada
programming" style then the C/Ada mixture that I will get by using
interface pragmas. That's the reason for my style/convenience
concerns.

Is there anything wrong with POSIX.5 compared with POSIX.1 in
your opinion (except the lack of an implementation)?

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/>

Re: question re Ada equivalent of C function

[Dale Stanbrough]

Robert Dewar writes:
"I would have thought it was clearly the case that it is more convenient to
 use pragma Import than a thickish binding. An aggressively thin binding might
 be more convenient (basically it would save you the trouble of writing the
 pragma Imports), but that is not what the standard provides."


I would agree that thin bindings are useful, especially as the common
C type map to common Ada types (or at least to those in interfaces.c).
I have found that providing a slightly thicker layer to accomodate Ada's
strings to be useful.

The use of callback data in Motif/TCL/Tk is also an area where something
better than "wafer thin" is also called for.

It's much easier to provide bindings and say (to students for example)
"just read the man page", than to have to create your own documentation.
Being _able_ to say "just read the man page" also helps with Ada's acceptance.

Dale

Re: Linux/POSIX packages for GNAT

[Andi Kleen]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> <<What is urgently missing for real Linux system development is Linux
> low-level access as well as an implementation of the full POSIX.5
> Ada API. Has this already been done somewhere or is any work on
> this in progress?
> 
> How widely implemented is the POSIX.5 API (standardized Ada versions
> of the common Unix system calls) anyway?
> >>
> 
> 
> Interesting to see these two paragraphs next to one another. The first
> claims it is urgent to implement the full POSIX.5 Ada API. The second
> asks how widely implemented this package is.
> 
> Perhaps the question should be answered before the urgency is declared :-)

Why? I don't see a connection. urgency of needing something is not directly 
connected to wide deployment of the same thing.

-Andi

Re: Linux/POSIX packages for GNAT

[Robert Dewar]

Andi said

<<Why? I don't see a connection. urgency of needing something is not directly
connected to wide deployment of the same thing.
>>

I can see how there can be an urgent need for *some* binding to *some*
set of facilities.

But to decide that a particular binding is *the* solution seems strange
unless that binding has a reasonable currency as a standard in use.

Re: Linux/POSIX packages for GNAT

[Markus Kuhn]

Robert Dewar wrote:
> But to decide that a particular binding is *the* solution seems strange
> unless that binding has a reasonable currency as a standard in use.

I was assuming that POSIX.5 is or will be the Ada equivalent of
POSIX.1 for C. POSIX.1 for C is extremely widely implemented and highly
helpful for portable programming on Unix. Any C programmer switching
under Unix from C to Ada will expect to have the equivalent of
POSIX.1 available under the new language, because under Unix
you have to be able to deal with processes, signals, terminals and
other functions that are beyond the Ada RM. Therefore, I considered
an implementation of POSIX.5 to be urgently needed.
What is wrong with that?

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/>

Re: Linux/POSIX packages for GNAT

[Robert Dewar]

Markus said

<<I was assuming that POSIX.5 is or will be the Ada equivalent of
POSIX.1 for C. POSIX.1 for C is extremely widely implemented and highly
helpful for portable programming on Unix. Any C programmer switching
under Unix from C to Ada will expect to have the equivalent of
POSIX.1 available under the new language, because under Unix
you have to be able to deal with processes, signals, terminals and
other functions that are beyond the Ada RM. Therefore, I considered
an implementation of POSIX.5 to be urgently needed.
What is wrong with that?
>>


OK, so you answered my last question. You have not read the standard.
I think you should, it would be particularly interesting to get your
reaction to the abstraction level at which it has been designed. 

I generally prefer very thin bindings for standards like this, precisely
because it allows easily portability of documentation and existing
knowledge.

Re: Linux/POSIX packages for GNAT

[Andi Kleen]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:
> 
> It seems the standard packages that come with GNAT only cover
> what is defined in the Ada95 RM plus a few GNAT specific extentions.
> What is urgently missing for real Linux system development is Linux
> low-level access as well as an implementation of the full POSIX.5
> Ada API. Has this already been done somewhere or is any work on
> this in progress?
> 
> How widely implemented is the POSIX.5 API (standardized Ada versions
> of the common Unix system calls) anyway?

I would be very interested in such a thing too. I started to write my
own API based on code from Jesus Gonzalez Barahona, because the POSIX.5
draft doesn't seem to be available. Especially socket access in Ada needs
home-grown interfaces currently :(

-Andi

Re: Linux/POSIX packages for GNAT

[Samuel Tardieu]

>>>>> "Andi" == Andi Kleen <ak@muc.de> writes:

Andi> Especially socket access in Ada needs home-grown interfaces
Andi> currently :(

If you need a socket interface, you can also use the one we developped 
in ENST. It's called AdaSockets, is in testing phase right now, but
works pretty well.

You can get the first release (0.1.0) at http://www-inf.enst.fr/ANC/

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Linux/POSIX packages for GNAT

[Nick Roberts]

Samuel Tardieu wrote in message ...
[...]
>If you need a socket interface, you can also use the one we developped
>in ENST. It's called AdaSockets, is in testing phase right now, but
>works pretty well.


Sam: you must have struggled with the name there for _hours_ :-)

Re: Linux/POSIX packages for GNAT

[Samuel Tardieu]

>>>>> "Nick" == Nick Roberts <Nick.Roberts@dial.pipex.com> writes:

Nick> Sam: you must have struggled with the name there for _hours_ :-)

And it still gives me headaches :) Anyway, if you have a better name,
I accept any suggestion. I'll add a note in the README of the next
version that asks for better ideas.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Testing exception handlers

[James M. Darlack]

Hi!

Im writing a tool(s) for testing unhandled exceptions, and standard
exceptions such as PROGRAM, TASKING, and STORAGE,for an Intel embedded
system.  My basic tool is a procedure shown at the end of this email.

Using the basic tool, I can invoke unhandled interupt exceptions and the
three standard exceptions.  However, what do I do to simulate the standard
exceptions within the code without the test procedure?  I would like to
create another tool(s), that would invoke a real tasking, programming, and
storage errors.

I contacted the compiler manufacturer, and they were vague... to say the
least. 

I am a C and assembler programmer, with Ada experience from over 10 years
ago.  So any help would be appreciated.

Thanks!  

Jim   

Note! Please respond to jmd@darlack.com

To use the test tool, include it in the package, and re-compile and link.
Set a breakpoint for the start of the procedure, step until you can change
the TEST_NUM, and single step or run until the exception is invoked.

  procedure UE_TEST is
    TEST_NUM : INTEGER := 99; --change to the case that matches the
                              --excpetion, that you want to invoke.
  begin
    case TEST_NUM is
      when  0 => INT0;  --UNHANDLED_EXCEPTION_000
      when  1 => INT1;  --UNHANDLED_EXCEPTION_001
       "
       "
      when 20 => raise PROGRAM_ERROR;
      when 21 => raise STORAGE_ERROR;
      when 22 => raise TASKING_ERROR;
      when others => null;
    end case;
  end UE_TEST;

Re: Linux/POSIX packages for GNAT

[Markus Kuhn]

Andi Kleen wrote:
> the POSIX.5 draft doesn't seem to be available.

That should not be the problem. The POSIX.5 standard can easily
be ordered from IEEE as

  IEEE Std 1003.5b-1996 Standard for Information Technology--POSIX
  Ada Language Interfaces--Part 1: Binding for System Applications
  Program Interface (API), 550 pages, ISBN 1-55937-758-5, US$ 112 (for
  IEEE members), order code SH94432-NYF.

either from

  IEEE Publications
  Tel: +1-732-981-1393 (1-800-678-IEEE)
  Fax: +1-732-981-9667

or

  IEEE Computer Society Publications
  10662 Los Vaqueros Circle
  PO Box 3014
  Los Alamitos, CA 90720-1264
  USA
  Tel: +1-714-821-8380
  Fax: +1-714-821-4010

There seem to be some partial POSIX.5 packages for Linux and other
Unices around, for instance Forest 1.3 on

http://www.informatik.uni-stuttgart.de/ifi/ps/ada-software/html/os_env.html

It would be nice to have this completed and become part of the
standard GNAT distribution plus as you mentioned some homemade
extentions for sockets, symlinks, etc., until we have a POSIX
Ada binding for those, too.

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/>

Re: Linux/POSIX packages for GNAT

[Robert Dewar]

<<There seem to be some partial POSIX.5 packages for Linux and other
Unices around, for instance Forest 1.3 on
>>

And that indeed is the cruz of the issue. The linux comment specifically
mentioned that it was urgent to have a "full" implementation, but it seems
that in practice partial implementations have been more common!