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

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

[OT] programming

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

Contents

  [OT] programming asetofsymbols@gmail.com - 2015-10-07 00:37 -0700
    Re: [OT] programming mark.bluemel@gmail.com - 2015-10-07 00:49 -0700
      Re: [OT] programming asetofsymbols@gmail.com - 2015-10-07 01:06 -0700
        Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-07 10:02 +0100
          Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 02:18 -0700
          Re: [OT] programming "Bill Cunningham" <nospam@nspam.invalid> - 2015-10-08 19:07 -0400
            Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-09 00:20 +0100
              Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 00:48 +0100
                Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-08 17:48 -0700
                  Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:38 +0200
                    Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:31 -0700
                  Re: [OT] programming Richard Damon <Richard@Damon-Family.org> - 2015-10-09 08:34 -0400
                    Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 12:05 -0700
                Re: [OT] programming Richard Heathfield <rjh@cpax.org.uk> - 2015-10-09 08:28 +0100
                  Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:50 +0200
                    Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:26 -0700
                      Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-11 20:30 +0200
                        Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 12:09 -0700
                  Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 10:40 +0100
                  Re: [OT] programming Keith Thompson <kst-u@mib.org> - 2015-10-09 09:23 -0700
                    Re: [OT] programming Bartc <bc@freeuk.com> - 2015-10-09 17:35 +0100
                      Re: [OT] programming Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-09 22:50 -0700
              Re: [OT] programming David Brown <david.brown@hesbynett.no> - 2015-10-09 10:34 +0200
            Re: [OT] programming glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-09 00:20 +0000
        Re: [OT] programming "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-07 09:37 -0700

Page 1 of 2  [1] 2  Next page →

#72115 — [OT] programming

The clue in programming is making
easy what is difficult
short what could be long

[toc] | [next] | [standalone]

#72116

On Wednesday, 7 October 2015 08:38:02 UTC+1, asetof...@gmail.com  wrote:
> The clue in programming is making
> easy what is difficult
> short what could be long

The winds are colder
Programming haikus appear
Do they add value?

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

#72118

I said that because people seems
to me use their intelligence
for make more difficult than what
could be something...

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

#72122

On 07/10/15 09:06, asetofsymbols@gmail.com wrote:
> I said that because people seems
> to me use their intelligence
> for make more difficult than what
> could be something...

Undoubtedly some people do. Unfortunately, though, very often it is not 
the case that people are making things more difficult than they need to 
be, but that things are more difficult than first meets the eye.

Consider, for example, a program that will find out the bit distribution 
of a file, by which I mean the number of times each particular bit is 
used within the file.

What could be simpler?

Okay, how are we going to find out the name of the file? Command line? 
Good idea. But what if we're on a platform where command line arguments 
are not supported? (I don't know if there is such a platform, but the C 
Standard certainly doesn't forbid it: argc is allowed to be 0.) Okay, so 
we could read the filename from standard input. But that opens the 
possibility of EOF, so we have to test for that. Once we've got a 
filename (and stripped off any trailing newline if we used fgets to read 
it, and what do we do if the newline isn't there?), how can we be sure 
that it's a legal filename? Does the file exist? Does the program have 
permission to read it? Of course, we could just try opening it and 
seeing what happens, but if we fail we ought to be able to tell the user 
/why/ we failed.

Now we need an array to store the results. Will an unsigned long int for 
each bit be sufficient? Large files are becoming more common, and it 
would only take a 32GB+1byte file to break 32-bit unsigned longs. But 
that assumes there are 8 bits in a byte. On most systems that's true, 
but at least one 32-bit byte platform does exist, so maybe we need to 
cater for that.

And so on, and so on. For such a simple task, there are so many tiny 
complications. And they all add up.

The complications are real. They are not invented for the sake of making 
things difficult. And when we write a "simple" program, very often it is 
because we are conveniently ignoring a vast number of complications, 
hand-waving them away because we only want to solve the problem that is 
in front of us, without worrying too much about the complexities because 
we're fairly sure they won't matter.

A week or three ago, I blew away an important file (well, not that 
important now, but it was important /then/) because I put it in the 
wrong place in the command line of a program I'd written. I had a 
backup, obviously, but it turned out that I'd blown that away too, 
because I'd run the program with the wrong argument /twice/, and so the 
backup became corrupted.

I had to reconstruct the file using handwritten records. Painfully slow, 
but it taught me to be even more careful about validation than I already 
was. I had over-simplified, and I paid the price for that. What I should 
have done was to check to see whether the file I was overwriting already 
existed and, if so, double-check with the user that it was okay to 
destroy the previous contents of that file. Had I seen such a message, 
I'd have been able to back out before any damage was done.

Having said that, I think you still have a point of sorts. I see people 
arguing over this or that, and thinking "why are they bothering to fight 
over whether method A should be done this way or that way, when surely 
the obvious thing to do is to use method B instead, which is a lot 
simpler and a lot cleaner?"

But much of the time the complication is there because life is 
complicated, and we have to deal with that complicated reality instead 
of the simple reality that many of us would prefer, but which few of us 
seem to be able to agree on.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#72124

On Wednesday, October 7, 2015 at 10:02:20 AM UTC+1, Richard Heathfield wrote:
> On 07/10/15 09:06, asetofsymbols@gmail.com wrote:
> > I said that because people seems
> > to me use their intelligence
> > for make more difficult than what
> > could be something...
> 
> Undoubtedly some people do. Unfortunately, though, very often it is not 
> the case that people are making things more difficult than they need to 
> be, but that things are more difficult than first meets the eye.
> 
> Consider, for example, a program that will find out the bit distribution 
> of a file, by which I mean the number of times each particular bit is 
> used within the file.
> 
> What could be simpler?
> 
> Okay, how are we going to find out the name of the file? Command line? 
>
> Now we need an array to store the results. Will an unsigned long int for 
> each bit be sufficient? Large files are becoming more common, and it 
> would only take a 32GB+1byte file to break 32-bit unsigned longs. But 
> that assumes there are 8 bits in a byte. On most systems that's true, 
> but at least one 32-bit byte platform does exist, so maybe we need to 
> cater for that.
> 
> And so on, and so on. For such a simple task, there are so many tiny 
> complications. And they all add up.
> 
A lot of the complications are caused by trivial data reformatting.
Every pure function is in a sense a data reformatting function, by a trivial
data reformatting function I mean one that doesn't do what we regard as
a calculation, but just pads out or rearranges fields, or does complicated
but completely routine transformations like from string to floating point
conversions.

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

#72228

"Richard Heathfield" <rjh@cpax.org.uk> wrote in message 
news:mv2muo$m6o$1@dont-email.me...

[...]

But
> that assumes there are 8 bits in a byte. On most systems that's true, but 
> at least one 32-bit byte platform does exist, so maybe we need to cater 
> for that.

    What would that be? There are still old DEC PDPs around too. With all 
kinds of bit sizes of bytes and buses.

Bill

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

#72229

On 09/10/15 00:07, Bill Cunningham wrote:
> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
> news:mv2muo$m6o$1@dont-email.me...
>
> [...]
>
> But
>> that assumes there are 8 bits in a byte. On most systems that's true, but
>> at least one 32-bit byte platform does exist, so maybe we need to cater
>> for that.
>
>      What would that be?

Analog Devices introduced the SHARC digital signal processor some time 
in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest 
addressable unit is 32 bits wide.

It's a good architecture for breaking C programs - for example, any 
program that declares an array of UCHAR_MAX + 1 elements (as some of my 
programs do) is heading for a world of hurt.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#72230

On 09/10/2015 00:20, Richard Heathfield wrote:
> On 09/10/15 00:07, Bill Cunningham wrote:
>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>> news:mv2muo$m6o$1@dont-email.me...
>>
>> [...]
>>
>> But
>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>> but
>>> at least one 32-bit byte platform does exist, so maybe we need to cater
>>> for that.
>>
>>      What would that be?
>
> Analog Devices introduced the SHARC digital signal processor some time
> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
> addressable unit is 32 bits wide.

That doesn't make a byte 32 bits. Any more than a machine having a 
bit-addressable memory would have 1-bit bytes.

(The data sheet for that device mostly uses 'bits' or 'words'. Where it 
uses 'bytes', then AFAICS it's to do with external memory or 
interfacing, and refers to 8-bit bytes. Possibly helped by 800M 
bytes/second sounding better than 200M words/second.)

-- 
Bartc

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

#72233

Bartc <bc@freeuk.com> writes:
> On 09/10/2015 00:20, Richard Heathfield wrote:
>> On 09/10/15 00:07, Bill Cunningham wrote:
>>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>>> news:mv2muo$m6o$1@dont-email.me...
>>>
>>> [...]
>>>
>>> But
>>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>>> but
>>>> at least one 32-bit byte platform does exist, so maybe we need to cater
>>>> for that.
>>>
>>>      What would that be?
>>
>> Analog Devices introduced the SHARC digital signal processor some time
>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>> addressable unit is 32 bits wide.
>
> That doesn't make a byte 32 bits. Any more than a machine having a 
> bit-addressable memory would have 1-bit bytes.

True, but it would probably be reasonable for a C implementation for
that DSP to have CHAR_BIT==32.  (It might also be reasonable to have
CHAR_BIT==8 if it needs to communicate with octet-oriented systems, but
as I understand it DSPs typically don't need to do that kind of thing.)

-- 
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]

#72245

On 09/10/15 02:48, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 09/10/2015 00:20, Richard Heathfield wrote:
>>> On 09/10/15 00:07, Bill Cunningham wrote:
>>>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>>>> news:mv2muo$m6o$1@dont-email.me...
>>>>
>>>> [...]
>>>>
>>>> But
>>>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>>>> but
>>>>> at least one 32-bit byte platform does exist, so maybe we need to cater
>>>>> for that.
>>>>
>>>>      What would that be?
>>>
>>> Analog Devices introduced the SHARC digital signal processor some time
>>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>>> addressable unit is 32 bits wide.
>>
>> That doesn't make a byte 32 bits. Any more than a machine having a 
>> bit-addressable memory would have 1-bit bytes.
> 
> True, but it would probably be reasonable for a C implementation for
> that DSP to have CHAR_BIT==32. 

Yes, that is common practice for such devices.  And technically, that
means they have a 32-bit "byte" as far as C is concerned - but to avoid
confusion, it is very rare to refer to them as a "byte".  If you want to
remain sane while programming these devices, you stick to "uint32_t" and
"int32_t" (or 64-bit types, floats, etc., as needed) so that you know
where you stand.

> (It might also be reasonable to have
> CHAR_BIT==8 if it needs to communicate with octet-oriented systems, but
> as I understand it DSPs typically don't need to do that kind of thing.)
> 

DSP's usually have /lots/ of communication via octet-oriented channels,
such as UARTs, SPI, Ethernet, etc.  And working with them is a PITA
because they can't deal with 8-bit data directly.

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

#72276

David Brown <david.brown@hesbynett.no> writes:
> On 09/10/15 02:48, Keith Thompson wrote:
[...]         
>> (It might also be reasonable to have
>> CHAR_BIT==8 if it needs to communicate with octet-oriented systems, but
>> as I understand it DSPs typically don't need to do that kind of thing.)
>
> DSP's usually have /lots/ of communication via octet-oriented channels,
> such as UARTs, SPI, Ethernet, etc.  And working with them is a PITA
> because they can't deal with 8-bit data directly.

I think you just answered the question I asked a moment ago.
I probably should have read the whole thread first.

Still, I suspect that most of the system's work involves 32-bit
quantities, and making CHAR_BIT==8, though it would amke the
octet-oriented tasks easier, might slow down it's main job.

This is almost pure speculation; I've never programmed for a DSP.
But I would guess that if optimizing octet-oriented processing were
a priority, it would have been supported by the hardware.

-- 
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]

#72260

On 10/8/15 8:48 PM, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 09/10/2015 00:20, Richard Heathfield wrote:
>>> On 09/10/15 00:07, Bill Cunningham wrote:
>>>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>>>> news:mv2muo$m6o$1@dont-email.me...
>>>>
>>>> [...]
>>>>
>>>> But
>>>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>>>> but
>>>>> at least one 32-bit byte platform does exist, so maybe we need to cater
>>>>> for that.
>>>>
>>>>       What would that be?
>>>
>>> Analog Devices introduced the SHARC digital signal processor some time
>>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>>> addressable unit is 32 bits wide.
>>
>> That doesn't make a byte 32 bits. Any more than a machine having a
>> bit-addressable memory would have 1-bit bytes.
>
> True, but it would probably be reasonable for a C implementation for
> that DSP to have CHAR_BIT==32.  (It might also be reasonable to have
> CHAR_BIT==8 if it needs to communicate with octet-oriented systems, but
> as I understand it DSPs typically don't need to do that kind of thing.)
>

The SHARC communicated fine with octet-oriented systems. They just chose 
to store octets 1 per word, rather than the more 'traditional' packing 
them 1 per 8-bit byte. (By C, they did still pack them 1 per byte, as C 
defines a byte as a char, and the SHARC defined a char as the same as a 
word, this is just bigger than 8 bits).

This made sense for this processor as it was very poor at trying to deal 
with things smaller than a word.

As far as I remember, the C compiler for this chip was fairly standards 
compliant (with a number of extensions to handle their special 
abilities), maybe not a good a gcc now with pedantic, but for the period 
pretty good. This was in part because when they wrote the standard, they 
were careful to make usable on 'weird' architectures like this.

It was also common for people to forget about weird, or even just 
different, architectures and just assume that things would always work 
the way they assumed (causing all sorts of bugs to pop up when the 
'common' architecture changed, like int moving from normally being 16 
bits to 32 bits, and now often being the same size as long).

We are now in an era where a lot of these 'weirdnesses' are just 
extremely uncommon, and many programmers have never experienced them. We 
also have an auxiliary standard, POSIX, which allows programmers to 
assume a lot of the common features (like 8 bit bytes, two's complement, 
etc), but it also imposes a lot of restrictions on services provided by 
the host operating system. It might make sense for a future version of 
the standard to add a testable extension, like was done for floating 
point, that would allow a program to check that it was being compiled on 
a system that was 'normal' (8 bit byte, two's complement, no padding for 
integers, etc, maybe even adding flat byte addressable memory space so 
common pointer hacks should work, or 'safe' overflow of signed values). 
Maybe a few sub-levels in this to handle some of the not quite so common 
assumptions that can be made (like signed right shifts). I wouldn't want 
C defined so that these MUST be true, just allow programs to test that 
it is true and then be able to assume them, or fail to be able to be 
compiled.

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

#72301

Richard Damon <Richard@Damon-Family.org> writes:
[...]
> We are now in an era where a lot of these 'weirdnesses' are just 
> extremely uncommon, and many programmers have never experienced them. We 
> also have an auxiliary standard, POSIX, which allows programmers to 
> assume a lot of the common features (like 8 bit bytes, two's complement, 
> etc), but it also imposes a lot of restrictions on services provided by 
> the host operating system.
[...]

POSIX does require CHAR_BIT==8, but does it really require two's
complement?

In its description of <limits.h>, POSIX requires signed char to have a
range of at least -128 to +127, but the required ranges for short, int,
and long are symmetric; for example, SHRT_MAX can be -32767.  That could
mean that one's complement and sign-and-magnitude are permitted, but it
could also mean that -32768 is allowed to be a trap representation.
(BTW, POSIX requires the range of int to be at least -2147483647 to
+2147483647.)

The POSIX  description of the abs() function says

    In two's-complement representation, the absolute value of the
    negative integer with largest magnitude {INT_MIN} might not be
    representable.

which could imply that two's-complement is optional.

Is there an explicit requirement in POSIX that signed integer types
(other than signed char, plain char if it's signed, and intN_t) must be
represented using 2's-complement?

-- 
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]

#72240

On 09/10/15 00:48, Bartc wrote:
> On 09/10/2015 00:20, Richard Heathfield wrote:
>> On 09/10/15 00:07, Bill Cunningham wrote:
>>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>>> news:mv2muo$m6o$1@dont-email.me...
>>>
>>> [...]
>>>
>>> But
>>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>>> but
>>>> at least one 32-bit byte platform does exist, so maybe we need to cater
>>>> for that.
>>>
>>>      What would that be?
>>
>> Analog Devices introduced the SHARC digital signal processor some time
>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>> addressable unit is 32 bits wide.
>
> That doesn't make a byte 32 bits.

3.6 gives the definition of 'byte': "addressable unit of data storage 
large enough to hold any member of the basic character set of the 
execution environment".

On that platform, no unit smaller than 32 bits is addressable.

It would be possible for a C implementation to set CHAR_BIT at 8 only if 
they jump through all the necessary hoops to ensure that the 
implementation behaves "as if" 8-bit units were addressable. I don't 
think the Analog Devices people went to that trouble.

On the other hand, somebody /did/ go to that trouble for... was it a 
Cray, or a Honeywell? I forget. Anyway, they had 64-bit bytes, but they 
decided, presumably for the sake of not getting shouted out by a lot of 
hairy C programmers, that they would emulate 8-bit bytes.

> Any more than a machine having a
> bit-addressable memory would have 1-bit bytes.

Bytes are at least 8 bits wide in C. So a 1-bit byte *in C* is not 
possible. On the other hand, I've mucked about with a 1-bit (virtual) 
processor which designated "byte" as "group of 1 contiguous bit". It had 
two one-bit bytes of addressable storage, and two one-bit op-codes. 
(Obviously it didn't do a lot.)

> (The data sheet for that device mostly uses 'bits' or 'words'. Where it
> uses 'bytes', then AFAICS it's to do with external memory or
> interfacing, and refers to 8-bit bytes. Possibly helped by 800M
> bytes/second sounding better than 200M words/second.)

The C Standard doesn't know about data sheets. It only knows that a byte 
is addressable. If the smallest addressable unit is 32 bits wide, then a 
byte is (at least) 32 bits wide, and to avoid that would require the 
compiler implementor to emulate an 8-bit-byte machine.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#72246

On 09/10/15 09:28, Richard Heathfield wrote:
> On 09/10/15 00:48, Bartc wrote:
>> On 09/10/2015 00:20, Richard Heathfield wrote:
>>> On 09/10/15 00:07, Bill Cunningham wrote:
>>>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>>>> news:mv2muo$m6o$1@dont-email.me...
>>>>
>>>> [...]
>>>>
>>>> But
>>>>> that assumes there are 8 bits in a byte. On most systems that's true,
>>>>> but
>>>>> at least one 32-bit byte platform does exist, so maybe we need to
>>>>> cater
>>>>> for that.
>>>>
>>>>      What would that be?
>>>
>>> Analog Devices introduced the SHARC digital signal processor some time
>>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>>> addressable unit is 32 bits wide.
>>
>> That doesn't make a byte 32 bits.
> 
> 3.6 gives the definition of 'byte': "addressable unit of data storage
> large enough to hold any member of the basic character set of the
> execution environment".
> 
> On that platform, no unit smaller than 32 bits is addressable.
> 
> It would be possible for a C implementation to set CHAR_BIT at 8 only if
> they jump through all the necessary hoops to ensure that the
> implementation behaves "as if" 8-bit units were addressable. I don't
> think the Analog Devices people went to that trouble.

The devices would be far more useful if they /did/ go to that trouble.
But you wouldn't expect that from a compiler toolchain that costs a mere
$20K (last I looked, the price was in that range), and a couple of years
ago brought out a new version with partial support for some C99 features.

For many "pure" DSPs, like the SHARC, it is best to buy the code for
them along with the chips.  Programming them is a highly specialised
task.  So you buy the chips along with a licence for code to do audio or
video codec handling (or does FIR filters, or FFTs, or whatever), with
all the necessary licenses, patent royalties, NDAs, and other
time-wasters, and view it as a black box that converts formats.  For
most of the applications in which a chip like the SHARC is really
appropriate, actually /programming/ the devices is the least of your
concerns - even though it is very different from "normal" C programming.

> 
> On the other hand, somebody /did/ go to that trouble for... was it a
> Cray, or a Honeywell? I forget. Anyway, they had 64-bit bytes, but they
> decided, presumably for the sake of not getting shouted out by a lot of
> hairy C programmers, that they would emulate 8-bit bytes.
> 
>> Any more than a machine having a
>> bit-addressable memory would have 1-bit bytes.
> 
> Bytes are at least 8 bits wide in C. So a 1-bit byte *in C* is not
> possible. On the other hand, I've mucked about with a 1-bit (virtual)
> processor which designated "byte" as "group of 1 contiguous bit". It had
> two one-bit bytes of addressable storage, and two one-bit op-codes.
> (Obviously it didn't do a lot.)
> 

So what about devices that can address bits directly?  8051 cpus manage
that, and compilers for such cpus often have extensions such as a "bit"
type.

(The answer, of course, is that they have 8-bit bytes and 8-bit chars,
with the "bit" types being somewhat special and not quite fitting in as
a normal C type.  Such compilers don't tend to be particularly close to
standard C, even for freestanding systems.)

And what about 4-bit processors?  (The answer here is that they usually
don't have C compilers - it is more common to program them in a sort of
Forth dialect.)

>> (The data sheet for that device mostly uses 'bits' or 'words'. Where it
>> uses 'bytes', then AFAICS it's to do with external memory or
>> interfacing, and refers to 8-bit bytes. Possibly helped by 800M
>> bytes/second sounding better than 200M words/second.)
> 
> The C Standard doesn't know about data sheets. It only knows that a byte
> is addressable. If the smallest addressable unit is 32 bits wide, then a
> byte is (at least) 32 bits wide, and to avoid that would require the
> compiler implementor to emulate an 8-bit-byte machine.
> 

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

#72274

David Brown <david.brown@hesbynett.no> writes:
> On 09/10/15 09:28, Richard Heathfield wrote:
[...]
>> On that platform, no unit smaller than 32 bits is addressable.
>> 
>> It would be possible for a C implementation to set CHAR_BIT at 8 only if
>> they jump through all the necessary hoops to ensure that the
>> implementation behaves "as if" 8-bit units were addressable. I don't
>> think the Analog Devices people went to that trouble.
>
> The devices would be far more useful if they /did/ go to that trouble.
> But you wouldn't expect that from a compiler toolchain that costs a mere
> $20K (last I looked, the price was in that range), and a couple of years
> ago brought out a new version with partial support for some C99 features.

How would they be "far more useful"?  As I understand it, these
devices aren't used to process octet-oriented data.  If you wanted
to do a bunch of ASCII string processing, for example, you'd do it
on the computer that the DSP is connected to, not on the DSP itself.

[...]

-- 
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]

#72498

On 09/10/15 18:26, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/10/15 09:28, Richard Heathfield wrote:
> [...]
>>> On that platform, no unit smaller than 32 bits is addressable.
>>>
>>> It would be possible for a C implementation to set CHAR_BIT at 8 only if
>>> they jump through all the necessary hoops to ensure that the
>>> implementation behaves "as if" 8-bit units were addressable. I don't
>>> think the Analog Devices people went to that trouble.
>>
>> The devices would be far more useful if they /did/ go to that trouble.
>> But you wouldn't expect that from a compiler toolchain that costs a mere
>> $20K (last I looked, the price was in that range), and a couple of years
>> ago brought out a new version with partial support for some C99 features.
>
> How would they be "far more useful"?  As I understand it, these
> devices aren't used to process octet-oriented data.  If you wanted
> to do a bunch of ASCII string processing, for example, you'd do it
> on the computer that the DSP is connected to, not on the DSP itself.
>

In a great many embedded tasks, you need a mixture of code.  You might 
want DSP-style code for filtering or complex numerical algorithms for 
handling signals or analysis, but you also normally want general purpose 
control code, communication code, and other sorts of code.  A DSP that 
is highly optimised for DSP operations can be wonderful at them - 
perhaps handling two separate multiply-add operations (with saturation) 
per clock cycle, while working through circular buffers with automatic 
wrap-around.  But they are usually a real pain for everything else - and 
you /always/ need other things.  Traditionally, there have been three 
ways to handle this.  One is to do everything on the DSP - that means a 
great deal more development work with distinctly sub-par tools at 
over-par price.  Or you can use a second microcontroller to handle the 
"normal" stuff and leave the DSP to the DSP code.  Or you can use one of 
the few so-called "hybrid" DSP devices (like the Analog Devices 
Blackfin, or Freescale 56F family) that are not /too/ bad at ordinary stuff.

If the toolchains for devices like the SHARC had had better support for 
non-DSP code, such as supporting 8-bit operations and modern C dialects 
(the DSP code is usually written in assembly code, or with C code so 
full of specialised intrinsic functions that it is practically assembly 
code - that's how you get maximal speed out the devices), then it would 
be a great deal easier to do everything in the DSP.  But DSP suppliers 
have shown little or no interest in such things.

The result is that it is usually much cheaper and easier to use a decent 
"ordinary" cpu with reasonable DSP instructions (such as fast 
multiply-accumulate instructions) and accept that your clock needs to 
run a little faster to get the same DSP operation speed.  Development on 
SHARC and its ilk is mostly relegated to niche programmers whose 
customers buy complete packages of DSP, code, and licenses (to handle 
audio/video codecs), or to companies who have always done everything 
with DSPs and have not moved with the times.  The rest of us use 
Cortex-M4 (small ARM microcontrollers, with some DSP instructions), 
bigger cpus with SIMD hardware, or FPGAs when serious speed is needed.

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

#72502

On Sunday, October 11, 2015 at 7:31:08 PM UTC+1, David Brown wrote:
> 
> If the toolchains for devices like the SHARC had had better support for 
> non-DSP code, such as supporting 8-bit operations and modern C dialects 
> (the DSP code is usually written in assembly code, or with C code so 
> full of specialised intrinsic functions that it is practically assembly 
> code - that's how you get maximal speed out the devices), then it would 
> be a great deal easier to do everything in the DSP.  But DSP suppliers 
> have shown little or no interest in such things.
> 
> The result is that it is usually much cheaper and easier to use a decent 
> "ordinary" cpu with reasonable DSP instructions (such as fast 
> multiply-accumulate instructions) and accept that your clock needs to 
> run a little faster to get the same DSP operation speed. 
>
You mean an inefficient but easy to use string library, stdout, qsort()
and so on for a DSP would make the difference for you between using the
DSP and going for another processor?
You seem to have identified an important gap in the market, and one
that doesn't seem too hard to fill.

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

#72252

On 09/10/2015 08:28, Richard Heathfield wrote:
> On 09/10/15 00:48, Bartc wrote:
>> On 09/10/2015 00:20, Richard Heathfield wrote:

>>> Analog Devices introduced the SHARC digital signal processor some time
>>> in the mid-1990s (IIRC). It has a 32-bit byte. That is, the smallest
>>> addressable unit is 32 bits wide.
>>
>> That doesn't make a byte 32 bits.
>
> 3.6 gives the definition of 'byte': "addressable unit of data storage
> large enough to hold any member of the basic character set of the
> execution environment".
>
> On that platform, no unit smaller than 32 bits is addressable.

Not directly. But that was common on older hardware (the first machine I 
used was only 36-bit addressable; the second 16-bit). But even then a 
'byte' was usually considered to be 8 bits.

And now, if you buy RAM modules, memory sticks or disk drives, the 
capacity is going to be expressed in bytes. How many bits are those byte 
going to be, since there is no discrete processor involved? Obviously eight.

> It would be possible for a C implementation to set CHAR_BIT at 8 only if
> they jump through all the necessary hoops to ensure that the
> implementation behaves "as if" 8-bit units were addressable. I don't
> think the Analog Devices people went to that trouble.

> On the other hand, somebody /did/ go to that trouble for... was it a
> Cray, or a Honeywell? I forget. Anyway, they had 64-bit bytes, but they
> decided, presumably for the sake of not getting shouted out by a lot of
> hairy C programmers, that they would emulate 8-bit bytes.

I think David Brown explained why that was the case. The Analog Devices 
chip has specialised uses. The other machines were general purpose and 
needed to deal efficiently with text.

-- 
Bartc

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

#72273

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> 3.6 gives the definition of 'byte': "addressable unit of data storage 
> large enough to hold any member of the basic character set of the 
> execution environment".
>
> On that platform, no unit smaller than 32 bits is addressable.
>
> It would be possible for a C implementation to set CHAR_BIT at 8 only if 
> they jump through all the necessary hoops to ensure that the 
> implementation behaves "as if" 8-bit units were addressable. I don't 
> think the Analog Devices people went to that trouble.
>
> On the other hand, somebody /did/ go to that trouble for... was it a 
> Cray, or a Honeywell? I forget. Anyway, they had 64-bit bytes, but they 
> decided, presumably for the sake of not getting shouted out by a lot of 
> hairy C programmers, that they would emulate 8-bit bytes.

Cray vector systems, such as the T90.

The smallest hardware-addressible unit is 64 bits.  A 64-bit unit is
called a "word"; I don't think it was ever referred to as a "byte".

Because Cray wanted to run a POSIX-compliant system (which requires
CHAR_BIT==8), they implemented 8-bit byte addressing in software, by
storing a 3-bit offset in the otherwise unused high-order 3 bits of a
64-bit pointer.  (Which made string processing really slow -- but that's
not what those systems were designed for).

[...]

-- 
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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web