Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #70255 > unrolled thread

Re: Reading beyond the end of file

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 10:06 -0700
    Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-11 12:41 -0700
      Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:24 -0700
        Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-26 21:49 -0700
          Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:57 -0700
            Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-10-01 17:22 -0700
              Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:05 +0000
              Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 17:56 -0700
    Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-11 13:55 -0600
      Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:14 -0700
        Re: Reading beyond the end of file Siri Cruz <chine.bleu@yahoo.com> - 2015-09-26 14:43 -0700
          Re: Reading beyond the end of file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-26 17:57 -0400
          Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 14:01 -0700
        Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-26 22:18 -0600
          Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 12:58 -0700
            Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-01 15:08 -0600
              Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 18:03 -0700
                Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:02 +0000
        Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:11 +0000
          Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-02 09:31 -0700
            Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:07 -0400
          Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:06 -0700
    Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-11 14:36 -0700
      Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:05 -0700
        Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-26 18:53 -0700
          Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:49 -0700
            Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-01 20:23 -0400
              Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 06:14 +0000
              Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:03 -0700
                Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-04 22:55 -0400
                  Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:27 +0000
                    Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-04 22:21 -0700
                      Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 09:53 +0000
                        Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-05 13:15 -0400
                          Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:25 -0700
                            Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:30 +0000
                          Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:27 +0000
                        Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:17 -0700
                        Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 11:59 -0700
                          Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 13:44 -0700
                            Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:58 +0000
                              Ones' complement subtraction supercat@casperkitty.com - 2015-10-05 15:28 -0700
                                Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 02:14 +0000
                                  Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 08:48 -0700
                                    Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 20:55 +0000
                                      Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 14:41 -0700
                                        Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-07 00:14 +0000
                            Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:24 -0700
                          Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:39 +0000
                            Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:31 -0700
                              Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 03:04 +0000
                                Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:55 -0700
                                  Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 11:44 -0700
                        Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-05 23:16 -0400
                          Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-06 10:29 -0400
                          Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:56 -0700
                            Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-06 23:13 -0400
                              Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 22:01 -0700
                              Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 08:43 -0700
                                Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-07 10:02 -0700
                                Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 13:08 -0700
                                Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-07 22:03 -0400
                  Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:47 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#72005

supercat@casperkitty.com wrote:
> On Monday, October 5, 2015 at 1:59:45 PM UTC-5, Keith Thompson wrote:
>> Another problem is that the input character is treated as an unsigned
>> char and converted to signed int.  If unsigned char fits in the range of
>> signed int, that's not a problem.  But if not, and if you read a
>> character with a value exceeding INT_MAX, then the conversion to int
>> yields an implementation-defined result or raises an
>> implementation-defined signal.  Probably the conversion will do the
>> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.
 
> If  James Kuyper's citation of 7.21.2p3 is accurate, I would think that any
> platform where UCHAR_MAX > INT_MAX would be required to use an "int" type
> which supported a value which behaved as -INT_MAX-1.  I think it might be
> possible for a ones'-complement or sign-magnitude implementation to meet
> the requirement if the bit pattern for "negative zero" was never generated
> by any calculations within the range of "int" but was produced by trying to
> convert "INT_MAX+1U" to "int", and if converting that value to "unsigned"
> yielded "INT_MAX+1U".

There are two ways to build ones complement machines:

The obvious one makes ~0==0, which complicates some C programs
using bit masking and testing.

The other way never generates ~0 unless an operand of an arithmetic
operation is ~0. If you use a ones complement subtractor, and
do addition by subtracting the complement, this is the natural
result.

The obvious way to build a sign magnitude adder is to convert to
ones complement (XOR sign bit with all value bits) put the result
into a ones complement adder, then XOR the sign bit again. 

Also, I have never known of 32 bit ones complement or sign
magnitude machines, not that one couldn't be built.

The last of the sign magnitude machines that I know about is
the IBM 7094, descendant from the 7090, 709, 704, and 701,
and has a 36 bit word.

The CDC 60 bit machines, starting with the 6600 family, are
ones complement. 

Unisys 2200 series machines, as far as I know still being sold,
are 36 bit ones complement.

-- glen

[toc] | [prev] | [next] | [standalone]

#72010 — Ones' complement subtraction

On Monday, October 5, 2015 at 4:58:29 PM UTC-5, glen herrmannsfeldt wrote:
> The other way never generates ~0 unless an operand of an arithmetic
> operation is ~0. If you use a ones complement subtractor, and
> do addition by subtracting the complement, this is the natural
> result.

Do ones'-complement subtractors start by doing a magnitude comparison between
the two values, swapping them if needed, then performing the subtraction and
negating the result if required, or is there an easier way?  Two's-complement
subtraction allows the bits to be computed LSB in order first with no bit
being dependent upon any higher bits, but ones'-complement subtraction would
not allow that.  If the low-order bytes of X and Y are 0x80 and 0x01, the
low-order byte of X-Y might be 0x7F or 0x80, and figuring out which would
require processing all higher-order bytes.

I could see some benefit to a ones'-complement floating-point format (in
which case the sign bit is extended infinitely far on *both* sides of the
number) because floating-point requires special handling of add/subtract
operations that cross zero, but for integers it seems like ones'-complement
would add extra complexity and I can't see any benefit.

[toc] | [prev] | [next] | [standalone]

#72019 — Re: Ones' complement subtraction

supercat@casperkitty.com wrote:

(snip, I wrote)
>> The other way never generates ~0 unless an operand of an arithmetic
>> operation is ~0. If you use a ones complement subtractor, and
>> do addition by subtracting the complement, this is the natural
>> result.
 
> Do ones'-complement subtractors start by doing a magnitude 
> comparison between the two values, swapping them if needed, 
> then performing the subtraction and negating the result if 
> required, or is there an easier way?  

You can make a ones complement adder taking the carry out of
the MSB and using it as the carry in for the LSB. Next, you
usually add carry lookahead logic, which I think works just
fine in that case. When the result isn't zero, that should
work as well as twos complement adders. 

When the result is zero, there is a theoretical possibility
that it won't converge.  That is, that it won't converge
to either 0 or ~0. As far as I know, this isn't a problem
in real adders, but it does complicate the timing calculation.

> Two's-complement subtraction allows the bits to be computed 
> LSB in order first with no bit being dependent upon any 
> higher bits, but ones'-complement subtraction would not 
> allow that.  If the low-order bytes of X and Y are 0x80 and 
> 0x01, the low-order byte of X-Y might be 0x7F or 0x80, 
> and figuring out which would require processing all 
> higher-order bytes.

Both the adder and subtractor can be done in parallel with
the MSB carry out going to the LSB carry in. If the sum isn't
zero, then either the least or most significant byte doesn't
depend on the other. 

For an adder, ~0+0 and 0+~0 both give ~0 as a sum. 
Actually, ~x+x and x+~x do for all x.

With an appropriate subtractor, x-x gives 0 for all x, except ~0.
 
> I could see some benefit to a ones'-complement floating-point format (in
> which case the sign bit is extended infinitely far on *both* sides of the
> number) because floating-point requires special handling of add/subtract
> operations that cross zero, but for integers it seems like ones'-complement
> would add extra complexity and I can't see any benefit.

I never heard why Cray liked ones complement through the CDC years.

With the Cray-1 he finally decided on twos complement.

-- glen

-- glen

[toc] | [prev] | [next] | [standalone]

#72050 — Re: Ones' complement subtraction

On Monday, October 5, 2015 at 9:14:18 PM UTC-5, glen herrmannsfeldt wrote:
> You can make a ones complement adder taking the carry out of
> the MSB and using it as the carry in for the LSB. Next, you
> usually add carry lookahead logic, which I think works just
> fine in that case. When the result isn't zero, that should
> work as well as twos complement adders.

It's certainly possible to implement a ones'-complement adder by performing
an addition and then having a cleanup step which feeds the carry from the
earlier stages to the later stages, and if the entire addition is being
performed in parallel one could probably overlap some of the work so that
the overall process would take less than twice as long as doing a straight
binary addition, but it would still require a significant amount of extra
circuitry even the parallel-math case; further, I don't see any practical
way to avoid a 2:1 speed penalty when performing straight binary addition.

Certainly many mechanical adding machines represented negative numbers in
ten's-complement format; I don't know of any that represented negative
numbers in nines'-complement.  Some performed subtraction by having an
operator enter a number on nines'-complement format *and plus a "plus one"
button*, which is the pattern used for two's-complement subtraction, but
I've never seen a unit where subtracting 2 from 1 would yield 999,998.

From what I can tell, two's-complement format is cheaper to implement in
hardware, faster to implement in hardware, and easier to work with in
software, than ones'-complement format.  The only situation I can see
where ones' complement would have advantages would be when performing
division, and even there the only advantage would be that hardware to
normalize both operands to positive and invert the result would be a
lot cheaper in sign-magnitude format and a little cheaper in ones'
complement than would be hardware in two's-complement, but since the
performance penalty for doing such normalization in software for those
cases where code didn't know in advance whether values would be positive
or negative would be pretty slight I don't see that as a very compelling
factor.

Any idea *why* one's-complement format emerged as a standard, given that
in the mechanical-computing world ten's-complement dominated over
nines' complement?

[toc] | [prev] | [next] | [standalone]

#72084 — Re: Ones' complement subtraction

supercat@casperkitty.com wrote:

(snip on ones complement adders and end-around carry)

> It's certainly possible to implement a ones'-complement adder by performing
> an addition and then having a cleanup step which feeds the carry from the
> earlier stages to the later stages, and if the entire addition is being
> performed in parallel one could probably overlap some of the work so that
> the overall process would take less than twice as long as doing a straight
> binary addition, but it would still require a significant amount of extra
> circuitry even the parallel-math case; further, I don't see any practical
> way to avoid a 2:1 speed penalty when performing straight binary addition.

For twos complement, the worst case is when the carry from the LSB
has to propagate all the way to the MSB. That happnes when the two
operands are x and -x. For twos complement subtraction, the second
operand is ones complemented and a carry in is forced. Worst case
is when the two operands are equal, and the forced carry propagates.

The condition for a carry out from any position is that either both
operands have a one bit in that position, or at least one has a
one bit and there is a carry in. Those two conditins are 
separately called carry generate and carry propagate, and this
logic is used to make carry lookahead adders.

For a ones complement adder, if there are no carries there is no
waiting for carry. Adding x and ~x generates -0 with no carries.
A carry can start in any position, and worst case propagates 
around until it gets to a position that doesn't propagate.

For any x and y where x&y has one 1 bit, and x|y is ~0, 
the delay is the same, and equal to the worst case for a twos
complement adder.

> Certainly many mechanical adding machines represented negative numbers in
> ten's-complement format; I don't know of any that represented negative
> numbers in nines'-complement.  Some performed subtraction by having an
> operator enter a number on nines'-complement format *and plus a "plus one"
> button*, which is the pattern used for two's-complement subtraction, but
> I've never seen a unit where subtracting 2 from 1 would yield 999,998.

It is hard to say by now. Some early computers were decimal, with
ten signal lines per digit. Two of five code might have come along
not so much later.  Hollerith punched cards went back earlier than
computers, and had some convenience in processing data coded that way.

Many early binary machines use sign magnitude, possibly because
it was easier for humans to understand. It did take just a little
longer for twos complement to be understood and used.
 
> From what I can tell, two's-complement format is cheaper to implement 
> in hardware, faster to implement in hardware, and easier to work with 
> in software, than ones'-complement format.  

The end-around carry costs one wire, and as above, the worst case
is the same. On average it might be faster, but for usual 
synchronous logic you time for worst case. Carry lookahead works
in either case. The negative zero does complicate software a
little bit, but then twos complement has the strange most negative
value.

> The only situation I can see where ones' complement would 
> have advantages would be when performing division, and even 
> there the only advantage would be that hardware to
> normalize both operands to positive and invert the result would be a
> lot cheaper in sign-magnitude format and a little cheaper in ones'
> complement than would be hardware in two's-complement, but since the
> performance penalty for doing such normalization in software for those
> cases where code didn't know in advance whether values would be positive
> or negative would be pretty slight I don't see that as a very compelling
> factor.

For some years, computers had an accumulator and MQ register.
You do multiply as a loop in software, either adding or not,
and then shifting the partial product one bit. As multiplier
each multiplier bit is used up, the product needs one more bit,
so you can arrange a double register shift appropriately.

For divide, you start with the double length dividend in MQ and AC,
as each quotient bit is produced, the dividend shifts one bit.
The result is the quotient in the left, and the remainder in
the right.  And yes, all this works much better in sign 
magnitude form.

> Any idea *why* one's-complement format emerged as a standard, given that
> in the mechanical-computing world ten's-complement dominated over
> nines' complement?

I am not sure about early decimal computers, but I think sign
magnitude was usual. One is that it matched closer the way
punched cards were used. 

It is hard now, knowing what we know, to try to go back and
consider the thoughts of people 60 or 70 years ago. 

If you follow that Atanasoff story, and the Eckert-Mauchly
patents, you can get some idea on how the thoughts went.

https://en.wikipedia.org/wiki/Honeywell,_Inc._v._Sperry_Rand_Corp.

you might think that is all ancient history, but the patent 
decision was 1973, about the time that the 8080 was being developed.

-- glen

[toc] | [prev] | [next] | [standalone]

#72089 — Re: Ones' complement subtraction

On Tuesday, October 6, 2015 at 3:56:00 PM UTC-5, glen herrmannsfeldt wrote:
> For any x and y where x&y has one 1 bit, and x|y is ~0, 
> the delay is the same, and equal to the worst case for a twos
> complement adder.

Given two N-bit straight binary adders with P and G outputs, one can
produce a straight binary adder that's twice as big by adding a little
glue logic which will add an extra delay which is independent of N, so
the overall speed ends up being proportional to lgN.  I don't think
things work out so nicely with ones' complement.  Maybe people weren't
trying to use such designs?

> Many early binary machines use sign magnitude, possibly because
> it was easier for humans to understand. It did take just a little
> longer for twos complement to be understood and used.

I find it curious that people would could work with ten's-complement
adding machines would find ones' complement easier than two's-complement,
though perhaps the people working with electronic computers weren't using
ten's-complement adding machines?  Or perhaps the ten's-complement adding
machines, despite their mechanical simplicity compared with sign/magnitude,
were actually a later invention which didn't actually appear until after
ones'-complement math was already established in the electronic world?

> The end-around carry costs one wire, and as above, the worst case
> is the same. On average it might be faster, but for usual 
> synchronous logic you time for worst case. Carry lookahead works
> in either case. The negative zero does complicate software a
> little bit, but then twos complement has the strange most negative
> value.

What about serial adders?  From what I recall, the first stored-program
computer used 32-bit words, but addition was performed one bit at a time.
It wouldn't find out about a carry in the top bit until after it had
already read, processed, and written back all the other bits.  Straight
binary arithmetic can be done in a single pass, but both sign-magnitude
and ones'-complement would require one pass to determine the sign bit
and a second pass to compute the final result.

> For some years, computers had an accumulator and MQ register.
> You do multiply as a loop in software, either adding or not,
> and then shifting the partial product one bit. As multiplier
> each multiplier bit is used up, the product needs one more bit,
> so you can arrange a double register shift appropriately.

Indeed.  Unless one needs a result size larger than the operand
size, such multiplication can be done essentially as easily with
two's complement as with sign+magnitude, and more easily with those
than with ones'-complement.

> For divide, you start with the double length dividend in MQ and AC,
> as each quotient bit is produced, the dividend shifts one bit.
> The result is the quotient in the left, and the remainder in
> the right.  And yes, all this works much better in sign 
> magnitude form.

Division is the only operation which is awkward in two's-complement
form, and I'm really not sure that support for signed division is
really a good thing.  If software is responsible for signed-division
behavior, it can use floored, rounding, or truncating division with
roughly equal ease.  Having hardware do truncating division which is
seldom what's actually required doesn't really help much.

[toc] | [prev] | [next] | [standalone]

#72102 — Re: Ones' complement subtraction

supercat@casperkitty.com wrote:

(snip, I wrote)

>> For any x and y where x&y has one 1 bit, and x|y is ~0, 
>> the delay is the same, and equal to the worst case for a twos
>> complement adder.
 
> Given two N-bit straight binary adders with P and G outputs, one can
> produce a straight binary adder that's twice as big by adding a little
> glue logic which will add an extra delay which is independent of N, so
> the overall speed ends up being proportional to lgN.  I don't think
> things work out so nicely with ones' complement.  Maybe people weren't
> trying to use such designs?

I think in that case, with only a little more work, you can still
do the end around carry. 

But it isn't so convenient if you want to do the two adds one after
the other.
 
>> Many early binary machines use sign magnitude, possibly because
>> it was easier for humans to understand. It did take just a little
>> longer for twos complement to be understood and used.
 
> I find it curious that people would could work with ten's-complement
> adding machines would find ones' complement easier than two's-complement,
> though perhaps the people working with electronic computers weren't using
> ten's-complement adding machines?  Or perhaps the ten's-complement adding
> machines, despite their mechanical simplicity compared with sign/magnitude,
> were actually a later invention which didn't actually appear until after
> ones'-complement math was already established in the electronic world?

Well, tens complement sort of comes accidentally in wheel oriented
mechanical adders. 
 
>> The end-around carry costs one wire, and as above, the worst case
>> is the same. On average it might be faster, but for usual 
>> synchronous logic you time for worst case. Carry lookahead works
>> in either case. The negative zero does complicate software a
>> little bit, but then twos complement has the strange most negative
>> value.
 
> What about serial adders?  From what I recall, the first stored-program
> computer used 32-bit words, but addition was performed one bit at a time.
> It wouldn't find out about a carry in the top bit until after it had
> already read, processed, and written back all the other bits.  Straight
> binary arithmetic can be done in a single pass, but both sign-magnitude
> and ones'-complement would require one pass to determine the sign bit
> and a second pass to compute the final result.

Yes, sign magnitude and ones complement aren't so good for serial
adders.

You can even see that in the instruction timing for packed decimal
on some S/360 models. They do the addition BCD digit serial,
and then recomplement when the result is negative. 

That is, recomplement is the word for converting negative values
in tens complement to sign magnitude results.
 
>> For some years, computers had an accumulator and MQ register.
>> You do multiply as a loop in software, either adding or not,
>> and then shifting the partial product one bit. As multiplier
>> each multiplier bit is used up, the product needs one more bit,
>> so you can arrange a double register shift appropriately.
 
> Indeed.  Unless one needs a result size larger than the operand
> size, such multiplication can be done essentially as easily with
> two's complement as with sign+magnitude, and more easily with those
> than with ones'-complement.

OK, the IBM 704, where Fortran originated, has 36 bit words
for 36 bit floating point and 16 bit sign magnitude integers.
In C terms, integers have 20 padding bits. 
 
>> For divide, you start with the double length dividend in MQ and AC,
>> as each quotient bit is produced, the dividend shifts one bit.
>> The result is the quotient in the left, and the remainder in
>> the right.  And yes, all this works much better in sign 
>> magnitude form.
 
> Division is the only operation which is awkward in two's-complement
> form, and I'm really not sure that support for signed division is
> really a good thing.  If software is responsible for signed-division
> behavior, it can use floored, rounding, or truncating division with
> roughly equal ease.  Having hardware do truncating division which is
> seldom what's actually required doesn't really help much.

Yes, the division algorithms that I know about convert to sign
magnitude, divide, and convert back. Of course, divide is slow
enough that it isn't a big contribution to the time.

It is this conversion, and earlier sign magnitude machines, that
gives the results we see for divide with negative dividend
or divisor.

One is that Fortran requires the quotient of a negative dividend
and positive divisor to round toward zero.

-- glen

[toc] | [prev] | [next] | [standalone]

#72008

supercat@casperkitty.com writes:
> On Monday, October 5, 2015 at 1:59:45 PM UTC-5, Keith Thompson wrote:
>> Another problem is that the input character is treated as an unsigned
>> char and converted to signed int.  If unsigned char fits in the range of
>> signed int, that's not a problem.  But if not, and if you read a
>> character with a value exceeding INT_MAX, then the conversion to int
>> yields an implementation-defined result or raises an
>> implementation-defined signal.  Probably the conversion will do the
>> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.
>
> If  James Kuyper's citation of 7.21.2p3 is accurate, I would think that any
> platform where UCHAR_MAX > INT_MAX would be required to use an "int" type
> which supported a value which behaved as -INT_MAX-1.  I think it might be
> possible for a ones'-complement or sign-magnitude implementation to meet
> the requirement if the bit pattern for "negative zero" was never generated
> by any calculations within the range of "int" but was produced by trying to
> convert "INT_MAX+1U" to "int", and if converting that value to "unsigned"
> yielded "INT_MAX+1U".

Yes, James raised some points that I hadn't thought of.  The required
behavior for stdio seems to impose some additional requirements on how
certain integer conversions behave.

Note that that's relevant only for implementations with UCHAR_MAX >
INT_MAX.  As I mentioned elsethread, there are currently very few such
impementations, and as far as I know they're all freestanding (which
means they needn't support stdio, which means the additional requirement
don't apply.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72003

Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)

(someone wrote)  
>>> getchar() doesn't operate on plain char values.  It returns the next
>>> input character *as an unsigned char* converted an int.

>> OK, so unsigned even on systems with signed char.
 
> That would be clearer as:
 
>    OK, so unsigned even on systems where plain char is signed.
 
> since "signed char" is a distinct type.  But yes.

I usually would write (signed char) if I meant that, but maybe
not always, and yes it would have been clearer.

(and I also wrote)
 
>> And what about the sizeof(char)==sizeof(int) case?
 
> In that case, if getchar() returns EOF you can't tell whether it
> indicates that there are no more characters to be read, or whether it
> actually read a character with that value (0xFFFF if CHAR_BIT==16, for
> example).  You can call feof() and ferror() after getchar() returns EOF
> to distinguish those cases.

I was thinking about UTF-32, but it also occurs for UTF-16 on
systems with 16 bit int.
 
> Another problem is that the input character is treated as an unsigned
> char and converted to signed int.  If unsigned char fits in the range of
> signed int, that's not a problem.  But if not, and if you read a
> character with a value exceeding INT_MAX, then the conversion to int
> yields an implementation-defined result or raises an
> implementation-defined signal.  Probably the conversion will do the
> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.

Seems to me that this already happens on systems where char is signed.

The (char) is converted to (unsigned char) for fgetc(), then after
reading it back to (char). 

Is (char) conversion defined different from (int) conversion?
 
> In practice, I don't think there are any hosted implementations with
> UCHAR_MAX > INT_MAX, and freestanding implementations aren't required to
> provide getchar() and friends.

I suspect UTF-16 will get more popular, but UTF-32 will likely 
stay rare for a while.

-- glen
 

[toc] | [prev] | [next] | [standalone]

#72011

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>>> And what about the sizeof(char)==sizeof(int) case?
>  
>> In that case, if getchar() returns EOF you can't tell whether it
>> indicates that there are no more characters to be read, or whether it
>> actually read a character with that value (0xFFFF if CHAR_BIT==16, for
>> example).  You can call feof() and ferror() after getchar() returns EOF
>> to distinguish those cases.
>
> I was thinking about UTF-32, but it also occurs for UTF-16 on
> systems with 16 bit int.

Plenty of systems support UTF-16 without making CHAR_BIT > 8.

>> Another problem is that the input character is treated as an unsigned
>> char and converted to signed int.  If unsigned char fits in the range of
>> signed int, that's not a problem.  But if not, and if you read a
>> character with a value exceeding INT_MAX, then the conversion to int
>> yields an implementation-defined result or raises an
>> implementation-defined signal.  Probably the conversion will do the
>> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.
>
> Seems to me that this already happens on systems where char is signed.
>
> The (char) is converted to (unsigned char) for fgetc(), then after
> reading it back to (char). 
> 
> Is (char) conversion defined different from (int) conversion?

There's no such conversion.  N1570 7.21.7.1p1:

    If the end-of-file indicator for the input stream pointed to by
    stream is not set and a next character is present, the fgetc
    function obtains that character as an unsigned char converted
    to an int and advances the associated file position indicator
    for the stream (if defined).

It doesn't read the character as a (plain) char and then convert it to
unsigned char.  It reads it directly as an unsigned char.  Before the
read, it doesn't have a type; it's just bits in whatever the input
stream is reading from.

>> In practice, I don't think there are any hosted implementations with
>> UCHAR_MAX > INT_MAX, and freestanding implementations aren't required to
>> provide getchar() and friends.
>
> I suspect UTF-16 will get more popular, but UTF-32 will likely 
> stay rare for a while.

Neither of those requires CHAR_BIT > 8.  See char16_t and char32_t in
<uchar.h> (new in C11).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72021

Keith Thompson <kst-u@mib.org> wrote:
>> Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)
>>>> And what about the sizeof(char)==sizeof(int) case?
  
(snip, I also wrote)
>> I was thinking about UTF-32, but it also occurs for UTF-16 on
>> systems with 16 bit int.
 
> Plenty of systems support UTF-16 without making CHAR_BIT > 8.

OK, but see below.
 
>>> Another problem is that the input character is treated as an unsigned
>>> char and converted to signed int.  If unsigned char fits in the range of
>>> signed int, that's not a problem.  But if not, and if you read a
>>> character with a value exceeding INT_MAX, then the conversion to int
>>> yields an implementation-defined result or raises an
>>> implementation-defined signal.  Probably the conversion will do the
>>> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.

(and I also wrote)

>> Seems to me that this already happens on systems where char is signed.

>> The (char) is converted to (unsigned char) for fgetc(), then after
>> reading it back to (char). 
 
>> Is (char) conversion defined different from (int) conversion?
 
> There's no such conversion.  N1570 7.21.7.1p1:
 
>    If the end-of-file indicator for the input stream pointed to by
>    stream is not set and a next character is present, the fgetc
>    function obtains that character as an unsigned char converted
>    to an int and advances the associated file position indicator
>    for the stream (if defined).
 
> It doesn't read the character as a (plain) char and then convert it to
> unsigned char.  It reads it directly as an unsigned char.  Before the
> read, it doesn't have a type; it's just bits in whatever the input
> stream is reading from.

Then it will be converted to signed (char) from (int), even
if the value is larger than CHAR_MAX.

I presume the value is the same as if the characters were read
directly into signed (char) without the intermediate (int).
 
>>> In practice, I don't think there are any hosted implementations with
>>> UCHAR_MAX > INT_MAX, and freestanding implementations aren't required to
>>> provide getchar() and friends.

>> I suspect UTF-16 will get more popular, but UTF-32 will likely 
>> stay rare for a while.
 
> Neither of those requires CHAR_BIT > 8.  See char16_t and char32_t in
> <uchar.h> (new in C11).

I was assuming the case where UTF-16 is popular enough that one
would just want to use (char). Java has been doing it for years
now, though it might take some years more for C.

-- glen

[toc] | [prev] | [next] | [standalone]

#72051

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>>> Keith Thompson <kst-u@mib.org> wrote:
[...]
>>> The (char) is converted to (unsigned char) for fgetc(), then after
>>> reading it back to (char). 
>  
>>> Is (char) conversion defined different from (int) conversion?
>  
>> There's no such conversion.  N1570 7.21.7.1p1:
>  
>>    If the end-of-file indicator for the input stream pointed to by
>>    stream is not set and a next character is present, the fgetc
>>    function obtains that character as an unsigned char converted
>>    to an int and advances the associated file position indicator
>>    for the stream (if defined).
>  
>> It doesn't read the character as a (plain) char and then convert it to
>> unsigned char.  It reads it directly as an unsigned char.  Before the
>> read, it doesn't have a type; it's just bits in whatever the input
>> stream is reading from.
>
> Then it will be converted to signed (char) from (int), even
> if the value is larger than CHAR_MAX.

How is it converted to char?  fgetc() doesn't perform any such
conversion; it returns an int.  If calling code happens to convert the
result to char, that's the caller's issue.

> I presume the value is the same as if the characters were read
> directly into signed (char) without the intermediate (int).

That depends on the code that does the conversion.  Do you have an
example in mind?

>>>> In practice, I don't think there are any hosted implementations with
>>>> UCHAR_MAX > INT_MAX, and freestanding implementations aren't required to
>>>> provide getchar() and friends.
>
>>> I suspect UTF-16 will get more popular, but UTF-32 will likely 
>>> stay rare for a while.
>  
>> Neither of those requires CHAR_BIT > 8.  See char16_t and char32_t in
>> <uchar.h> (new in C11).
>
> I was assuming the case where UTF-16 is popular enough that one
> would just want to use (char). Java has been doing it for years
> now, though it might take some years more for C.

A particular C implementation could define CHAR_BIT==16 for the
purpose of making UTF-16 handling easier, but I've never heard of
one that does so.  Such an implementation would be incompatible
with POSIX, and probably with Windows.  And I don't think UTF-16
is becoming more popular; Windows uses it a lot, but outside that
UTF-8 is the most popular Unicode encoding.

Java, as I understand it, defined its 16-bit char type when Unicode
had fewer than 2**16 defined code points, so it was effectively
UCS-2.  I suspect that if it were being defined today, it would
make char 8 bits and use UTF-8 by default (perhaps with provisions
to use 32-bit characters internally).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72076

On Tuesday, October 6, 2015 at 10:55:28 AM UTC-5, Keith Thompson wrote:
> Java, as I understand it, defined its 16-bit char type when Unicode
> had fewer than 2**16 defined code points, so it was effectively
> UCS-2.  I suspect that if it were being defined today, it would
> make char 8 bits and use UTF-8 by default (perhaps with provisions
> to use 32-bit characters internally).

Personally, I suspect the most efficient thing to do would have been to
have "String" be an abstract type with some magic attribute that would
for the existence of derived-types which would report themselves as "String"
but could only be defined in the same package as "String" itself.  The
majority of strings generated by most programs will contain only ASCII
characters, and since strings are immutable using a char[] backing store
will mean half the space used by ASCII-only strings will be wasted.  If
there exists a native method that can unpack a byte[] into a char[],
the reduced cache footprint enabled by the smaller size of byte[] should
more than offset the overhead of sometimes using char[] and sometimes
byte[].

[toc] | [prev] | [next] | [standalone]

#72022

On 10/5/15 5:53 AM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>> In the case of getchar() with char as unsigned, no valid char
>>> value is -1.  (I am not sure what systems with sizeof(int) equal
>>> to sizeof(char) do.)
>
>>> If valid char values are 0 to 255, -1 is out of band.
>
>>> If char values are, for example, -128 to 127 then -1 is in band.
>
>> getchar() doesn't operate on plain char values.  It returns the next
>> input character *as an unsigned char* converted an int.
>
> OK, so unsigned even on systems with signed char.
>
> And what about the sizeof(char)==sizeof(int) case?
>
> -- glen
>

I HAVE used such a system, and their documentation warned that just 
because getchar() returned EOF, wasn't proof that end of file was 
reached, you needed to check feof() to be sure. If you knew that your 
file was 'text', you didn't need to do this, as ASCII characters were 
all values 0 to 127, only binary files could have a -1 character in 
them. (I believe this is even standard conforming).

[toc] | [prev] | [next] | [standalone]

#72044

On 10/05/2015 11:16 PM, Richard Damon wrote:
> On 10/5/15 5:53 AM, glen herrmannsfeldt wrote:
...
>> And what about the sizeof(char)==sizeof(int) case?
...
> I HAVE used such a system, and their documentation warned that just 
> because getchar() returned EOF, wasn't proof that end of file was 
> reached, you needed to check feof() to be sure. If you knew that your 
> file was 'text', you didn't need to do this, as ASCII characters were 
> all values 0 to 127, only binary files could have a -1 character in 
> them. (I believe this is even standard conforming).

"Data read in from a text stream will necessarily compare equal to the
data that were earlier written out to that stream
only if: the data consist only of printing characters and the control
characters horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last character is a
new-line character." (7.21.2p2).

Therefore, if all of the characters permitted by 7.21.2p2 are
non-negative, then such an implementation could be fully conforming.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#72052

Richard Damon <Richard@Damon-Family.org> writes:
> On 10/5/15 5:53 AM, glen herrmannsfeldt wrote:
[...]
>> And what about the sizeof(char)==sizeof(int) case?
>
> I HAVE used such a system, and their documentation warned that just
> because getchar() returned EOF, wasn't proof that end of file was
> reached, you needed to check feof() to be sure. If you knew that your
> file was 'text', you didn't need to do this, as ASCII characters were
> all values 0 to 127, only binary files could have a -1 character in
> them. (I believe this is even standard conforming).

What system was it?  (And did the documentation warn you to call both
feof() and ferror()?)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72109

On 10/6/15 11:56 AM, Keith Thompson wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>> On 10/5/15 5:53 AM, glen herrmannsfeldt wrote:
> [...]
>>> And what about the sizeof(char)==sizeof(int) case?
>>
>> I HAVE used such a system, and their documentation warned that just
>> because getchar() returned EOF, wasn't proof that end of file was
>> reached, you needed to check feof() to be sure. If you knew that your
>> file was 'text', you didn't need to do this, as ASCII characters were
>> all values 0 to 127, only binary files could have a -1 character in
>> them. (I believe this is even standard conforming).
>
> What system was it?  (And did the documentation warn you to call both
> feof() and ferror()?)
>

It was for a TI DSP chip many years ago. The processor basically had no 
support for manipulation things smaller than 16 bits (its word size), 
memory was word addressed. My guess is that they decided that it wasn't 
worth implementing all the warts to fake out having an 8 bit char, and 
figured users weren't going to be using a lot of text, so they just 
stored things 1 '8 bit char' per 16 bit word.

[toc] | [prev] | [next] | [standalone]

#72114

On Tuesday, October 6, 2015 at 10:13:54 PM UTC-5, Richard Damon wrote:
> It was for a TI DSP chip many years ago. The processor basically had no 
> support for manipulation things smaller than 16 bits (its word size), 
> memory was word addressed. My guess is that they decided that it wasn't 
> worth implementing all the warts to fake out having an 8 bit char, and 
> figured users weren't going to be using a lot of text, so they just 
> stored things 1 '8 bit char' per 16 bit word.

I've used the 320C5x, which I liked, and the 320F206 which I thought seemed
a little silly; it was basically a 320C5x but with all of the ways of avoiding
slow-downs avoided.  The 320C5x had the equivalent of FORTRAN's "DO" loop in
hardware, so one could run a block of code (not just a single instruction) N
times with *zero* overhead per loop provided that one knew at least two
cycles before the end of the loop whether it needed to early-exit.  The
320C5x also had "conditional skip" instructions as well as "delayed" forms
of branches which would execute the next two already-fetched instructions
before taking a branch [reducing the branch cost from 4 cycles to 2].  The
320F206 eliminated all of those features, greatly limiting the kinds of
things one could do efficiently.

An interesting thing about those processors from the standpoint of C
programming was that they had a 32-bit accumulator, but because it could
only be moved to/from memory 16 bits at a time "int" was 16 bits.  As a
consequence, an expression like "x+y > z" would generally be evaluated
as though it was "(long)x+y > z".  Writing the code as something like
"(int)((unsigned)x+y) > z" would make it a lot slower, since it would
IIRC have to store the low half of the accumulator and load it back
with sign extension.  Too bad there's no way to write code with the
semantics "I'm perfectly happy if this expression gets evaluated as long
or it wraps around like a 16-bit int, but it must not corrupt the
functioning of other code".

[toc] | [prev] | [next] | [standalone]

#72138

Richard Damon <Richard@Damon-Family.org> writes:
> On 10/6/15 11:56 AM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> On 10/5/15 5:53 AM, glen herrmannsfeldt wrote:
>> [...]
>>>> And what about the sizeof(char)==sizeof(int) case?
>>>
>>> I HAVE used such a system, and their documentation warned that just
>>> because getchar() returned EOF, wasn't proof that end of file was
>>> reached, you needed to check feof() to be sure. If you knew that your
>>> file was 'text', you didn't need to do this, as ASCII characters were
>>> all values 0 to 127, only binary files could have a -1 character in
>>> them. (I believe this is even standard conforming).
>>
>> What system was it?  (And did the documentation warn you to call both
>> feof() and ferror()?)
>
> It was for a TI DSP chip many years ago. The processor basically had no 
> support for manipulation things smaller than 16 bits (its word size), 
> memory was word addressed. My guess is that they decided that it wasn't 
> worth implementing all the warts to fake out having an 8 bit char, and 
> figured users weren't going to be using a lot of text, so they just 
> stored things 1 '8 bit char' per 16 bit word.

Interesting.  I've heard about C implementations for DSPs having
CHAR_BIT > 8, but I've assumed that they would be freestanding
implementations that therefore would not be required to provide
<stdio.h>.  Apparently that was a bad assumption.

What is a full hosted implementation, or was it a freestanding
implementation that just happened to provide <stdio.h>?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72143

On Wednesday, October 7, 2015 at 10:43:57 AM UTC-5, Keith Thompson wrote:
> What is a full hosted implementation, or was it a freestanding
> implementation that just happened to provide <stdio.h>?

The TI C compiler is a freestanding implementation, but many such
implementations define <stdio.h> even though not required to do so.
Typically implementations will require that an application which
e.g. uses "printf" must also provide definitions for putchar,
fputc, and/or fwrite, and (unless the implementation only requires
putchar) must also supply definitions for stdout.  Many of the
platforms where I've looked at such things define FILE as something
like "struct __FILE", but don't define that structure, thus allowing
the application programmer to interface code using the C Standard
Library I/O functions with whatever form of I/O routines have been
written on the target hardware.  In my own code, I define FILE as
a structure holding function pointers for I/O routines, and define
the C library I/O routines as calling those pointers with the FILE
itself passed as a parameter.  This construct would make it easy
for a system with e.g. an LCD screen and a serial port to have one
FILE object which draws data to the LCD screen and another which
would cause data to be sent to the serial port, without any of the
code passing around the the FILE* pointers to know anything about
that.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web