Re: C/C++ ... out of Ada

[ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)]

ncohen@watson.ibm.com (Norman H. Cohen) writes:

>In article <4ggt07$7mm@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU
>(Richard A. O'Keefe) writes: 

>|> PL/I-style "record" I/O is also not supported by Ada 95.

>Sequential_IO provides the basic capabilities of PL/I record I/O,
>although it is obviously not a clone of that facility.

I think it would be considerably more accurate to say that Sequential_IO
provides the basic capability of Pascal I/O.  Most of the interesting bits
in PL/I are missing, and sometimes they can be useful.

Package Ada.Sequential_IO takes Element_Type(<>) as generic parameter,
and provides

	File_Type, File_Mode, Create, Open, Close, Delete, Reset,
	Mode, Name, Form, Is_Open, a bunch of exceptions, and

	Read(File, Item), Write(File, Item)

as the only transfer operations.  Now, when I use fread() in UNIX, the data
are transferred from disc to OS buffers, from OS buffers to a stdio buffer,
and thence to my object (2 memory-memory copies), and when I use fwrite()
the same happens.

One of the key features of PL/I record I/O was "locate mode"

Let's see how something like that could be specified in Ada.

	Read_Locate(File, Location)
	-- return access to a record
	Read_Release(File, Location)
	-- releases the record area for re-use

	Write_Locate(File, Location)
	-- return access to a writable record
	Write_Release(File, Location)
	-- releases the record for output

so

	generic

	    type Element_Type(<>) is private;
	    Record_Areas: Positive := 1;

	package Locate_Mode_IO is

	    type Input_Element_Location is access constant Element_Type;
	    type Output_Element_Location is access Element_Type;

	    type File_Type is limited private;
	    type File_Mode is (In_File, In_Out_File, Out_File, Append_File);

	    Open, Close, Delete, Reset, Mode, Name, Form, Is_Open,
	    and End_Of_File declared as in Sequential_IO.

	    exception Record_Areas_Exhausted;
	    -- the generic parameter Record_Areas says how many record
	    -- area pointers can be in client hands for a single file.
	    -- E.g. if Record_Areas = 2, then
	    --	Read_Locate(F, X1);	-- ok
	    --	Read_Locate(F, X2);	-- ok
	    --	Read_Locate(F, X3);	-- Record_Areas_Exhausted

	    exception Released_To_Wrong_File;
	    -- In a call to Read_Release(F, L), the value of L must have
	    -- been obtained by a call to Read_Locate(F, L) with the same
	    -- parameters.  Ditto for Write_Release/Write_Locate; 

	    procedure Read_Locate  (File: in File_Type;
				    Area: out Input_Element_Location);
	    -- if not at end of file, reads a record into a record area
	    -- and sets Area to point to that record area.

	    procedure Read_Release (File: in File_Type;
				    Area: in out Input_Element_Location);
	    -- returns the Area to the File's control, sets Area to null.

	    procedure Write_Locate (File: in File_Type;
				    Area: out Output_Element_Location);
	    procedure Write_Release(File: in File_Type;
				    Area: in out Output_Element_Location);

	end Locate_Mode_IO;

Here's how it would be used:

	with Locate_Mode_IO;

	procdure Main is
	    type Foo_Bar is record ... end record;

	    package Foo_Bar_IO is new Locate_Mode_IO(
		Element_Type => Foo_Bar, Record_Areas => 10);

	    use Foo_Bar_IO;

	    Source: File_Type;
	    Source_Ptr: Input_Element_Location;

	    Destination: File_Type;
	    Destination_Ptr: Output_Element_Location;

	begin
	    Open(Source, In_File, "foobar.dat");
	    Create(Destination, Out_File, "foobar.cpy");
	    while not End_Of_File(Source) loop
		Read_Locate(Source, Source_Ptr);
		Write_Locate(Destination, Destination_Ptr);
		Destination_Ptr.all := Source_Ptr.all;
		Read_Release(Source, Source_Ptr);
		Write_Release(Destination, Destination_Ptr);
	    end loop;
	    Close(Source);
	    Close(Destination);
	end Main;

What's the point of this?  Well, in a typical implementation of Sequential_IO,

    read a record:
	disc -> OS buffer -> file buffer -> internal variable
    write a record
	internal variable -> file buffer -> OS buffer -> disc

That's FOUR memory->memory transfers.  With locate mode IO,

    read a record:
	disc -> OS buffer -> file buffer 1
    copy the record
	file buffer 1 -> file buffer 2
    write a record
	file buffer 2 -> OS buffer -> disc

That's THREE memory->memory transfers.  Copying is about the worst case:
if you are just reading or just writing a file, you cut out half of the
memory transfers,

Then there's the matter of "rewrite".

>|> It might actually be worth discussing this at some time; what did DEC Ada
>|> do about RMS?

>DEC adopted a gcc-based Ada compiler for the Alpha.

That doesn't answer the question at all.  I'm not asking about what
_compiler_ they use, I'm asking "what do they do about interfacing to
and exploiting Open VMS facilities".

>(I presume that by RMS you mean Richard M. Stallman. ;-) )

I presume that Norman Cohen knows what I really meant, but for the benefit
of readers who don't, I meant "Record Management Services".



Look, I'm not an Ada basher.  I love Ada.  Ada does not try to do everything.
There is nothing in the Ada 95 standard that says someone _can't_ write a
package like the one I outlined above.  Indeed, Ada + POSIX binding provides
a firm basis for writing and experimenting with alternative IO models.  (I'd
better save this message and see if any student is interested in doing it
for a project.)  

-- 
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.