www.digitalmars.com         C & C++   DMDScript  

D - Also...

reply "Brian Bober" <netdemonz yahoo.com> writes:
Another idea I had when talking to someone on Mozilla irc was that
endianness should be explicit. You should tell the compiler which endianness
you use and that is kept in mind by the compiler. There would be 3 options:

setBigEndian
setLittleEndian
setDefaultEndian    <- uses system's method

Endianness causes a lot of problems in XP code.
Feb 03 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Brian Bober wrote:

 Another idea I had when talking to someone on Mozilla irc was that
 endianness should be explicit. You should tell the compiler which endianness
 you use and that is kept in mind by the compiler. There would be 3 options:
 
 setBigEndian
 setLittleEndian
 setDefaultEndian    <- uses system's method
 
 Endianness causes a lot of problems in XP code.

And if your endianness request doesn't match the target environment's endianness, does the compiler generate code to accomodate, or does it issue an error? -Russell B
Feb 03 2002
parent reply "Brian Bober" <netdemonz yahoo.com> writes:
Ignore the other two posts... I'm going to cancel them.

It compenstates and produces assembler code as if people were using the
correct endianess.

Also, there should be a getDefaultEndian and getCurrentEndian or something
equivalent.

This is almost a necessity for things like XP graphics - such as image
decoders.
In Mozilla, we have macros defined that switch the endianness - which is
obviously slower than the compiler taking it into consideration and
generating
different code.

D should be written in such a way that every caveat of cross-platform and
cross-language programming is addressed.

"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C5E219E.1070202 estarcion.com...
 Brian Bober wrote:

 Another idea I had when talking to someone on Mozilla irc was that
 endianness should be explicit. You should tell the compiler which


 you use and that is kept in mind by the compiler. There would be 3


 setBigEndian
 setLittleEndian
 setDefaultEndian    <- uses system's method

 Endianness causes a lot of problems in XP code.

And if your endianness request doesn't match the target environment's endianness, does the compiler generate code to accomodate, or does it issue an error? -Russell B

Feb 03 2002
next sibling parent reply "D" <s_nudds hotmail.com> writes:
Default Endian isn't explicitly required.

Endian conversions have value only for I/O.  And I/O is closely associated
with the passing of structures between machines.

As a result endian specifications should be a character of structures rather
than simple variables.

I suggest that a special class of IO structure be created which is intended
specifically for information sharing.  Operations on such structures could
be restricted to simple assignment so that unnecessary endian conversions
can be avoided.  The programmer would be forced to complete a compatible
structure,  then perform an explicit assignment to the I/O structure before
it is output.

This would also provide the opportunity for the compiler to perform other
byte alignment operations. as needed.


 Another idea I had when talking to someone on Mozilla irc was that
 endianness should be explicit. You should tell the compiler which

 you use and that is kept in mind by the compiler. There would be 3

 setBigEndian
 setLittleEndian
 setDefaultEndian    <- uses system's method

Feb 03 2002
next sibling parent reply "Brian Bober" <netdemonz yahoo.com> writes:
I agree with you that its not required, but it wouldn't hurt to put it in.
There might be some
strange reason someone wants it. Saying no one will is kind of like
saying that no one would need more than 1MB of ram 20 years ago.

I do like your idea for the structures. Do you think a special keyword on
structs and integers
would work?

"D" <s_nudds hotmail.com> wrote in message
news:a3ldt4$nel$1 digitaldaemon.com...
 Default Endian isn't explicitly required.

 Endian conversions have value only for I/O.  And I/O is closely associated
 with the passing of structures between machines.

 As a result endian specifications should be a character of structures

 than simple variables.

 I suggest that a special class of IO structure be created which is

 specifically for information sharing.  Operations on such structures could
 be restricted to simple assignment so that unnecessary endian conversions
 can be avoided.  The programmer would be forced to complete a compatible
 structure,  then perform an explicit assignment to the I/O structure

 it is output.

 This would also provide the opportunity for the compiler to perform other
 byte alignment operations. as needed.


 Another idea I had when talking to someone on Mozilla irc was that
 endianness should be explicit. You should tell the compiler which

 you use and that is kept in mind by the compiler. There would be 3

 setBigEndian
 setLittleEndian
 setDefaultEndian    <- uses system's method


Feb 04 2002
parent "D" <s_nudds hotmail.com> writes:
DefaultEndian is the default by definition.  The only way I could see it
being used is if the language assigned numeric values to the types for the
purpose of run time type checking.  The kind that's used for Varints.

In that case you would have

If DefaultEndian = bigEndian then....

I say restrict the endian types to structures, and not to simple variables
at all, or any complex type that permits element by element assignment.

Further, there should be two classes of endienness.  EndianByte and
EndianBit.




Brian Bober <netdemonz yahoo.com> wrote in message
news:a3lg5l$qg4$1 digitaldaemon.com...
 I agree with you that its not required, but it wouldn't hurt to put it in.
 There might be some
 strange reason someone wants it. Saying no one will is kind of like
 saying that no one would need more than 1MB of ram 20 years ago.

 I do like your idea for the structures. Do you think a special keyword on
 structs and integers
 would work?

Feb 04 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3ldt4$nel$1 digitaldaemon.com...
 Default Endian isn't explicitly required.

 Endian conversions have value only for I/O.  And I/O is closely associated
 with the passing of structures between machines.

For file (and general stream) I/O, I'll add conversion functions to my Stream class. It'd work like this: File file; ... file.writeBE(666); // big-endian file.writeLE(666); // lil-endian
Feb 04 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3lk7q$sfb$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3ldt4$nel$1 digitaldaemon.com...
 Default Endian isn't explicitly required.

 Endian conversions have value only for I/O.  And I/O is closely


 with the passing of structures between machines.

For file (and general stream) I/O, I'll add conversion functions to my Stream class. It'd work like this: File file; ... file.writeBE(666); // big-endian file.writeLE(666); // lil-endian

I agree doing it in the streams is the right place.
Feb 15 2002
parent reply "Brian Bober" <netdemonz yahoo.com> writes:
I agree that it should be done in streams, but that is not the only place.
What if someone uses their own stream functions? What about interfacing with
legacy code that has explicit endianness?

Default endianness is the one that is defined by the system. Mac has a
different default endianness than pc.


"Walter" <walter digitalmars.com> wrote in message
news:a4je38$1qhv$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a3lk7q$sfb$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3ldt4$nel$1 digitaldaemon.com...
 Default Endian isn't explicitly required.

 Endian conversions have value only for I/O.  And I/O is closely


 with the passing of structures between machines.

For file (and general stream) I/O, I'll add conversion functions to my Stream class. It'd work like this: File file; ... file.writeBE(666); // big-endian file.writeLE(666); // lil-endian

I agree doing it in the streams is the right place.

Feb 20 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a50spc$18g4$1 digitaldaemon.com...

 I agree that it should be done in streams, but that is not the only place.
 What if someone uses their own stream functions? What about interfacing

 legacy code that has explicit endianness?

D legacy code should have no "explicit endianness" (because there is a standard way to determine it if needed). For C code, you will have to use explicit conversion - which is as easy as writing a one-line version'ed function, which than gets inlined by the compiler.
Feb 20 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3lakj$m5o$1 digitaldaemon.com...
 D should be written in such a way that every caveat of cross-platform and
 cross-language programming is addressed.

I have a start in \dmd\src\phobos\system.d. Endianness is already there. I'm open to suggestions.
Feb 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a4je37$1qhv$1 digitaldaemon.com...

 "Brian Bober" <netdemonz yahoo.com> wrote in message
 news:a3lakj$m5o$1 digitaldaemon.com...
 D should be written in such a way that every caveat of cross-platform


 cross-language programming is addressed.

I have a start in \dmd\src\phobos\system.d. Endianness is already there.

 open to suggestions.

Define a processor family identificator, so it is possible to write: asm { version (i386) ... else version (alpha) ... ... } Would help to write _fast_ cross-platform thingies. Like GNU's bignum, GMP...
Feb 15 2002
parent "Walter" <walter digitalmars.com> writes:
Ok, that's a good idea.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a4jqcr$20o0$1 digitaldaemon.com...
 Define a processor family identificator, so it is possible to write:

     asm
     {
         version (i386)
             ...
         else version (alpha)
             ...
         ...
     }

 Would help to write _fast_ cross-platform thingies. Like GNU's bignum,
 GMP...

Feb 15 2002