about BigEndian and LittleEndian

[Sharon]

hi all,

I generate binary text file (in Windows using Dev-C++)
Is the generated binary file using BigEndian?
Are there any method to generate binary file using LittleEndian?
Because I want the generated binary file to be used in Palm, is it necessary
to do so ?
thanks!

[Mark A. Odell]

Da*****@cern.ch (Dan Pop) wrote in news:bq**********@sunnews.cern.ch:

The Unix semantics is: uninitialised data segment.
Which I always thought was a misnomer as the block is zeroed.

The idea is that there is no image for this segment in the executable
file. It comes already zeroed by the OS, as any piece of memory
obtained from the OS, for obvious security reasons.

I suppose it
means the programmer did not initialize items in this segment.

Anything initialised to all zeroes *by default* gets there.

Yes, of course.
If you
initialise to all zeroes explicitly, the stuff goes into the data
segment and actually increases the executable size. At least, this is
what gcc is doing:

I find this behaviour to be true for many toolchains. I'm for ever
removing the initializer on definitions like:

static int arr[ARR_SIZE] = { 0 };

to keep our image sizes down. I suppose, from an implementor's view, this
is correct although somewhat silly behavior.

--
- Mark ->
--

[CBFalconer]

Chris Dollin wrote:

CBFalconer wrote:

Gene Wirchenko wrote:

<ir*******@freenet.de> wrote:
>"Mr. Ger" <as******@none.none> wrote:
>> > Sharon <sh************@hotmail.com> scribbled the following
>> >
>> >> I generate binary text file (in Windows using Dev-C++)
>> >> Is the generated binary file using BigEndian?
>> >
>> > Mu.
>>
>> Please speak English and not Finnish in English groups please.
>
> 'Mu' (at least in this case) isn't Finnish; it is a Zen reply,
> with the approximate meaning: "The only way to know the answer
> to this question is not asking this question.", or, in short:
> "I am un-asking your question."

Another way it is used is with the meaning: "Your question
assumes something that is not the case, and so is unaswerable."

Or, as has often arisen over the bridge table, at a suitable
point in play:

Nu?

Is that in Nu Trump play?

Not necessarily. Consider the following end position, where the
actual cards are known for one reason or another, and the lead is
with South, Diamonds trumps (or no trumps):

North:
S: x
H: Ax
East: West:
S: A C: xxx
H: KQ
South:
S: x
H: x
D: x

South places the x of D on the table, gazes sweetly upon East, and
clearly enunciates "Nu?". :-)

Note: you may interchange East and West if desired. I can also
construct scenarios that call for two Nus during one trick. For
the defence, no nus is good nus.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[glen herrmannsfeldt]

Dan Pop wrote:

In <sl*******************@hehe.cl.cam.ac.uk> Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:

glen herrmannsfeldt wrote:

Dan Pop wrote:

It's also common Unix terminology:

fangorn:~/tmp 217> size a.out
text data bss dec hex filename
855 220 24 1099 44b a.out

I don't think I ever knew what bss stands for.

"Block started by symbol", according to Dennis Ritchie:

And, IIRC, it was introduced by an IBM assembler, which supported it as
a directive, along with BES, "block ended by symbol". Back in the late
fifties or so.

I started with OS/360 assembly, and it seems it was gone by then.

-- glen

[Sheldon Simms]

On Wed, 26 Nov 2003 12:23:32 +0000, Jeremy Yallop wrote:

glen herrmannsfeldt wrote:

Dan Pop wrote:

It's also common Unix terminology:

fangorn:~/tmp 217> size a.out
text data bss dec hex filename
855 220 24 1099 44b a.out

I don't think I ever knew what bss stands for.

"Block started by symbol", according to Dennis Ritchie:
<news:3B*****************************@ifi.uio.no >.

There is an older meaning "binary symbolic subroutine" from
Fortran. From the John Backus paper "The History of FORTRAN I, II, II":

In the early fall of 1957 we started to plan ways of correcting these
shortcomings; a document dated September 25, 1957 ... This document is
titled "Proposed Specifications for FORTRAN II for the 704"; ...
It describes how symbolic information is retained in the relocatable
binary form of a subroutine so that the "binary symbolic subroutine
[BSS] loader" can implement references to separately compiled
subroutines.

[Dave Thompson]

On 25 Nov 2003 16:32:12 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <2_Awb.225969$ao4.817994@attbi_s51> glen herrmannsfeldt <ga*@ugcs.caltech.edu> writes:

Martijn Lievaart wrote: <snip>

For those that don't know, 'text' is also use as a (terribly confusing)
term for the code of a program as it is layed out in an executable file or
in memory.

IBM, at least, seems to like it. The S/360 object code files contain a
few different types of records, ESD (external symbol dictionary), RLD
(relocation dictionary), TXT (the instructions and data),

^^^^^^^^^^^^^^^^^^^^^^^^^
Isn't it instructions and *read-only* data?

I believe it's all initialized data; read-only data, or at least
literals, will normally be put in the same CSECT as code and
modifiable data in another, so the first can be pure (originally and I
think still called reentrant) but the second not.

- David.Thompson1 at worldnet.att.net

[glen herrmannsfeldt]

Dave Thompson wrote:

On 25 Nov 2003 16:32:12 GMT, Da*****@cern.ch (Dan Pop) wrote: (snip regarding the use of the word "text" describing executable code)
I wrote:

IBM, at least, seems to like it. The S/360 object code files contain a
few different types of records, ESD (external symbol dictionary), RLD
(relocation dictionary), TXT (the instructions and data),

^^^^^^^^^^^^^^^^^^^^^^^^^ Isn't it instructions and *read-only* data?

I believe it's all initialized data; read-only data, or at least
literals, will normally be put in the same CSECT as code and
modifiable data in another, so the first can be pure (originally and I
think still called reentrant) but the second not.

Old Fortran compilers would put everything into the same CSECT. All
variables were static, and initialized ones were in the same CSECT, and
initialized with TXT records.

The PL/I compilers that I knew used a separate CSECT for initialized data.

Newer processors with large cache line size and separate instruction and
data caches run significantly slower if data and instructions are close
together. That is one reason to keep them separate.

uninitialized static external variables (not in C) would be COM
sections, initialized ones (from Fortran BLOCK DATA for example) would
be CSECTs.

-- glen