[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] binary streams



hi #3,

Michael Riepe wrote:
> Hi #2,
> 
> On Thu, Sep 13, 2001 at 12:52:57AM +0200, Yann Guidon wrote:
> [...]
> > given a text input file, simili will insert 0xD, 0xA pairs
> > for carriage returns. Well, it's a MSDOS thing.
> > Worse : simili "interprets" the input characters and particularly :
> > it stops on a "EOF" character (i don't know which) while
> > Vanilla copies texto the input to the output.
> EOF used to be ^Z (decimal 26); I guess it's still that way.
probably :-)

> > This is not revelant for the text i/O but i want to
> > handle "binary" files, that is : whatever the data is.
> > the different behaviours of the tools almost gave me headaches.
> >
> > anyone can help ?
> 
> That's easy to handle in C -- fopen(file, "rb") should do the trick --
but that's not the problem ;-)

> but I don't know what to do in VHDL.  Perhaps you can do something like
>         type octet is 0 to 255;
>         type octet_stream is file of octet;
i think i tried this already, however i presume that this "subset"
for the "integer" type keeps the 4-byte encoding (the range is only restricted)
so if i read a "byte" i will increment the file counter by four.
i'll try anyway because i better prove it, but it's a gut feeling.

> If it still stops at a ^Z, I would consider that a bug in Simili.
simili and vanilla definitely differ !
> But you'll probably have to write a completely new set of I/O routines
> for the `octet' type.
not necessarily, but if it's necessary, i'll do it.

> On the other hand, binary files are evil anyway because they're not
> portable (imagine you had to transfer them to a big-endian box, like
> SPARC).
in this case (random numbers coming from /dev/random or .tgz files)
it is irrevelant.

>  Better use a `compact' ASCII representation (e.g.  hexadecimal
> numbers).  It will have a 2:1 overhead, but it's portable, and also
> readable/editable by humans.  Another portable and even more compact
> (but unreadable) encoding is base64 (used by MIME, for example).
but it adds another C layer, which has to be compiled etc...
base-16 is ok, easily VHDL-writeable, but not handy, because pipes etc
are not well portable across different platforms.
see what i mean ?

i simply hope there was a byte file support.
i found nothing in Graham's books.

good night,
and thanks for the NCO file.

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/