Streams in Ada

Streams in Ada

[chris.danx]

Hi,
    I've looked about for examples on streams in Ada.  I'm writing an
virtual file system as a file on disk, and want to use streams.  I have to
be able to go back and forwards and read large blocks of data from the file
at random positions.  I have tried to locate an example of using streams but
couldn't find any that didn't deal with sequential access.

the first block is 512 bytes and inodes are 64bytes.  then i have a set of
blocks which are 16bytes long.  you can see now why i'm using streams, but i
can't seem to work out from the ref manual and Barnes what i should do.  I
recall the ref manual saying index is relative to stream element but i don't
know what it means.  Anyone know of a good example?



Thanks in advance,
Chris Campbell

Re: Streams in Ada

[chris.danx]

I also need help with this.

The OS developer i'm working with might switch development from C to Ada.  I
found out he has a background in Pascal and not C.  I seem to remember an
introduction to Ada for Pascal programmers.  Can't find it, only C/C++ to
Ada.  Does anyone know the link?


Thanks again,
Chris Campbell

Re: Streams in Ada

[Jeff Creem]

Hmm..This is not really all that difficult to do with by just calling
the Set_Index function. Perhaps I am missing the complexity. If so perhaps
you
can explain exactly what the difficulty is and I could create an example.


"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:pCmx6.7235$MZ2.1205520@news2-win.server.ntlworld.com...
> I also need help with this.
>
> The OS developer i'm working with might switch development from C to Ada.
I
> found out he has a background in Pascal and not C.  I seem to remember an
> introduction to Ada for Pascal programmers.  Can't find it, only C/C++ to
> Ada.  Does anyone know the link?
>
>
> Thanks again,
> Chris Campbell
>
>

Re: Streams in Ada

[chris.danx]

I remember what it is that's confusing me.  It's this

ARM Annex A 12.1 (4)

"The Index function returns the current file index, as a count (in stream
elements) from the beginning of the file. The position of the first element
in the file is 1. "

What are the stream elements in this case?


Thanks,
Chris Campbell

Re: Streams in Ada

[Robert A Duff]

"chris.danx" <chris.danx@ntlworld.com> writes:

> What are the stream elements in this case?

Stream_Element is declared at RM-13.13.1(4).  You have to look at your
compiler's documentation to see for sure what it is.

But in practise, it's almost always an 8-bit byte ("octet").
I.e., type Stream_Element is mod 2**8;

- Bob

Re: Streams in Ada

[chris.danx]

So i just compute the byte address and call set_index.  Simple.

Thanks Guys,
Christopher Campbell

Re: Streams in Ada

[Ted Dennison]

In article <wccwv95fulm.fsf@world.std.com>, Robert A Duff says...
>
>"chris.danx" <chris.danx@ntlworld.com> writes:
>
>> What are the stream elements in this case?
>
>Stream_Element is declared at RM-13.13.1(4).  You have to look at your
>compiler's documentation to see for sure what it is.
>
>But in practise, it's almost always an 8-bit byte ("octet").
>I.e., type Stream_Element is mod 2**8;

I generally feel better calculating it anyway, just to be safe (and portable).
Just use the following declaration:

Bytes_Per_Element  : constant := (Ada.Streams.Stream_Element'Size + 7) / 8;

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Streams in Ada

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> I generally feel better calculating it anyway, just to be safe (and
> portable).  Just use the following declaration:
> 
> Bytes_Per_Element  : constant := (Ada.Streams.Stream_Element'Size + 7) / 8;

This gives the wrong result on a PDP-10, I think. ;-)

Re: Streams in Ada

[Ted Dennison]

In article <tglmpjxutl.fsf@mercury.rus.uni-stuttgart.de>, Florian Weimer says...
>
>Ted Dennison<dennison@telepath.com> writes:
>
>> I generally feel better calculating it anyway, just to be safe (and
>> portable).  Just use the following declaration:
>> 
>> Bytes_Per_Element  : constant := (Ada.Streams.Stream_Element'Size + 7) / 8;
>
>This gives the wrong result on a PDP-10, I think. ;-)

There's an Ada compiler for the PDP-10? Who says we aren't cutting-edge! :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Streams in Ada

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> There's an Ada compiler for the PDP-10? Who says we aren't cutting-edge! :-)

I worked on an Ada compiler for the PDP-10.  It never got finished,
though, because the project was cancelled when DEC cancelled the Jupiter
project.  (Jupiter was going to be the next version of PDP-10 hardware,
but they decided to put all their efforts into the VAX, instead.)

- Bob

Re: Streams in Ada

[Marin David Condic]

But wouldn't that posit that there *was* an Ada95 implementation on a PDP-10
and that a Stream_Element was 36 bits?

Someone mentioned here a few days ago about the existence of PDP-10
look-alikes, but I don't think anyone has any evidence of a validated Ada95
compiler for one of them. It would sure make me nostalgic to have access to
a PDP-10 for a while & write some programs for it again. (Hmmmmmmm.......
Maybe I'll get started writing a simulator for it, just for fun & to use up
all that spare time I have..... :-)

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Florian Weimer" <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message
news:tglmpjxutl.fsf@mercury.rus.uni-stuttgart.de...
> Ted Dennison<dennison@telepath.com> writes:
>
> > I generally feel better calculating it anyway, just to be safe (and
> > portable).  Just use the following declaration:
> >
> > Bytes_Per_Element  : constant := (Ada.Streams.Stream_Element'Size + 7) /
8;
>
> This gives the wrong result on a PDP-10, I think. ;-)

Re: Streams in Ada

[Florian Weimer]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> But wouldn't that posit that there *was* an Ada95 implementation on a PDP-10
> and that a Stream_Element was 36 bits?

Well, the poster specifically mentioned portability, and his code does
not work on such an architecture.  IMHO, portable code hasn't just to
run on all platforms which exist (this could be called 'practically
portable code'), but on all Ada implementations.

> Someone mentioned here a few days ago about the existence of PDP-10
> look-alikes, but I don't think anyone has any evidence of a validated Ada95
> compiler for one of them.

GCC is currently being ported to it.

Re: Streams in Ada

[Ted Dennison]

In article <tgofufwd4x.fsf@mercury.rus.uni-stuttgart.de>, Florian Weimer says...
>
>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
>> But wouldn't that posit that there *was* an Ada95 implementation on a PDP-10
>> and that a Stream_Element was 36 bits?
>
>Well, the poster specifically mentioned portability, and his code does
>not work on such an architecture.  IMHO, portable code hasn't just to
>run on all platforms which exist (this could be called 'practically
>portable code'), but on all Ada implementations.

I think you meant, "all possible Ada implementations", which I would disagree
with. On the other hand, if we were to interpret this to say "on all likely
implementations", I could agree with you. I'll leave it up to others how likely
a conforming Ada95 PDP-10 implementation is.

However, this wouldn't actually have been a problem anyway, because the code I
wrote assumes that the user also has something close to the following
declarations:

type User_Element is mod 256;  -- Could be any multiple of this
for User_Element'size use 8;   -- Could be any matching multiple of this
type Byte_Array is array (<> Natural) of Byte;

And then the hard-coded 8's and 7's in the code I posted before would *really*
be "User_Element'size" and "(User_Element'size - 1)". I just used the hard-coded
8 as a short-cut for implying the above. On platforms with different byte sizes,
it is the user's "mod" and "'size" declarations that would be changed. (Are they
buying it? :-)  )

Out of curiosity, what exactly constituted a "byte" on a PDP-10?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Streams in Ada

[Marin David Condic]

The PDP-10 was more closely oriented to "Sixbit" characters. (Or
"Half-ASCII" - basically ASCII with the lower case & some other stuff gone.)
IIRC, the Tops-10 OS had the 6x3 file name restrictions basically because it
would make filenames fit with Sixbit & into even multiples of machine words.
Why DEC chose Sixbit & 36 bit words in the first place, I do not know - but
one must remember that this was back in the time when Pangeia was still a
united country. (Or was it Ganwanaland?) There weren't a lot of existing
conventions for much of anything in computer technology, so 36 was just as
beautiful a number as 32.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:zc1y6.352$UK4.34815@www.newsranger.com...
>
> Out of curiosity, what exactly constituted a "byte" on a PDP-10?
>

PDP-10, was Re: Streams in Ada

[tmoran]

>Why DEC chose Sixbit & 36 bit words in the first place, I do not know
  IBM 7090?

Re: Streams in Ada

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> The PDP-10 was more closely oriented to "Sixbit" characters. (Or
> "Half-ASCII" - basically ASCII with the lower case & some other stuff gone.)
> IIRC, the Tops-10 OS had the 6x3 file name restrictions basically because it
> would make filenames fit with Sixbit & into even multiples of machine words.

This is more a property of Tops-10 than the PDP-10 hardware.

The hardware supported "bytes", which could be from 1 to 36 bits each --
there's nothing special about 6-bit bytes.  A byte could not cross a
(36-bit) word boundary.  Tops-20 also ran on this hardware (and was far
superior to Tops-10).  When I used it, we mainly used 7-bit ASCII for
character data.  Each character is a 7-bit byte, packed 5 to a word,
with one bit left over.  You could also use sixbit (6 6-bit bytes per
word) on Tops-20, presumably for backward compatibility.  But you could
also use 1-bit bytes for arrays of Boolean, or any other convenient
sub-word size.

> Why DEC chose Sixbit & 36 bit words in the first place, I do not know - but
> one must remember that this was back in the time when Pangeia was still a
> united country. (Or was it Ganwanaland?) There weren't a lot of existing
> conventions for much of anything in computer technology, so 36 was just as
> beautiful a number as 32.

Well, I think it only makes sense to design hardware where the word size
is a power of 2 times the addressable unit (what Ada calls
System.Storage_Unit).  So 36 only works if your addressable unit is 36,
18, or 9.  (It was 36 on the PDP-10.)  Ie, a machine with Storage_Unit = 6
and Word_Size = 36 wouldn't work very well.

Although it's probably true that nobody cares about Ada on a PDP-10
these days, there do exist machines with Storage_Unit /= 8, and there do
exist Ada compilers for such machines.  So it might very well make
sense to program with portability to such weird machines in mind.

Besides, even if all machines had Storage_Unit = 8, it would *still*
make sense to declare meaningful constants, because it makes code more
readable if you know that it depends on such things.

- Bob

6-bit characters (was: Re: Streams in Ada)

[Jeffrey Carter]

I've never used the PDP-10, but ...

I learned to program in Fortran 66 (IV) on a CDC 6400 with 60-bit words.
It used a 6-bit character set, so 10H fit into one word. The next
machine I used was a DEC 10 with TOPS-10. It had 36-bit words, but I
never encountered 6-bit characters on it; 7-bit ASCII IIRC.

Jeffrey Carter

Re: 6-bit characters (was: Re: Streams in Ada)

[Robert A Duff]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> I've never used the PDP-10, but ...
> 
> I learned to program in Fortran 66 (IV) on a CDC 6400 with 60-bit words.
> It used a 6-bit character set, so 10H fit into one word. The next
> machine I used was a DEC 10 with TOPS-10. It had 36-bit words, but I
> never encountered 6-bit characters on it; 7-bit ASCII IIRC.

The DEC 10 and the PDP-10 are the same machine.

- Bob

Re: 6-bit characters (was: Re: Streams in Ada)

[Jeffrey Carter]

Robert A Duff wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> writes:
> 
> > I've never used the PDP-10, but ...
> >
> > I learned to program in Fortran 66 (IV) on a CDC 6400 with 60-bit words.
> > It used a 6-bit character set, so 10H fit into one word. The next
> > machine I used was a DEC 10 with TOPS-10. It had 36-bit words, but I
> > never encountered 6-bit characters on it; 7-bit ASCII IIRC.
> 
> The DEC 10 and the PDP-10 are the same machine.

How interesting. Since you and MDC both say this, I only need one more
person to tell me this for it to be a fact ("What I tell you 3 times is
true."). I was aware of the PDP-11, but no one ever mentioned that the
DEC 10 was the PDP-10.

The DEC 10 was supposed to be able to handle 100 users simultaneously.
Boy, was it slow.

BTW, I didn't use TECO on the DEC 10; I used SOS.

Jeffrey Carter

Re: 6-bit characters (was: Re: Streams in Ada)

[Florian Weimer]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> How interesting. Since you and MDC both say this, I only need one more
> person to tell me this for it to be a fact ("What I tell you 3 times is
> true."). I was aware of the PDP-11, but no one ever mentioned that the
> DEC 10 was the PDP-10.

This page

  http://www.montagar.com/dfwcug/VMS_HTML/timeline/1971-2.htm

seems to imply that DECsystem-10 and PDP-10 are different beasts.  The
following page

  http://www.dsi.uminho.pt/museuv/framedec3.htm

states that the DECsystem-10 was initially called PDP-10.  And here's
a quote from the Jargon file:


|  PDP-20 n.     The most famous computer that never was.  {PDP-10}
|  computers running the {{TOPS-10}} operating system were labeled
|  `DECsystem-10' as a way of differentiating them from the PDP-11.
|  Later on, those systems running {TOPS-20} were labeled `DECSYSTEM-20'
|  (the block capitals being the result of a lawsuit brought against DEC by
|  Singer, which once made a computer called `system-10'), but contrary to
|  popular lore there was never a `PDP-20'; the only difference between
|  a 10 and a 20 was the operating system and the color of the paint.
|  Most (but not all) machines sold to run TOPS-10 were painted `Basil
|  Blue', whereas most TOPS-20 machines were painted `Chinese Red' (often
|  mistakenly called orange).

Re: 6-bit characters (was: Re: Streams in Ada)

[Marin David Condic]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87d7atkgrv.fsf@deneb.enyo.de...
> This page
>
>   http://www.montagar.com/dfwcug/VMS_HTML/timeline/1971-2.htm
>
Ooooooooohhhhhhhhhh!!!!!! Front-pannel switches and blinking lights! I feel
so nostalgic.


> seems to imply that DECsystem-10 and PDP-10 are different beasts.  The
> following page
>
I didn't get that impression. Just that "DECsystem-10" grew from "PDP-10" -
that it was mostly a naming issue & not one of any real fundamental
difference. There may be some technical distinction, but it seems of little
consequence. Same processor. Same instruction set. Maybe some evolutionary
differences, but that's true of all significant systems over time. (How long
have you been able to buy a "Ford Thunderbird"?)


> |  PDP-20 n.     The most famous computer that never was.  {PDP-10}
> |  computers running the {{TOPS-10}} operating system were labeled
> |  `DECsystem-10' as a way of differentiating them from the PDP-11.
> |  Later on, those systems running {TOPS-20} were labeled `DECSYSTEM-20'
> |  (the block capitals being the result of a lawsuit brought against DEC
by
> |  Singer, which once made a computer called `system-10'), but contrary to
> |  popular lore there was never a `PDP-20'; the only difference between
> |  a 10 and a 20 was the operating system and the color of the paint.
> |  Most (but not all) machines sold to run TOPS-10 were painted `Basil
> |  Blue', whereas most TOPS-20 machines were painted `Chinese Red' (often
> |  mistakenly called orange).

As I recall, the University of Chicago had a DECSYSTEM-20 - but I never
actually got to touch it. What I saw of the data on it tended to indicate
that it used the same KL-10 processor as the DECsystem-10. (KA, KI & KL were
the iterations of the processor I remember.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: 6-bit characters (was: Re: Streams in Ada)

[Tucker Taft]

Marin David Condic wrote:
> ...
> I didn't get that impression. Just that "DECsystem-10" grew from "PDP-10" -
> that it was mostly a naming issue & not one of any real fundamental
> difference. There may be some technical distinction, but it seems of little
> consequence. Same processor. Same instruction set. Maybe some evolutionary
> differences, but that's true of all significant systems over time. (How long
> have you been able to buy a "Ford Thunderbird"?)
> 
> > |  PDP-20 n.     The most famous computer that never was.  {PDP-10}
> > |  computers running the {{TOPS-10}} operating system were labeled
> > |  `DECsystem-10' as a way of differentiating them from the PDP-11.
> > |  Later on, those systems running {TOPS-20} were labeled `DECSYSTEM-20'
> > |  (the block capitals being the result of a lawsuit brought against DEC
> by
> > |  Singer, which once made a computer called `system-10'), but contrary to
> > |  popular lore there was never a `PDP-20'; the only difference between
> > |  a 10 and a 20 was the operating system and the color of the paint.
> > |  Most (but not all) machines sold to run TOPS-10 were painted `Basil
> > |  Blue', whereas most TOPS-20 machines were painted `Chinese Red' (often
> > |  mistakenly called orange).
> 
> As I recall, the University of Chicago had a DECSYSTEM-20 - but I never
> actually got to touch it. What I saw of the data on it tended to indicate
> that it used the same KL-10 processor as the DECsystem-10. (KA, KI & KL were
> the iterations of the processor I remember.)

The major difference between the DECSystem-20 
and the DECSystem-10 had to do with memory management.
The DECSystem-20 had a better virtual memory
capability than the '10.  Tops-20, the operating system
for the '20, was based on the "Tenex" operating system
developed by BBN, which also pioneered the fancier 
virtual memory hardware for the '10/'20 line.  TOPS-10
was the inspiration for the original CP/M-80 which grew
up (?) into MS-DOS and then Windows.  Tenex/Tops-20 was
the inspiration for Vax/VMS, and might be called the "CISC"
of the operating system world, where Unix/Linux is the "RISC."
It is interesting that the Tenex-Vax/VMS thread joined the
Tops10-MS-DOS thread in Windows-NT (the worst of RISC
and CISC all wrapped up in one baroque mess ;-).

> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/

-- 
-Tucker Taft   stt@avercom.net   http://www.averstar.com/~stt/
Chief Technology Officer, AverCom Corporation (A Titan Company) 
Burlington, MA  USA (AverCom was formerly the Commercial Division of AverStar:
http://www.averstar.com/services/ebusiness_applications.html)

Re: 6-bit characters (was: Re: Streams in Ada)

[Marin David Condic]

Well, I don't know that I can speak for (ex)Digital Equipment Corp as to how
they went about naming things, but IIRC, the "DECSystem-10" referred to the
whole ball of wax, (processors, disks, etc.) whereas the PDP-10 designated
the processor. (PDP = Programmable Data Processor?) They had at one time a
tripple-processor configuration (Western Michigan University was the first
to get one!) so the distinction between DEC-10 and PDP-10 had some reality.
Still, it was essentially talking about the same thing.

As for SOS - I used that one too - much moreso than TECO. But the one thing
you couldn't do with SOS was edit a file on a magnetic tape drive. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3AC9FD54.47CF0136@boeing.com...
> How interesting. Since you and MDC both say this, I only need one more
> person to tell me this for it to be a fact ("What I tell you 3 times is
> true."). I was aware of the PDP-11, but no one ever mentioned that the
> DEC 10 was the PDP-10.
>
> The DEC 10 was supposed to be able to handle 100 users simultaneously.
> Boy, was it slow.
>
> BTW, I didn't use TECO on the DEC 10; I used SOS.
>

Re: 6-bit characters (was: Re: Streams in Ada)

[Robert A Duff]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> The DEC 10 was supposed to be able to handle 100 users simultaneously.
> Boy, was it slow.

The Simula-67 compiler on that machine could compile something like
70,000 lines per minute, which rivals some modern-day compilers on
modern machines.  Sigh.

> BTW, I didn't use TECO on the DEC 10; I used SOS.

I used SOS, too, until I learned about Emacs, which was written in TECO!
(at that time)

- Bob

Re: 6-bit characters (was: Re: Streams in Ada)

[Marin David Condic]

The DEC-10 is the PDP-10. The Sixbit stuff was sort of a throwback to an
earlier age by the time I started using it. Most stuff rather quickly
migrated to 7-bit ASCII, but there were still lots of things that had their
history in Sixbit. Not so much that Sixbit got used regularly - just that at
one time it did, so lots of aspects of the machine and its software were
colored by it.

MDC

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3AC8F892.87B56B74@boeing.com...
> I've never used the PDP-10, but ...
>
> I learned to program in Fortran 66 (IV) on a CDC 6400 with 60-bit words.
> It used a 6-bit character set, so 10H fit into one word. The next
> machine I used was a DEC 10 with TOPS-10. It had 36-bit words, but I
> never encountered 6-bit characters on it; 7-bit ASCII IIRC.
>
> Jeffrey Carter

Re: Streams in Ada

[Larry Kilgallen]

In article <wccg0frw5se.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> 
>> The PDP-10 was more closely oriented to "Sixbit" characters. (Or
>> "Half-ASCII" - basically ASCII with the lower case & some other stuff gone.)
>> IIRC, the Tops-10 OS had the 6x3 file name restrictions basically because it
>> would make filenames fit with Sixbit & into even multiples of machine words.
> 
> This is more a property of Tops-10 than the PDP-10 hardware.
> 
> The hardware supported "bytes", which could be from 1 to 36 bits each --
> there's nothing special about 6-bit bytes.

6-bit bytes were adequate to meet the needs of the time.
As I recall, ITS (Incompatible Timesharing System), which
predated Tops-10, used 6x6 filenames.

Re: Streams in Ada

[Marin David Condic]

If we don't watch it, we're going to start those "Old Guys" stories. :-)
Like finding out what typing your name as a command string to TECO would do.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:5FW3+dkM46AZ@eisner.encompasserve.org...
> In article <wccg0frw5se.fsf@world.std.com>, Robert A Duff
<bobduff@world.std.com> writes:
> > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> >
> >> The PDP-10 was more closely oriented to "Sixbit" characters. (Or
> >> "Half-ASCII" - basically ASCII with the lower case & some other stuff
gone.)
> >> IIRC, the Tops-10 OS had the 6x3 file name restrictions basically
because it
> >> would make filenames fit with Sixbit & into even multiples of machine
words.
> >
> > This is more a property of Tops-10 than the PDP-10 hardware.
> >
> > The hardware supported "bytes", which could be from 1 to 36 bits each --
> > there's nothing special about 6-bit bytes.
>
> 6-bit bytes were adequate to meet the needs of the time.
> As I recall, ITS (Incompatible Timesharing System), which
> predated Tops-10, used 6x6 filenames.

Re: Streams in Ada

[Robert A Duff]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> In article <wccg0frw5se.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> > "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> > 
> >> The PDP-10 was more closely oriented to "Sixbit" characters. (Or
> >> "Half-ASCII" - basically ASCII with the lower case & some other stuff gone.)
> >> IIRC, the Tops-10 OS had the 6x3 file name restrictions basically because it
> >> would make filenames fit with Sixbit & into even multiples of machine words.
> > 
> > This is more a property of Tops-10 than the PDP-10 hardware.
> > 
> > The hardware supported "bytes", which could be from 1 to 36 bits each --
> > there's nothing special about 6-bit bytes.
> 
> 6-bit bytes were adequate to meet the needs of the time.
> As I recall, ITS (Incompatible Timesharing System), which
> predated Tops-10, used 6x6 filenames.

You seem to be implying that "bytes" are always used to represent
"characters".  On the PDP-10, 6-bit bytes were used to represent 6-bit
characters, and 7-bit bytes were used to represent 7-bit ASCII, and
1-bit bytes were used to represent booleans, and 3-bit bytes were used
to represent enumeration types with 8 values, and so on.

- Bob

Re: Streams in Ada

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> I think you meant, "all possible Ada implementations", which I would
> disagree with.

Do impossible Ada implementations exist? ;-)

> On the other hand, if we were to interpret this to say "on all
> likely implementations", I could agree with you. I'll leave it up to
> others how likely a conforming Ada95 PDP-10 implementation is.

I think if you're after practical portability, the PDP-10 doesn't
matter to you.

> Out of curiosity, what exactly constituted a "byte" on a PDP-10?

According to http://www.inwap.com/pdp10/hbaker/pdp-10/Byte.html, the
smallest individually addressable storage unit is a bit, so with a
common definition of a byte, it consists of a single bit. ;-)

If I were writing an Ada compiler for the PDP-10, I would probably
choose Storage_Element'Size = 9.  IIRC, the GCC porters are doing a
similar thing (CHAR_BITS == 8).

Re: Streams in Ada

[Robert A Duff]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:

> Ted Dennison<dennison@telepath.com> writes:
> 
> > I think you meant, "all possible Ada implementations", which I would
> > disagree with.
> 
> Do impossible Ada implementations exist? ;-)

No, but some possible Ada implementations don't exist.  ;-)

> > On the other hand, if we were to interpret this to say "on all
> > likely implementations", I could agree with you. I'll leave it up to
> > others how likely a conforming Ada95 PDP-10 implementation is.
> 
> I think if you're after practical portability, the PDP-10 doesn't
> matter to you.

True, but the principle of writing byte-size-independent code is still
often a good idea.  It's just as easy to be portable to the PDP-10 as to
any other machine that has "unusual" Storage_Units.

> > Out of curiosity, what exactly constituted a "byte" on a PDP-10?
> 
> According to http://www.inwap.com/pdp10/hbaker/pdp-10/Byte.html, the
> smallest individually addressable storage unit is a bit, so with a
> common definition of a byte, it consists of a single bit. ;-)

Well, sort of.  You could address a single bit with a "byte pointer".
But a normal machine address addressed a 36-bit word.  I believe machine
addresses are more efficient.

> If I were writing an Ada compiler for the PDP-10, I would probably
> choose Storage_Element'Size = 9.

Sounds like a bad idea to me.  Storage_Element'Size should be 36 on the
PDP-10.  I believe anything else would be unnecessarily inefficient.

>...IIRC, the GCC porters are doing a
> similar thing (CHAR_BITS == 8).

That's because of various problems with the C language, which don't
exist in Ada.  C has no packed arrays, for example.  Plus the fact that
C culture has grown up in such a way that there's a huge amount of code
that implicitly assumes that char is 8 bits.

In another newsgroup, I recently read a nice quote from G B Shaw that
seems apropos:  "He is a barbarian who thinks the customs of his tribe
are natural laws."

- Bob

Re: Streams in Ada

[Marin David Condic]

As I understand the notion of Storage_Element, they rather intended for this
to correspond to whatever the hardware would normally reference with a
machine address and pull off the bus. The fact that there may be
instructions that let you pick apart that chunk of stuff you pulled from the
bus wouldn't be a consideration because you'd be looking for the machine's
most efficient means of referencing data. Hence, even though the PDP-10
could easily disect the 36 bit words, you'd still want Storage_Element to be
36 bits because that was the smallest chunk of data you could extract from
main memory. (IIRC, it was an 18 bit address, right? And I *do* remember
using 7 bit ASCII with one bit left over! :-)

So this hypothetical Ada95 compiler would use 36 bits to store a character
or array of characters? You'd have to use packing or other representation
clauses to get the characters into a single word? Hmmmmmmm....... That would
probably provide all sorts of ammunition for the Anti-Ada-Zealots.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccae5zw4hm.fsf@world.std.com...
>
> Sounds like a bad idea to me.  Storage_Element'Size should be 36 on the
> PDP-10.  I believe anything else would be unnecessarily inefficient.
>

Re: Streams in Ada

[Robert A Duff]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

>...(IIRC, it was an 18 bit address, right? ...

Right.  Later models had some sort of segmentation mechanism to increase
the address space (was it called "extended addressing", maybe?).

> So this hypothetical Ada95 compiler would use 36 bits to store a character
> or array of characters?

By default, yes.  I think that's what you want: default behavior is fast
array indexing, and if you want tighter packing, say pragma Pack.
This is what we do on one of our targets that happens to have 32-bit
storage units.

It's no different than an array of Booleans on a more typical machine --
you have to say pragma Pack if you want 1 bit per component.

>... You'd have to use packing or other representation
> clauses to get the characters into a single word? Hmmmmmmm....... That would
> probably provide all sorts of ammunition for the Anti-Ada-Zealots.

Shrug.  The programmer gets the choice.  And there's no pragma
Dont_Pack, so it's pretty clear what the default ought to be.

And would these Anti-Ada-Zealots perhaps prefer a language such as C,
where there *is* no such choice?

Note that the predefined String type has pragma Pack, so you would get 4
characters per word, with 4 bits per word wasted.

- Bob

Re: Streams in Ada

[Florian Weimer]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> As I understand the notion of Storage_Element, they rather intended for this
> to correspond to whatever the hardware would normally reference with a
> machine address and pull off the bus.

According to this definition, Storage_Element'Size would have to be
256. :-/

> The fact that there may be instructions that let you pick apart that
> chunk of stuff you pulled from the bus wouldn't be a consideration
> because you'd be looking for the machine's most efficient means of
> referencing data. Hence, even though the PDP-10 could easily disect
> the 36 bit words, you'd still want Storage_Element to be 36 bits
> because that was the smallest chunk of data you could extract from
> main memory.

This would imply that Storage_Element'Size should equal 64 with
generic Alpha targets.  I don't think many vendors implement this.

Re: Streams in Ada

[Marin David Condic]

I suppose that may be what it would be if you thought of the *LARGEST*
addressable unit - but going the other direction is I think what was
intended. AFAIK, Alphas will address a single byte - even if it isn't the
most optimal use of the bus. Whereas, the PDP-10 would only address a 36 bit
word as the smallest element it would extract from memory. The rest of the
operations for smaller sized units would disect the word after it was
fetched.

I doubt we'd have to consider various possible hardware schemes as part of
the issue. Only the instruction set.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:87g0fqpa4b.fsf@deneb.enyo.de...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > As I understand the notion of Storage_Element, they rather intended for
this
> > to correspond to whatever the hardware would normally reference with a
> > machine address and pull off the bus.
>
> According to this definition, Storage_Element'Size would have to be
> 256. :-/
>
> > The fact that there may be instructions that let you pick apart that
> > chunk of stuff you pulled from the bus wouldn't be a consideration
> > because you'd be looking for the machine's most efficient means of
> > referencing data. Hence, even though the PDP-10 could easily disect
> > the 36 bit words, you'd still want Storage_Element to be 36 bits
> > because that was the smallest chunk of data you could extract from
> > main memory.
>
> This would imply that Storage_Element'Size should equal 64 with
> generic Alpha targets.  I don't think many vendors implement this.

Re: Streams in Ada

[Florian Weimer]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> I suppose that may be what it would be if you thought of the *LARGEST*
> addressable unit - but going the other direction is I think what was
> intended.

No, the smallest unit which ordinarily hits the memory bus on the
message I'm typing is 32 octets -- a cache line. ;-)

> AFAIK, Alphas will address a single byte

In standardeese, you're correct (a byte is commonly defined as the
smallest addressable storage unit), but if you mean a single octet,
I don't think so, AFAIK, the original Alpha CPU doesn't have this
feature.  (Modern CPUs which also can operate in a PC-like environment
probably have octet) Can anyone shed some light on this issue?

Re: Streams in Ada

[Robert A Duff]

Florian Weimer <fw@deneb.enyo.de> writes:

> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> 
> > I suppose that may be what it would be if you thought of the *LARGEST*
> > addressable unit - but going the other direction is I think what was
> > intended.
> 
> No, the smallest unit which ordinarily hits the memory bus on the
> message I'm typing is 32 octets -- a cache line. ;-)
> 
> > AFAIK, Alphas will address a single byte
> 
> In standardeese, you're correct (a byte is commonly defined as the
> smallest addressable storage unit),

Perhaps nowadays, but in the old days, that wasn't true.  People talked
about "byte addressable", meaning you can address bytes (whatever that
means -- 8 bits?  something smaller than a word?).

>... but if you mean a single octet,
> I don't think so, AFAIK, the original Alpha CPU doesn't have this
> feature.  (Modern CPUs which also can operate in a PC-like environment
> probably have octet) Can anyone shed some light on this issue?

An address on the Alpha points to a single octet (8-bit byte).  The
original Alpha had no instructions for loading a byte, but I would still
call it an "addressable unit".  So on Alpha, an Ada compiler ought to
define:

    Storage_Unit = 8
    Word_Size = 64

- Bob

Re: Streams in Ada

[Florian Weimer]

Robert A Duff <bobduff@world.std.com> writes:

> > If I were writing an Ada compiler for the PDP-10, I would probably
> > choose Storage_Element'Size = 9.
> 
> Sounds like a bad idea to me.  Storage_Element'Size should be 36 on the
> PDP-10.  I believe anything else would be unnecessarily inefficient.

Are you sure?  There are quite a few Ada compilers out there which use
Storage_Element'Size = 8 even though it's inefficient on that
particular platform.  I think the size of a storage element is pretty
irrelevant for efficiency concerns.

> >...IIRC, the GCC porters are doing a
> > similar thing (CHAR_BITS == 8).

Oops, CHAR_BITS == 9 of course.
 
> That's because of various problems with the C language, which don't
> exist in Ada.  C has no packed arrays, for example.  Plus the fact that
> C culture has grown up in such a way that there's a huge amount of code
> that implicitly assumes that char is 8 bits.

An 8 bit char on a PDP-10 doesn't work.  Only values which are
divisors of 36 are acceptable.

Re: Streams in Ada

[Robert A Duff]

Florian Weimer <fw@deneb.enyo.de> writes:

> Robert A Duff <bobduff@world.std.com> writes:
> 
> > > If I were writing an Ada compiler for the PDP-10, I would probably
> > > choose Storage_Element'Size = 9.
> > 
> > Sounds like a bad idea to me.  Storage_Element'Size should be 36 on the
> > PDP-10.  I believe anything else would be unnecessarily inefficient.
> 
> Are you sure?

No.

>...  There are quite a few Ada compilers out there which use
> Storage_Element'Size = 8 even though it's inefficient on that
> particular platform.

Which machines?  I've never heard of such a thing.

>...I think the size of a storage element is pretty
> irrelevant for efficiency concerns.

Well, maybe I misunderstood.  I was presuming that if
Storage_Element'Size = 8, then the compiler behaves accordingly (eg,
for laying out arrays).  *That's* what would affect efficiency.
I guess it's true that Storage_Element'Size in and of itself is
irrelevent unless you're using 'Address and related stuff.

> > >...IIRC, the GCC porters are doing a
> > > similar thing (CHAR_BITS == 8).
> 
> Oops, CHAR_BITS == 9 of course.
>  
> > That's because of various problems with the C language, which don't
> > exist in Ada.  C has no packed arrays, for example.  Plus the fact that
> > C culture has grown up in such a way that there's a huge amount of code
> > that implicitly assumes that char is 8 bits.
> 
> An 8 bit char on a PDP-10 doesn't work.  Only values which are
> divisors of 36 are acceptable.

I don't see why.  The PDP-10 hardware can deal with 8-bit bytes just
fine (although you waste approx 1/9 of the bits).  Is there some
subtlety of C I'm missing?

Or do I have to say you waste 1.0/9.0 of the bits?  ;-)

- Bob

Re: Streams in Ada

[Florian Weimer]

Robert A Duff <bobduff@world.std.com> writes:

> >...  There are quite a few Ada compilers out there which use
> > Storage_Element'Size = 8 even though it's inefficient on that
> > particular platform.
> 
> Which machines?  I've never heard of such a thing.

IIRC, in the AI dealing with 13.13.2(17), some vendor(s) claimed that
the current IA is inappropriate because it results in inefficient code
if a character is written to a stream because it has to be represented
in 8 bits.

With Storage_Element'Size, this isn't such a big concern, I think,
because usually, you can add all kinds of padding to make the
in-memory representation efficient.

> > An 8 bit char on a PDP-10 doesn't work.  Only values which are
> > divisors of 36 are acceptable.
> 
> I don't see why.  The PDP-10 hardware can deal with 8-bit bytes just
> fine (although you waste approx 1/9 of the bits).  Is there some
> subtlety of C I'm missing?

In C, each object must be representable as a sequence of bytes (i.e.
char values).  If you use 8-bit chars, words can only consist of 32
bits, not 36 bits.  So you have to run the PDP-10 in some kind of
32-bit mode.  As a result, you probably can't write system code in C.

Re: Streams in Ada

[Marin David Condic]

"Florian Weimer" <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message
news:tgofufwd4x.fsf@mercury.rus.uni-stuttgart.de...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
>
> > But wouldn't that posit that there *was* an Ada95 implementation on a
PDP-10
> > and that a Stream_Element was 36 bits?
>
> Well, the poster specifically mentioned portability, and his code does
> not work on such an architecture.  IMHO, portable code hasn't just to
> run on all platforms which exist (this could be called 'practically
> portable code'), but on all Ada implementations.
>
O.K. That's a valid point. But the instant one delves into the theoretically
possible machines, one can spend an enormous amount of energy making code
that is portable to all possible machines, when maybe it is sufficient to
make code that is portable to most machines that are in practical existence.

While there are machines that don't have an 8 bit byte as the logical
storage unit for a Stream_Element (the 1750a comes to mind...:-) and there
are machines that don't even have a storage unit evenly divisible by 8 (the
PDP-10 is a prime example) code that was dependent on an 8 bit storage unit
& Stream_Element is probably going to port to well over 90% of all the
places that are likely to come up or be at all important. Of course, if all
you have to do is a little simple static math in your declarations to keep
things totally portable, its probably worth the effort.

> > Someone mentioned here a few days ago about the existence of PDP-10
> > look-alikes, but I don't think anyone has any evidence of a validated
Ada95
> > compiler for one of them.
>
> GCC is currently being ported to it.

This has *got* to be a labor of love! I find it hard to imagine that there
are thousands (or even hundreds) of PDP-10 sites out there, much less
thousands (or even hundreds) of PDP-10 sites with a burning need for Ada
compilers. (Wouldn't they mostly be in use to maintain legacy systems
written in Fortran, Cobol, or even Bliss?) Either it is a real specialty
need (with the government picking up the tab?) or it is an idle, Quixotic,
excentric programmer with too much time & money on his hands - or a twisted
sense of humor. (Ahhhh.... To be an idle Quixotic excentric programmer with
too much time & money & a twisted sense of humor and a government contract
to pick up the tab! But I digress....) If someone is doing this, I'd be very
curious to find out where & what for.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Streams in Ada

[David Thompson]

Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote :
> Someone mentioned here a few days ago about the existence of PDP-10
> look-alikes, but I don't think anyone has any evidence of a validated Ada95
> compiler for one of them. It would sure make me nostalgic to have access to
> a PDP-10 for a while & write some programs for it again. (Hmmmmmmm.......
> Maybe I'll get started writing a simulator for it, just for fun & to use up
> all that spare time I have..... :-)

There are two active efforts to write -10 simulators that
have been discussed (extensively) on alt.sys.pdp10
over the past few months, one by Bob Supnik and
one by Timothy Stark, which seem to "nearly" work --
i.e. at this point much of the discussion is along the lines
of "I can boot TOPS-10 and create a filesystem but
running a system utility program XX faults at YY --
was this a bug in the actual program (even on a real -10)
or am I running it wrong (and discussants try to remember
amazingly arcane details of how to use TOPS-10 features,
or those of the KL10 front-end or diagnostic programs)
or is it a very narrow bug in the simulator".

There are also a couple of folks who pop up from time to time
apparently working on an FPGA hardware implementation
(AIR in VHDL) but have not announced any real results.

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote :
> GCC is currently being ported to it.

By Lars Brinkhoff sponsored by XKL, makers of one workalike.
So it may eventually be possible to compile and run a -10 emulator
(both now written AIUI in Unix-flavored C) on an emulated -10!

--
- David.Thompson 1 now at worldnet.att.net

Re: Streams in Ada

[James Rogers]

I assume from your use of the term "streams" that you want to be able
to directly address file elements. "Streams" is the C term for such
capability. Ada uses streams for a somewhat different capability.

I believe what you want is handled by the package Ada.Direct_Io.

Look in the Ada Reference Manual, Appendix A, for details on this
package.

Jim Rogers
Colorado Springs, Colorado USA

"chris.danx" wrote:
> 
> Hi,
>     I've looked about for examples on streams in Ada.  I'm writing an
> virtual file system as a file on disk, and want to use streams.  I have to
> be able to go back and forwards and read large blocks of data from the file
> at random positions.  I have tried to locate an example of using streams but
> couldn't find any that didn't deal with sequential access.
> 
> the first block is 512 bytes and inodes are 64bytes.  then i have a set of
> blocks which are 16bytes long.  you can see now why i'm using streams, but i
> can't seem to work out from the ref manual and Barnes what i should do.  I
> recall the ref manual saying index is relative to stream element but i don't
> know what it means.  Anyone know of a good example?
> 
> Thanks in advance,
> Chris Campbell

Re: Streams in Ada

[chris.danx]

Direct IO handles single type files, i.e. all file elements are the same.  I
want different types in the file i.e. heterogeneous files.  Streams allow
this so i need streams.

I want to allow the reading and writing of 3 or 4 types.

    type Superblock_type;
    type Inode_type;
    type Data_block_type;
    type FileInfo_block_type;

surely then i want streams.  I did think about direct io but i'd have severe
performance losses in the conversion to the smallest unit -- in this case
byte_type;  Maybe i am looking in the wrong place.

All i want is an example of how to access files using streams in a non
sequential manner with one or two types.

Cheers,
Chris Campbell

Re: Streams in Ada

[chris.danx]

"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:XRrx6.7012$u93.987018@news6-win.server.ntlworld.com...
> Direct IO handles single type files, i.e. all file elements are the same

Typo! Sorry!  Should be

Direct IO handles single type files, i.e. all file elements are the same
type.

Re: Streams in Ada

[David C. Hoos, Sr.]

Stream_Elements are the smallest addressable element of the medium
usually an octet (8 bits).

The Index (position) of a stream file can be read using the function
Ada.Streams.Stream_IO.Index, and the index can be set using the
procedure Ada.Streams.Stream_IO.Set_Index.

The first index of a file is 1.

Read and write operations are automatically declared for
every type you declare, so you can just call Superblock_type'Read,
Superblock_type'Write, etc. when the file index is appropriately
positioned.

The 'Read and "write procedures defined by the compiler follow
certain rules which may not be appropriate for some types you
could declare. For example, if a record has elements that do not
begin and end on byte boundaries, you can override the compiler-
defined procedures with your own.

Here is an example of such a type, where a 32-bit record has a
31-bit component, and a 1-bit component.

-- Part of package specification:
with Ada.Streams;
   .
   .
   .
   type An_Hour_Fraction is
     delta 3600.0 * 2.0 ** (-31) range 0.0 .. 3600.0;
   for An_Hour_Fraction'Small use 3600.0 * 2.0 ** (-31);
   for An_Hour_Fraction'Size use 31;
   type A_Time_Stamp_Kind is (Relative, Absolute);
   for A_Time_Stamp_Kind use (Relative => 0, Absolute => 1);
   for A_Time_Stamp_Kind'Size use 1;

   type A_Time_Stamp is
      record
         Seconds : An_Hour_Fraction;
         Kind : A_Time_Stamp_Kind;
      end record;
   for A_Time_Stamp use
      record
         Seconds at 0 range 0 .. 30;
         Kind at 0 range 31 .. 31;
      end record;
   for A_Time_Stamp'Size use 32;

private
   procedure Read_Time_Stamp
               (Stream : access Ada.Streams.Root_Stream_Type'Class;
                Item : out A_Time_Stamp);

   procedure Write_Time_Stamp
               (Stream : access Ada.Streams.Root_Stream_Type'Class;
                Item : in A_Time_Stamp);
   for A_Time_Stamp'Read use Read_Time_Stamp;
   for A_Time_Stamp'Write use Write_Time_Stamp;




-- Part of package body:
 with Ada.Unchecked_Conversion;
with Interfaces;
   .
   .
   .
   function To_Time_Stamp is new Ada.Unchecked_Conversion
     (Source => Interfaces.Unsigned_32,
      Target => A_Time_Stamp);

  function To_Unsigned_32 is new Ada.Unchecked_Conversion
     (Source => A_Time_Stamp,
      Target => Interfaces.Unsigned_32);

    procedure Read_Time_Stamp
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Item : out A_Time_Stamp) is
   begin
     Item := To_Time_Stamp (Interfaces.Unsigned_32'Input (Stream));
  end Read_Time_Stamp;

    procedure Write_Time_Stamp
     (Stream : access Ada.Streams.Root_Stream_Type'Class;
      Item : in A_Time_Stamp) is
   begin
      Interfaces.Unsigned_32'Write
        (Stream,
         To_Unsigned_32 (Item));
   end Write_Time_Stamp;


"chris.danx" <chris.danx@ntlworld.com> wrote in message
news:XRrx6.7012$u93.987018@news6-win.server.ntlworld.com...
> Direct IO handles single type files, i.e. all file elements are the same.
I
> want different types in the file i.e. heterogeneous files.  Streams allow
> this so i need streams.
>
> I want to allow the reading and writing of 3 or 4 types.
>
>     type Superblock_type;
>     type Inode_type;
>     type Data_block_type;
>     type FileInfo_block_type;
>
> surely then i want streams.  I did think about direct io but i'd have
severe
> performance losses in the conversion to the smallest unit -- in this case
> byte_type;  Maybe i am looking in the wrong place.
>
> All i want is an example of how to access files using streams in a non
> sequential manner with one or two types.
>
> Cheers,
> Chris Campbell
>
>

Re: Streams in Ada

[chris.danx]

Thank you, it' appreciated,
Chris Campbell

Re: Streams in Ada

[Ted Dennison]

In article <XRrx6.7012$u93.987018@news6-win.server.ntlworld.com>, chris.danx
says...
>
>Direct IO handles single type files, i.e. all file elements are the same.  I
>want different types in the file i.e. heterogeneous files.  Streams allow
>this so i need streams.
>
>I want to allow the reading and writing of 3 or 4 types.
>
>    type Superblock_type;
>    type Inode_type;
>    type Data_block_type;
>    type FileInfo_block_type;
>
>surely then i want streams.  I did think about direct io but i'd have severe
>performance losses in the conversion to the smallest unit -- in this case
>byte_type;  Maybe i am looking in the wrong place.

Just a bit of advice. You could just do a "Superblock_Type'Read (...)" when
reading one of these objects from the stream file. However, that will cause one
Ada.Streams.Read call for each and every component in Superblock_Type. What
would be much quicker would be to create your own 'Read routine for
Superblock_Type, which makes only one call to Ada.Streams.Read for the entire
structure. Its a bit more work though, and has to be debugged, so you should
weigh that against your desire for quicker reads.

As an example of this, we used streams in a real-time simulation I'm working on
to save all the model data for a possible simulation restore later. For most of
the models we found no performance problem with just taking the default 'Read
and 'Write. However, the I/O models have significantly more data than other
models, and run at the highest rate. They were taking so much time to complete
the operation (about 20ms) that the simulation could do nothing else but save IO
data. Rewriting their 'Write and 'Read brought the time down into the trivial
level (about 100ns).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Streams in Ada

[Ted Dennison]

In article <3AC64324.A79AE084@worldnet.att.net>, James Rogers says...
>
>I assume from your use of the term "streams" that you want to be able
>to directly address file elements. "Streams" is the C term for such
>capability. Ada uses streams for a somewhat different capability.
>
>I believe what you want is handled by the package Ada.Direct_Io.

Actually, this sounds like the exact issue we've talked about twice in the last
couple of months already. You generally don't want to use Direct_IO instantiated
for byte-sized objects, as there will be a call for each and every byte read,
which is going to be really slow (and make your Ada code look bad). If there is
only a couple of sizes to read, you might be able to get away with a separate
Direct_IO instantiation for each, but there will still be a bit of waste closing
one instantiation's view of the file so the other can open it and reposition to
the right place.

The best way to solve the problem of reading an unstructured array of bytes from
a file in Ada is to use Ada.Streams.Stream_IO, along with a direct call to
Ada.Streams.Read with a properly-sized array of stream elements. 

Didn't someone volunteer to put some example sources for doing this on AdaPower?
I can post some code I have that does this, if needed. (hmmm, assuming I didn't
delete it last week...) The speedup I observed in doing it this way vs.
Sequential_IO was nothing less than amazing.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Streams in Ada

[Brian Gaffney]

Robert A Duff wrote:
> 
> Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:
> 
> > Ted Dennison<dennison@telepath.com> writes:
> >
> > > I think you meant, "all possible Ada implementations", which I would
> > > disagree with.
> >
> > Do impossible Ada implementations exist? ;-)
> 
> No, but some possible Ada implementations don't exist.  ;-)
> 
Are you sure?  Isn't there a current _very_ long thread about a current 
'impossible' Ada implementation :-)?  Oops, that's an Ada compiler/tool
set, sorry.

Seriously, shouldn't the Storage_Unit refer to the addressable unit on 
the machine?  For example, on a machine with 32-bit addressing, does the
potential address space cover 2**32 8-bit bytes, 32-bit words, or
256-bit 
cache-words?  I would think most machines are byte-addressable,
therefore
Storage_Unit should be 8.  On machines we use, we have a 16-bit address 
space and can reference 2**16 16-bit half-words.  Therefore Storage_Unit
would be 16 (assuming an Ada compiler existed, HA!), even though 8-bit 
bytes and 32-bit words can be referenced.

Just my thoughts.

						--Brian

Re: Streams in Ada

[Robert A Duff]

Brian Gaffney <b_gaffney@deja.com> writes:

> Robert A Duff wrote:
> > 
> > Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:
> > 
> > > Ted Dennison<dennison@telepath.com> writes:
> > >
> > > > I think you meant, "all possible Ada implementations", which I would
> > > > disagree with.
> > >
> > > Do impossible Ada implementations exist? ;-)
> > 
> > No, but some possible Ada implementations don't exist.  ;-)
> > 
> Are you sure?

Yes, I'm quite sure that some possible Ada implementations do not (yet?)
exist.

>....  Isn't there a current _very_ long thread about a current 
> 'impossible' Ada implementation :-)?  Oops, that's an Ada compiler/tool
> set, sorry.
> 
> Seriously, shouldn't the Storage_Unit refer to the addressable unit on 
> the machine?

Yes.

>..  For example, on a machine with 32-bit addressing, does the
> potential address space cover 2**32 8-bit bytes, 32-bit words, or
> 256-bit 
> cache-words?

I'm not sure what you mean by "32-bit addressing".  If an address points
to an 8-bit quantity, then Storage_Unit = 8.  If it points to a 32-bit
quantity, then Storage_Unit = 32.  It doesn't matter how big an address
is.

The cache has nothing to do with it.  It's the machine architecture that
matters.

>..  I would think most machines are byte-addressable,
> therefore
> Storage_Unit should be 8.

True on most machines, these days.

>...  On machines we use, we have a 16-bit address 
> space and can reference 2**16 16-bit half-words.  Therefore Storage_Unit
> would be 16 (assuming an Ada compiler existed, HA!), even though 8-bit 
> bytes and 32-bit words can be referenced.

How are 8-bit bytes referenced?  If by "load high/low byte pointed to by
address", then yes, Storage_Unit should be 16.

- Bob