Forum unknown
· Off the Cuff
#What goes where?
31 messages in this thread
Isn't the present situation such that some compilers generate signed and
some generate unsigned by default? Couldn't you just as easily say that the
'unsigned' wouldn't be needed?
Yes, the current situation is that some compilers generate signed
and some generate unsigned. Since the ANSI reccomendation at this point is
to keep the keyword signed then one would presume that there is a reason to
keep it so you could modify the default from unsigned to signed.
Don
I'm still confused… are they not also keeping the keyword 'unsigned'?
Larry, I'd assume the reason for keeping both keywords around is so that
you can write code that will work with older compilers that accept both
keywords but don't necessarily default to the one you want. It seems that
making an overt specification for the signedness of char is going to be a
wise precaution in C for a long time to come. I agree with you that this is
a defect in the language; however, it is only an inconvenience, not an
obstacle to writing good code.
Larry, I'd assume the reason for keeping both keywords around is so that
you can write code that will work with older compilers that accept both
keywords but don't necessarily default to the one you want. It seems that
making an overt specification for the signedness of char is going to be a
wise precaution in C for a long time to come. I agree with you that this is
a defect in the language; however, it is only an inconvenience, not an
obstacle to writing good code.
For the record – the lattice defaults to signed…. what does the (ugh!)
Manx do? –ben–
I think Manx defaults to signed. One thing though, you can hardly fault a
C compiler for defaulting to unsigned, since they are merely excercising
their prerogative as specified in K&R. same goes for order of evaluation of
equal prcedence operators and operands, or any number of other things that
have been loosely defined.
Yeah – well, I don't fault Manx – for that… I fault them for allowing
in-line asm, trying to push off incompatible object files for so long,
defaulting to a _different_ default (16 bits) than how the original 'c'
stuff was written (and thereby making the manx stuff incompatible) not
supporting some of the more advanced features of the language (Till
recently, I _think_) like structure passing and so on, and puching a
debugger as a useful tool – while imho a debugger is a tool for creating
lazy and programmers, who don't take care when they write because they
think the debugger will pull them 'out of the fire'. All the effort manx
spent on the debugger should (again, imho) have been spent on the compiler.
–Ben– (Happily playing with Lattice 4.0 as I type)
Nobody is forcing you to use the debugger or the inline #asm., and it's
obvious to me that 16 bits is the natural int size of the machine.
Well, it's obvious to ME that 32 bits is the natural size of the machine,
and that the bus width is a temporary restriction based on the 68000 unit.
If you use your logic, then an 8 bit word is the natural size for a 68008,
and 32 bits for the 68020. When in reality, they are ALL 32 bit processors.
The issue about debuggers and inline asm isn't who's forcing whoom… it's
that code produced by the former (always) and the latter (often) is either
totally unusable by others not familiar with the particular compiler and
it's register assignments, (in the case of the former) and that code
produced by people who use the latter is simply inferior (usually). I don't
like debuggers – they encourage sloppy programming, and so I lobby against
them. I don't like in line asm, for that reason AND it ruins portability,
AND it makes code unreadable, AND it's schlock programming to try to change
tracks in the middle of a module – if you need high performance, then write
it in assembler – if not, use 'c'. Why be schitzo? <grin>. Every time I see
in-line code, I think 'inferior/unskilled/jr programmer' and toss it.
–Ben–
Well, it's obvious to ME that 32 bits is the natural size of the machine,
and that the bus width is a temporary restriction based on the 68000 unit.
If you use your logic, then an 8 bit word is the natural size for a 68008,
and 32 bits for the 68020. When in reality, they are ALL 32 bit processors.
The issue about debuggers and inline asm isn't who's forcing whoom… it's
that code produced by the former (always) and the latter (often) is either
totally unusable by others not familiar with the particular compiler and
it's register assignments, (in the case of the former) and that code
produced by people who use the latter is simply inferior (usually). I don't
like debuggers – they encourage sloppy programming, and so I lobby against
them. I don't like in line asm, for that reason AND it ruins portability,
AND it makes code unreadable, AND it's schlock programming to try to change
tracks in the middle of a module – if you need high performance, then write
it in assembler – if not, use 'c'. Why be schitzo? <grin>. Every time I see
in-line code, I think 'inferior/unskilled/jr programmer' and toss it.
–Ben–
The 'natural' size of an int should be the size of a data register
and thus, the Amiga should have 32 bit ints. Doesn't matter the size of
the external data path.
so a pointer to the natural size is a pointer to long? I knew there was a
good reason for BPTRs. They are 'natural' for the Amiga.
Larry, the unnatural thing about BPTRs is that they're not pointers at all
in the normal sense, they're the ordinal number of a long-word in memory;
i.e. the BPTR to address 4 is 1, to address 8 is 2… etc. I'm not sure
(haven't tried), but since C lets you say: "static foo;" and assumes you
mean "static int foo;", int being whatever the compiler writer takes to be
the natural data size for the machine at hand, you can probably say "static
*foo" and get a pointer to data of that size. So the answer (for those who
think the natural data size is long) is yes, a pointer to the natural size
is a pointer to long.
Depends on how you look at it. In C, adding 1 to a long pointer really
adds 4 to it to point at the next long. A BPTR is a pointer to long, in
that it points to the nth longword in memory, considering the longwords to
be the base unit. Looked at this way, a BPTR + 1 points to the next
longword when using, for example, assembler. That you have to convert
before actually using it is not really any different than the C cmpiler
converting when it increments a long pointer.
Depends on how you look at it. In C, adding 1 to a long pointer really
adds 4 to it to point at the next long. A BPTR is a pointer to long, in
that it points to the nth longword in memory, considering the longwords to
be the base unit. Looked at this way, a BPTR + 1 points to the next
longword when using, for example, assembler. That you have to convert
before actually using it is not really any different than the C cmpiler
converting when it increments a long pointer.
Larry, the unnatural thing about BPTRs is that they're not pointers at all
in the normal sense, they're the ordinal number of a long-word in memory;
i.e. the BPTR to address 4 is 1, to address 8 is 2… etc. I'm not sure
(haven't tried), but since C lets you say: "static foo;" and assumes you
mean "static int foo;", int being whatever the compiler writer takes to be
the natural data size for the machine at hand, you can probably say "static
*foo" and get a pointer to data of that size. So the answer (for those who
think the natural data size is long) is yes, a pointer to the natural size
is a pointer to long.
I agree with Nick. BPTR's are weird, not real pointers.
I agree with Nick. BPTR's are weird, not real pointers.
so a pointer to the natural size is a pointer to long? I knew there was a
good reason for BPTRs. They are 'natural' for the Amiga.
The 'natural' size of an int should be the size of a data register
and thus, the Amiga should have 32 bit ints. Doesn't matter the size of
the external data path.
Nobody is forcing you to use the debugger or the inline #asm., and it's
obvious to me that 16 bits is the natural int size of the machine.
Let's see, to make a program, you take your editor output and pass
it to a preprocessor, that output goes to a compiler and that output goes
to an assembler and that output goes to a linker. Gee…how about if we
pass the #asm stuff thru the compiler unchanged so you don't have to
assemble and link in a separate module? Gee…that's kind of a neat
idea…but nah.. we wouldn't want to mess up our C code with crappy ole'
assembly would e we?
Let's see, to make a program, you take your editor output and pass
it to a preprocessor, that output goes to a compiler and that output goes
to an assembler and that output goes to a linker. Gee…how about if we
pass the #asm stuff thru the compiler unchanged so you don't have to
assemble and link in a separate module? Gee…that's kind of a neat
idea…but nah.. we wouldn't want to mess up our C code with crappy ole'
assembly would e we?
Yeah – well, I don't fault Manx – for that… I fault them for allowing
in-line asm, trying to push off incompatible object files for so long,
defaulting to a _different_ default (16 bits) than how the original 'c'
stuff was written (and thereby making the manx stuff incompatible) not
supporting some of the more advanced features of the language (Till
recently, I _think_) like structure passing and so on, and puching a
debugger as a useful tool – while imho a debugger is a tool for creating
lazy and programmers, who don't take care when they write because they
think the debugger will pull them 'out of the fire'. All the effort manx
spent on the debugger should (again, imho) have been spent on the compiler.
–Ben– (Happily playing with Lattice 4.0 as I type)
I think Manx defaults to signed. One thing though, you can hardly fault a
C compiler for defaulting to unsigned, since they are merely excercising
their prerogative as specified in K&R. same goes for order of evaluation of
equal prcedence operators and operands, or any number of other things that
have been loosely defined.
For the record – the lattice defaults to signed…. what does the (ugh!)
Manx do? –ben–
If the default is unsigned, then there is no need for that keyword
is there? As a matter of fact thou…yes, it is being kept. If for no
other reason that for use with a cast. If I take a signed character value
and wish to move that value into an unsigned integer variable, then I still
need the ability to cast to an unsigned so I don't get sign extension into
the large (storage wise) value.
If the default is unsigned, then there is no need for that keyword
is there? As a matter of fact thou…yes, it is being kept. If for no
other reason that for use with a cast. If I take a signed character value
and wish to move that value into an unsigned integer variable, then I still
need the ability to cast to an unsigned so I don't get sign extension into
the large (storage wise) value.
I'm still confused… are they not also keeping the keyword 'unsigned'?
Yes, the current situation is that some compilers generate signed
and some generate unsigned. Since the ANSI reccomendation at this point is
to keep the keyword signed then one would presume that there is a reason to
keep it so you could modify the default from unsigned to signed.
Don