"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CD2BFF2.8040103@estarcion.com...
> There are also lots of C compilers where a command-line
> option or pragma or incompatible hack selects the int
> size.

Yuk. I really don't like the semantics of the compiler being controlled by the command line. It should be done in the source code itself. I'm forced into doing that with the C compiler, but with D I can try to design out such things.

I've seen some C programs where it seems much of the logic was transferred into the makefile that was generated by perl scripts - aaarrrggghh. It was *really* hard to figure out what was going on.

"Walter" <walter@digitalmars.com> wrote in message news:aauksb$2k56$3@digitaldaemon.com...
>
> "Richard Krehbiel" <rich@kastle.com> wrote in message news:aatrrm$1j1v$1@digitaldaemon.com...
> > The ancient, obsolete processor you're thinking of may well be the
> PowerPC!
> > Subroutine calls place the return address in a link register, which, by *convention* *only*, the called function "pushes" onto a
software-managed
> > stack referred to by R1.
>
> It's still a stack.

Of course.  It's just that it's proper use is not hardware-enforced.

> > (I coded IBM 370 mainframe machine code in a former life, and it also
has
> > no
> > stack.  This machine architecture lives on in the current IBM mainframe
> > lineup.)
>
> Does it emulate a stack?

My code never did; the standard calling conventions did not call for a default stack pointer, and there was no memory space set aside for a stack.

And oddly enough, I never used any recursive algorithms...

Walter wrote:
> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3CD2C330.7050908@estarcion.com...
> 
>>[1] I may be completely misremembering,
>>but some even use a general register as the
>>Program Counter/Instruction Pointer, meaning that
>>the same circuitry that does "*p++" is doing
>>instruction reads, and the same addressing modes
>>available with address registers are available
>>in PC-relative form.
> 
> 
> You remember correctly, that was the PDP-11. 

Thought it might be, but I'm getting mistrustful of
my memory in my old age. A little IIRC avoids a lot
of public humiliation. :)

-R

I would actually go farther, in suggesting a conservative subset of all the ideas expressed in this item.

Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or not this is the case) the char type (whether ANSI or Unicode - again I am not sure in whether this has been decided) should be a distinct type from any of the aforementioned 10 integer types, as should bool.

I know this strikes at the C-ness of it all, but I am pretty sure it makes for simpler coding and better maintainability. In my own C/C++ code I have for years had types akin to the C99, and the only time I ever have cause to use one of the "real" types is when defining post-inc/decrement operators (ie. operator ++(int)).

Whether this is accepted (and I doubt, given the style offense it would cause to most C/C++-heads), there could surely be these types provided alongside the non-sized ones?

Alternatively, in Java the types sizes are all strictly defined, and that causes no problems either. It is pretty easy to remember that int is 32 and long 64 bits.

Undecidely, ...

Matthew



"Mark T" <mt@nospam.com> wrote in message news:aar9td$3gu$1@digitaldaemon.com...
> I think using the Java standard sizes for integral sizes is a mistake
since
> D does not need a VM :) and since "D is designed to fit comfortably with a
C
> compiler for the target system".
>
> I think the D language spec is overly targeted to the IA32/x86
architecture.
> Generally, the C programmer uses "int" as the most efficient type for the CPU (it has been a while but I think "int" on the DEC Alpha is 64 bits).
Of
> course, there are still plenty of 16 bit CPUs and odd-ball DSPs which
would
> could possibly use D.
>
> The following D types should be modified to match the underlying C types
for
> the specific target (since you have a single target currently that
wouldn't
> break much code), then interfacing to existing C code would be very straightforward.
>
> short
> ushort
> int
> uint
> long
> ulong
>
> D should introduce the following types (similar to C99 with the "_t"
> removed) for those times when you need an exact bit length data type.
>   int8 - signed 8 bits
>   uint8 - unsigned 8 bits
>   int16 - signed 16 bits
>   uint16 - unsigned 16 bits
>   int32 - signed 32 bits
>   uint32 - unsigned 32 bits
>   etc
>
> I do embedded programming and use the exact size C99 types quite often.
>
> Mark
>
>

 would actually go farther, in suggesting a conservative subset of all the
ideas expressed in this item.

Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or not this is the case) the char type (whether ANSI or Unicode - again I am not sure in whether this has been decided) should be a distinct type from any of the aforementioned 10 integer types, as should bool.

I know this strikes at the C-ness of it all, but I am pretty sure it makes for simpler coding and better maintainability. In my own C/C++ code I have for years had types akin to the C99, and the only time I ever have cause to use one of the "real" types is when defining post-inc/decrement operators (ie. operator ++(int)).

Whether this is accepted (and I doubt, given the style offense it would cause to most C/C++-heads), there could surely be these types provided alongside the non-sized ones?

Alternatively, in Java the types sizes are all strictly defined, and that causes no problems either. It is pretty easy to remember that int is 32 and long 64 bits.

Undecidely, ...

Matthew


"Mark T" <mt@nospam.com> wrote in message news:aar9td$3gu$1@digitaldaemon.com...
> I think using the Java standard sizes for integral sizes is a mistake
since
> D does not need a VM :) and since "D is designed to fit comfortably with a
C
> compiler for the target system".
>
> I think the D language spec is overly targeted to the IA32/x86
architecture.
> Generally, the C programmer uses "int" as the most efficient type for the CPU (it has been a while but I think "int" on the DEC Alpha is 64 bits).
Of
> course, there are still plenty of 16 bit CPUs and odd-ball DSPs which
would
> could possibly use D.
>
> The following D types should be modified to match the underlying C types
for
> the specific target (since you have a single target currently that
wouldn't
> break much code), then interfacing to existing C code would be very straightforward.
>
> short
> ushort
> int
> uint
> long
> ulong
>
> D should introduce the following types (similar to C99 with the "_t"
> removed) for those times when you need an exact bit length data type.
>   int8 - signed 8 bits
>   uint8 - unsigned 8 bits
>   int16 - signed 16 bits
>   uint16 - unsigned 16 bits
>   int32 - signed 32 bits
>   uint32 - unsigned 32 bits
>   etc
>
> I do embedded programming and use the exact size C99 types quite often.
>
> Mark
>
>

"Matthew Wilson" <mwilson@nextgengaming.com> wrote in message news:abff2a$1i69$1@digitaldaemon.com...

> Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or not

Walter promised to give us a unit with appropriate typedefs:

    module types;
    typedef byte int8;
    typedef short int16;
    typedef int int32;
    ...

> Alternatively, in Java the types sizes are all strictly defined, and that causes no problems either. It is pretty easy to remember that int is 32
and
> long 64 bits.

This is exactly how D works, and I would really prefer it to remain.

On Fri, 10 May 2002 13:40:13 +1000, "Matthew Wilson" <mwilson@nextgengaming.com> wrote:
>  would actually go farther, in suggesting a conservative subset of all the
> ideas expressed in this item.
> 
> Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or not this is the case) the char type (whether ANSI or Unicode - again I am not sure in whether this has been decided) should be a distinct type from any of the aforementioned 10 integer types, as should bool.

Get rid of unsigned entirely. It adds nothing but confusion. Its very use implies that overflow behavior is important!

Karl Bochert

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1021047954@bose...
> On Fri, 10 May 2002 13:40:13 +1000, "Matthew Wilson"
<mwilson@nextgengaming.com> wrote:
> >  would actually go farther, in suggesting a conservative subset of all
the
> > ideas expressed in this item.
> >
> > Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or
not
> > this is the case) the char type (whether ANSI or Unicode - again I am
not
> > sure in whether this has been decided) should be a distinct type from
any of
> > the aforementioned 10 integer types, as should bool.
>
> Get rid of unsigned entirely. It adds nothing but confusion. Its very use implies that overflow behavior is important!
>
> Karl Bochert
>
>

Mmmm....
It doubles the range of a type without any loss!
If a value is *always* positive (the index of an array)
why not express this using an unsigned type?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Karl Bochert wrote:
> On Fri, 10 May 2002 13:40:13 +1000, "Matthew Wilson" <mwilson@nextgengaming.com> wrote:
> 
>> would actually go farther, in suggesting a conservative subset of all the
>>ideas expressed in this item.
>>
>>Basically, we could do away with short, int, long, etc, and use
>>s/uint8/16/32/64/128. Additionally (and please let me know whether or not
>>this is the case) the char type (whether ANSI or Unicode - again I am not
>>sure in whether this has been decided) should be a distinct type from any of
>>the aforementioned 10 integer types, as should bool.
> 
> 
> Get rid of unsigned entirely. It adds nothing but confusion.
> Its very use implies that overflow behavior is important!

I use unsigned vs. signed to control the behavior of
shifts, not the behavior of overflows.

-Russell B

Russell Borogove wrote:

> Karl Bochert wrote:
> > On Fri, 10 May 2002 13:40:13 +1000, "Matthew Wilson" <mwilson@nextgengaming.com> wrote:
> >
> >> would actually go farther, in suggesting a conservative subset of all the
> >>ideas expressed in this item.
> >>
> >>Basically, we could do away with short, int, long, etc, and use s/uint8/16/32/64/128. Additionally (and please let me know whether or not this is the case) the char type (whether ANSI or Unicode - again I am not sure in whether this has been decided) should be a distinct type from any of the aforementioned 10 integer types, as should bool.
> >
> >
> > Get rid of unsigned entirely. It adds nothing but confusion. Its very use implies that overflow behavior is important!
>
> I use unsigned vs. signed to control the behavior of shifts, not the behavior of overflows.
>
> -Russell B

And I haven't seen many signed hardware registers...


-BobC