Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

-byteswapio


Dear all,

I have problem in reading unformatted data in compaq visual fortran
(CVF). I can read that binary data only with linux env by using -
byteswapio. It just simple statement, but It doesn't work anylonger
when I use CVF. I want to read that unformatted data in CVF and I've
tried to combine all intrinsic statements in CVF, but it always
failed. Does any one know how to make READ for unformatted data which
only can be read with using -byteswapio but in CVF environment? (the
data is in 2-D)

Thank you so much.

-r/K-

Dear all,

I have problem in reading unformatted data in compaq visual fortran
(CVF). I can read that binary data only with linux env by using -
byteswapio. It just simple statement, but It doesn't work anylonger
when I use CVF. I want to read that unformatted data in CVF and I've
tried to combine all intrinsic statements in CVF, but it always
failed. Does any one know how to make READ for unformatted data which
only can be read with using -byteswapio but in CVF environment? (the
data is in 2-D)

Thank you so much.

-r/K-

In a previous article, kartadika@gmail.com wrote:
>Dear all,

>I have problem in reading unformatted data in compaq visual fortran
>(CVF). I can read that binary data only with linux env by using -
>byteswapio. It just simple statement, but It doesn't work anylonger
>when I use CVF. I want to read that unformatted data in CVF and I've
>tried to combine all intrinsic statements in CVF, but it always
>failed. Does any one know how to make READ for unformatted data which
>only can be read with using -byteswapio but in CVF environment? (the
>data is in 2-D)

>Thank you so much.

>-r/K-

Here's a shot in the dark, since I don't use linux or CVF.
Look for information on endian or endianness connected with
CVF. Linux (I think) has the most significant byte of
a multi-byte number (e.g. float) stored at the lower
memory address. I don't know about CVF, but if it runs
under Windows, the byte order is probably reversed.

  I think Linux storage  would be called big endian -- but since
a number has 2 ends ... your guess is as good as mine!

 I have made computers very upset by trying to read a big
endian (float) in a windows fortran.  
Chris

m@skyway.usask.ca wrote:

(snip)

> Here's a shot in the dark, since I don't use linux or CVF.
> Look for information on endian or endianness connected with
> CVF. Linux (I think) has the most significant byte of
> a multi-byte number (e.g. float) stored at the lower
> memory address. I don't know about CVF, but if it runs
> under Windows, the byte order is probably reversed.

Endianness mostly depends on the processor not the OS.
(There are bi-endian processors where it does depend
on the OS.)

680x0, SPARC, HPPA, S/370, ESA/390, are some popular
big-endian processors.

x86 is a popular little-endian processor. VAX
(except in floating point) and many eight bit
microprocessors such as 6502, 6800, 8080, 6809,
are also little-endian.

-- glen

-- glen

Yes, endedness defines what happens whan a CPU store a register, local
16/32/64 bit integers or floating-point chip register. If the byte of
lowest significance of the value from the register is stored at the
lowest address of the memory area to be used, then the order is little-
indian (from Gulliver's Travels where two opposing societies cracked
their boiled egs on the big or else little ends, as a semi-religous
principle).

Since memory is almost always automatically written from memory to an
I/O unit in the order low address byte to high address byte, this
affects the tranfer file that someone has to read.

IBM and other mainframes wrote high-to-low significance; micros wrote
the opposite because the early chip designers realised that little-
indian order gave more time for circuits to respond in selecting the
memory block to be used (first ues low address to select ALL like
addresses of ALL the memory blocks, then use the HIGH order address to
trigger the store command to the ONLY block of memory matching the
block address (high order). Only one memory chip got the store command
although all chips hade pre-selected the byte number in the block.

Terence wrote:

(snip)

> IBM and other mainframes wrote high-to-low significance; micros wrote
> the opposite because the early chip designers realised that little-
> indian order gave more time for circuits to respond in selecting the
> memory block to be used (first ues low address to select ALL like
> addresses of ALL the memory blocks, then use the HIGH order address to
> trigger the store command to the ONLY block of memory matching the
> block address (high order). Only one memory chip got the store command
> although all chips hade pre-selected the byte number in the block.

The usual explanation is that it makes it easier to do addition
on 16 bit values, as the carry goes in that direction.  This would
only matter if 16 bit values were stored in memory and used in
addition operations.

The 6502 is even more interesting.  In doing a subroutine call,
it doesn't put the actual return address on the stack, but
one less than the return address.  The return instruction
returns to the right address.

For processors with multiply and divide, it is necessary to
do more complex memory addressing, reducing the advantage.
Big endian is, at least, slightly more natural for humans
to read when printed out, such as in memory dumps.

-- glen

>IBM and other mainframes wrote high-to-low significance; micros wrote
>the opposite because the early chip designers realised that little-
>indian order gave more time for circuits to respond in selecting the
>memory block to be used

little-endian also allows the same address to be used for dword,
low-word and lowest-byte access to the same value, just as ONE
other example.  

There are several reasons why one might choose either big- or
little- endian.  And even a few (weird reasons, to be sure)
why one might choose mixed-endian.

FOR the OP: to read a Linux-Unformatted file on another platform,
endian-ness is but one thing.  The UNFORMATTED file structure is
NOT the same the C's uncooked or raw or "binary" file -- it has
structure, there is just no formatting conversion done when
reading or writing values.  So you may need to diddle with file
structure issues or you may not.  

Since you mention CVF, CVF can open files for reading transparently,
which may be desireable for your application.  Instead of
UNFORMATTED you can use the keyword BINARY for CVF, this is a MSism
that DEC faithfully reproduced when they provided an upgrade path
from the MS Fortrans.

Kevin G. Rhoads wrote:
>>IBM and other mainframes wrote high-to-low significance; micros wrote
>>the opposite because the early chip designers realised that little-
>>indian order gave more time for circuits to respond in selecting the
>>memory block to be used
> little-endian also allows the same address to be used for dword,
> low-word and lowest-byte access to the same value, just as ONE
> other example.  

I consider this a disadvantage for little-endian.  It hides bugs
in passing the wrong type to a subroutine during debugging with
small values.   (This was first explained to me in the context
of PDP-11 Fortran, and the ability to pass INTEGER*4 values to
INTEGER*2 dummy arguments.)

The S/360 addressing modes make it easy to add a small offset.
The PDP-11 makes it a little harder.  Then again, the PDP-11
started the mixed endian floating point format used in VAX.

-- glen

>> little-endian also allows the same address to be used for dword,
>> low-word and lowest-byte access to the same value, just as ONE
>> other example.  

>I consider this a disadvantage for little-endian.  It hides bugs
>in passing the wrong type to a subroutine during debugging with

I would agree with the "bug vs. feature" call on this for any HLL,
I am more mixed about it for assembly.

>and the ability to pass INTEGER*4 values to INTEGER*2 dummy arguments.

What's worse is seeing someone pass INT*2 to INT*4 dummy args and
having it work -- most of the time.

>The S/360 addressing modes make it easy to add a small offset.

Too long since I did BAL, about 4 decades, and the manuals are
all in the attic at my parents house in PA (Yes, I know about
accessing a Green Card on-line). Just like looking over old
CDC-6400 assembly listings and not remembering much of aught.
(e.g., "Now, why was I writing *that*?")

Kevin G. Rhoads wrote:

(snip)

>>I consider this a disadvantage for little-endian.  It hides bugs
>>in passing the wrong type to a subroutine during debugging with
> I would agree with the "bug vs. feature" call on this for any HLL,
> I am more mixed about it for assembly.

Yes, assembly is different.

>>and the ability to pass INTEGER*4 values to INTEGER*2 dummy arguments.
> What's worse is seeing someone pass INT*2 to INT*4 dummy args and
> having it work -- most of the time.

Again, it might work through debugging and not when you
really need it to work.

>>The S/360 addressing modes make it easy to add a small offset.
> Too long since I did BAL, about 4 decades, and the manuals are
> all in the attic at my parents house in PA (Yes, I know about
> accessing a Green Card on-line).

http://www.bitsavers.org/pdf/ibm/360/

except that the Fortran manual is at

http://www.fh-jena.de/~kleine/history/languages/GC28-6515-10-FORTRAN-...

-- glen

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc