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

Groups > comp.arch > #35741 > unrolled thread

Re: Setting architectural features in stone

Back to article view | Back to comp.arch

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: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-01 11:18 +0200
    Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-01 09:26 -0700
    Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-01 15:48 +0000
    Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-01 10:13 -0700
    Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-02 20:09 -0400
      Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-02 18:39 -0700
        Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 00:52 -0700
          Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-03 06:45 -0400
        Re: Setting architectural features in stone David Brown <david.brown@hesbynett.no> - 2016-08-03 15:02 +0200
      Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-02 19:37 -0700
        Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-03 10:52 +0200
          Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:09 +0100
          Re: Setting architectural features in stone Keith Thompson <kst-u@mib.org> - 2016-08-03 08:51 -0700
          Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 09:36 -0700
            Re: Setting architectural features in stone George Neuner <gneuner2@comcast.net> - 2016-08-03 20:30 -0400
            Re: Setting architectural features in stone Noob <root@127.0.0.1> - 2016-08-04 13:06 +0200
              Re: Setting architectural features in stone Bruce Hoult <bruce.hoult@gmail.com> - 2016-08-04 06:39 -0700
                Re: Setting architectural features in stone nmm@wheeler.UUCP (Nick Maclaren) - 2016-08-04 17:40 +0000
        Re: Setting architectural features in stone nmm@wheeler.UUCP (Nick Maclaren) - 2016-08-03 09:40 +0000
          Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 09:50 -0700
            Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 10:14 -0700
              Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-04 06:11 -0700
                Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-04 06:14 -0700
        Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-03 07:03 -0400
          Re: Setting architectural features in stone already5chosen@yahoo.com - 2016-08-03 04:12 -0700
            Re: Setting architectural features in stone already5chosen@yahoo.com - 2016-08-03 04:26 -0700
              Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-03 07:50 -0400
            Re: Setting architectural features in stone Walter Banks <walter@bytecraft.com> - 2016-08-03 07:35 -0400
      Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 06:42 +0000
        Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 00:03 -0700
          Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 08:30 +0000
        Re: Setting architectural features in stone Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-03 11:02 +0100
          Re: Setting architectural features in stone Ivan Godard <ivan@millcomputing.com> - 2016-08-03 03:15 -0700
          Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-03 11:53 +0000
            Re: Setting architectural features in stone Quadibloc <jsavard@ecn.ab.ca> - 2016-08-03 18:03 -0700
              Re: Setting architectural features in stone Bruce Hoult <bruce.hoult@gmail.com> - 2016-08-04 01:54 -0700
              Re: Setting architectural features in stone anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-04 09:28 +0000
        Re: Setting architectural features in stone timcaffrey@aol.com - 2016-08-04 09:48 -0700
          Re: Setting architectural features in stone Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2016-08-04 10:04 -0700

Page 1 of 2  [1] 2  Next page →

#35741 — Re: Setting architectural features in stone

[ Cross-posting to comp.arch where the Mill guru lives ]

On 28/07/2016 16:50, Melzzzzz wrote:

> supercat at casperkitty.com wrote:
> 
>> The majority of C code written will never need to be targeted for
>> anything other than a general-purpose reprogrammable microcomputer,
>> and the overwhelming majority of such devices share a number of
>> architectural features with the PDP-11:
>>
>>   1. Integer sizes are power-of-two multiples of an 8-bit character
>> type.
>>
>>   2. Each size of integer larger than the character type is stored as
>> two halves in either big-endian or little-endian order.
>>
>>   3. A relational comparison between pointers will never have any
>> effect other than to either indicate that the a particular pointer is
>> higher or that it isn't, in a fashion that forms a ranking (on some
>> older computers, the relation tested by equality operators might not
>> be consistent with that tested by relational operators, but the
>> relational operators would be consistent among themselves).
>>
>>   4. Integer arithmetic operations are performed in sign-agnostic
>> fashion except for promotion, division, right-shift, and relational
>> operators; thus the default hardware behavior is two's-complement
>> silent wraparound.
>>
>> Can you suggest any remotely-common general-purpose reprogrammable
>> microcomputers where any of the above do not apply?

Note: Setting architectural features in stone might very well constrain
the potential performance of future architectures.

> Mill, upcoming architecture...

IMHO, Mill looks very interesting. As in "one in a decade".
(The previous two were Itanium and Transmeta, from my PoV.)

https://en.wikipedia.org/wiki/Mill_architecture
https://en.wikipedia.org/wiki/TriMedia_%28mediaprocessor%29
https://millcomputing.com/docs/
http://millcomputing.com/wiki/Main_Page

Regards.

[toc] | [next] | [standalone]

#35751

On 8/1/2016 2:18 AM, Noob wrote:
> [ Cross-posting to comp.arch where the Mill guru lives ]

Thank you. It is impossible to folly all the possibly-relevant lists :-(

Mill per this list:

> On 28/07/2016 16:50, Melzzzzz wrote:
>
>> supercat at casperkitty.com wrote:
>>
>>> The majority of C code written will never need to be targeted for
>>> anything other than a general-purpose reprogrammable microcomputer,
>>> and the overwhelming majority of such devices share a number of
>>> architectural features with the PDP-11:
>>>
>>>   1. Integer sizes are power-of-two multiples of an 8-bit character
>>> type.

Yes.

>>>   2. Each size of integer larger than the character type is stored as
>>> two halves in either big-endian or little-endian order.

Yes

>>>   3. A relational comparison between pointers will never have any
>>> effect other than to either indicate that the a particular pointer is
>>> higher or that it isn't, in a fashion that forms a ranking (on some
>>> older computers, the relation tested by equality operators might not
>>> be consistent with that tested by relational operators, but the
>>> relational operators would be consistent among themselves).

Unclear what this bullet means for any machine. Mill pointer relationals 
have no side effects if the addresses are within bounds; a 
total-ordering idiom that ignores bounds is also available. Languages 
use whichever semantics fits their definition. Equality is consistent 
with relationals.

>>>   4. Integer arithmetic operations are performed in sign-agnostic
>>> fashion except for promotion, division, right-shift, and relational
>>> operators; thus the default hardware behavior is two's-complement
>>> silent wraparound.

Silent two's-complement is available. Also available are corresponding 
forms that saturate the result; fault on numeric overflow; and produce a 
double-width result.

>>> Can you suggest any remotely-common general-purpose reprogrammable
>>> microcomputers where any of the above do not apply?

The Mill is certainly not common :-)  Yet.

> Note: Setting architectural features in stone might very well constrain
> the potential performance of future architectures.
>
>> Mill, upcoming architecture...
>
> IMHO, Mill looks very interesting. As in "one in a decade".
> (The previous two were Itanium and Transmeta, from my PoV.)
>
> https://en.wikipedia.org/wiki/Mill_architecture
> https://en.wikipedia.org/wiki/TriMedia_%28mediaprocessor%29
> https://millcomputing.com/docs/
> http://millcomputing.com/wiki/Main_Page
>
> Regards.
>

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

#35752

Noob <root@127.0.0.1> writes:
>[ Cross-posting to comp.arch where the Mill guru lives ]
>
>On 28/07/2016 16:50, Melzzzzz wrote:
>
>> supercat at casperkitty.com wrote:
>> 
>>> The majority of C code written will never need to be targeted for
>>> anything other than a general-purpose reprogrammable microcomputer,
>>> and the overwhelming majority of such devices share a number of
>>> architectural features with the PDP-11:
>>>
>>>   1. Integer sizes are power-of-two multiples of an 8-bit character
>>> type.
>>>
>>>   2. Each size of integer larger than the character type is stored as
>>> two halves in either big-endian or little-endian order.
>>>
>>>   3. A relational comparison between pointers will never have any
>>> effect other than to either indicate that the a particular pointer is
>>> higher or that it isn't, in a fashion that forms a ranking (on some
>>> older computers, the relation tested by equality operators might not
>>> be consistent with that tested by relational operators, but the
>>> relational operators would be consistent among themselves).
>>>
>>>   4. Integer arithmetic operations are performed in sign-agnostic
>>> fashion except for promotion, division, right-shift, and relational
>>> operators; thus the default hardware behavior is two's-complement
>>> silent wraparound.
>>>
>>> Can you suggest any remotely-common general-purpose reprogrammable
>>> microcomputers where any of the above do not apply?
>
>Note: Setting architectural features in stone might very well constrain
>the potential performance of future architectures.

Sure, when quantum computers become mainstream (i.e., probably never),
the assumptions most current software makes will probably not be
satisfied (except maybe in a compatibility layer), but despite not
wanting to settle on the architectural features mentioned above, C
will probably be inappropriate for such revolutionary architectures.

In the meantime, writing software to avoid making use of these
properties costs performance.

>IMHO, Mill looks very interesting. As in "one in a decade".
>(The previous two were Itanium and Transmeta, from my PoV.)

Both not very successful, and I expect a similar fate for the Mill,
although it would be nice to see success for an unconventional
architecture for a change.  Anyway, from what I know about the Mill,
it can be used efficiently in a way that satisfies all the properties
mentioned above (although people who like to miscompile code will be
happy to learn that the Mill can have unconventional handling of
integer overflows; but we also have that on MIPS and Alpha, but even
undefined-behaviour-fanatics don't compile signed-integer + to
(trapping) add on MIPS by default).

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

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

#35754

On Monday, August 1, 2016 at 3:18:29 AM UTC-6, Noob wrote:
> [ Cross-posting to comp.arch where the Mill guru lives ]

I went back to the original newsgroup, comp.lang.c, to reply to the post you 
quoted, as follows:


I think that the bigger question here would be: is there any good reason for 
any of those features not to apply to any architecture?

(3) does not apply to some architectures because they provide a high level of 
isolation between data belonging to different processes, and that is a good and 
useful thing.

Some historical systems used integer formats other than two's complement, thus 
missing (4), but that is pretty much dead today. It is true, though, that 
"wraparound" arithmetic is only useful for stuff like pseudorandom number 
generation, and usually catching overflow as an error for integers as is done 
for floats would make more sense.

I can think of good reasons for breaking (1) and hence (2). When the IBM 360
came along to replace the IBM 7090, a lot of people complained that they had to
switch their scientific programs to use double precision, where before they
produced useful results with only single precision.

So a computer that, say, had 36-bit single precision floats, 48-bit
intermediate precision floats, and 60-bit double precision floats (since 64
bits is already overly long, and the Control Data 6600, with a 60 bit word,
seemed to make everyone happy) - as multiples of a 12-bit unit, and, hence,
presumably a 48-bit word length with fancy features to make accessing of
unaligned operands efficient - would offer the highest possible floating-point
performance by not using any more precision than is actually needed to get the
job done!

As for (2) by itself, though, why wouldn't a computer be either consistently
big-endian (my preference, as that's then consistent with packed and unpacked
decimal too) or consistently little-endian? What useful purpose would something
like the original PDP-11's floating-point format serve? 

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

#35767

On 2016-08-01 5:18 AM, Noob wrote:
> [ Cross-posting to comp.arch where the Mill guru lives ]
>
> On 28/07/2016 16:50, Melzzzzz wrote:
>
>> supercat at casperkitty.com wrote:
>>
>>> The majority of C code written will never need to be targeted for
>>> anything other than a general-purpose reprogrammable microcomputer,
>>> and the overwhelming majority of such devices share a number of
>>> architectural features with the PDP-11:
>>>
>>>   1. Integer sizes are power-of-two multiples of an 8-bit character
>>> type.
>>>
>>>   2. Each size of integer larger than the character type is stored as
>>> two halves in either big-endian or little-endian order.
>>>
>>>   3. A relational comparison between pointers will never have any
>>> effect other than to either indicate that the a particular pointer is
>>> higher or that it isn't, in a fashion that forms a ranking (on some
>>> older computers, the relation tested by equality operators might not
>>> be consistent with that tested by relational operators, but the
>>> relational operators would be consistent among themselves).
>>>
>>>   4. Integer arithmetic operations are performed in sign-agnostic
>>> fashion except for promotion, division, right-shift, and relational
>>> operators; thus the default hardware behavior is two's-complement
>>> silent wraparound.
>>>
>>> Can you suggest any remotely-common general-purpose reprogrammable
>>> microcomputers where any of the above do not apply?

Perhaps not generally available. The eTPU used in engine controllers is 
24 bit data word and sells in the general area of 20M copies a year. (It 
is BTW supported with a C compiler)

I have worked on processors that had 9 bit, 12 bit, 13 bit, 18 bit and 
and several 36 bit words.

I have never worked with a procwessor that did not use 2's compliment
arithmetic.

The 12bit and 13bit processpors had no general provision for byte sized 
character data. The multiple of 9 bit processors all had the ability to 
support 9 bit data.

For what it is worth I am currently working on a project with a non 
power of two multiple of 8 bits that also does not support character 
data in any familliar size.

C often is used as a reason to support charters and power of two data 
sizes but there is no language limit that restricts its use for other 
data formats.

w..

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

#35768

On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks wrote:

> Perhaps not generally available. The eTPU used in engine controllers is 
> 24 bit data word and sells in the general area of 20M copies a year. (It 
> is BTW supported with a C compiler)

Google tells me that it's a processor usually found as part of an SoC including a 
more conventional processor. Of course, code still needs to be written for it.

John Savard

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

#35772

On Tuesday, August 2, 2016 at 7:39:54 PM UTC-6, Quadibloc wrote:
> On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks wrote:
> 
> > Perhaps not generally available. The eTPU used in engine controllers is 
> > 24 bit data word and sells in the general area of 20M copies a year. (It 
> > is BTW supported with a C compiler)
> 
> Google tells me that it's a processor usually found as part of an SoC including a 
> more conventional processor. Of course, code still needs to be written for it.

If I'm looking at the right machine - the eTPU being Freescale's Enhanced Time 
Processing Unit, an auxilliary processor included with their signal processor 
chips so as to handle interrupts and generate output analog signals without 
burdening the main CPU - while its data memory is 24 bits wide, it gets its 
instructions from memory that is 32 bits wide.

John Savard

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

#35779

On 2016-08-03 3:52 AM, Quadibloc wrote:
> On Tuesday, August 2, 2016 at 7:39:54 PM UTC-6, Quadibloc wrote:
>> On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks
>> wrote:
>>
>>> Perhaps not generally available. The eTPU used in engine
>>> controllers is 24 bit data word and sells in the general area of
>>> 20M copies a year. (It is BTW supported with a C compiler)
>>
>> Google tells me that it's a processor usually found as part of an
>> SoC including a more conventional processor. Of course, code still
>> needs to be written for it.
>
> If I'm looking at the right machine - the eTPU being Freescale's
> Enhanced Time Processing Unit, an auxilliary processor included with
> their signal processor chips so as to handle interrupts and generate
> output analog signals without burdening the main CPU - while its
> data memory is 24 bits wide, it gets its instructions from memory
> that is 32 bits wide.
>
> John Savard
>
It is a dual processor that does the detail controlling of the I/O pins.
That control the engine. It is paired with a powerPC derivative (super
set) that is the host processor. The host establishes set points and
the eTPU does the actual control at a reasonably high level managing
timing doing pid loops and data gathering.

Other eTPU uses that I have been involved in are small scale process
control and instrumentation.

The eTPU as you correctly stated is 24 bit data paths and 32 bit
instruction paths. I worked on the eTPU ISA and wrote the code generator
for the C compiler that is used in most applications.

w..

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

#35790

On 03/08/16 03:39, Quadibloc wrote:
> On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks wrote:
> 
>> Perhaps not generally available. The eTPU used in engine controllers is 
>> 24 bit data word and sells in the general area of 20M copies a year. (It 
>> is BTW supported with a C compiler)
> 
> Google tells me that it's a processor usually found as part of an SoC including a 
> more conventional processor. Of course, code still needs to be written for it.
> 

Yes, the eTPU (and other TPU versions before it) are co-processors in a
sophisticated and programmable timer unit, found in a variety of
Motorola/Freescale/NXP microcontrollers.  They are especially popular
for car engine control or sophisticated motor control.

Usually, the code is written by the manufacturer - customers use
pre-written functions.  With later versions (the eTPU) having a C
compiler, it became more practical for people to write their own
functions - but still, most users select from pre-written functions.

I have always thought that they would be fun to program, but the
compiler cost is well outside my fun budget.

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

#35769

On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks wrote:

> C often is used as a reason to support charters and power of two data 
> sizes but there is no language limit that restricts its use for other 
> data formats.

I'm not aware of a language limit myself.

However, C does specify that string constants may include things like \n and 
this means that char values must be able to represent lower-case letters. 
Therefore, a system where characters are six bits long would conflict with the 
C standard,

In the FORTRAN standard, it is specified that DOUBLE PRECISION values are to 
occupy two "storage cells" while REAL ones occupy one.

This would not make sense on many computers with a 24-bit word length. On such 
a computer, one possibility is that single precision will be 48 bits long, and 
double precision will be 72 bits, or three words, long.

However, plenty of computers which broke that particular rule had FORTRAN 
compilers, so it was not a real obstacle.

John Savard

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

#35773

[ Adding comp.lang.c back since we're discussing C ]

On 03/08/2016 04:37, Quadibloc wrote:

> However, C does specify that string constants may include things like \n and
> this means that char values must be able to represent lower-case letters.

I don't follow your logic. What does '\n' have to do with lower-case?
On DOS systems, '\n' is encoded as CR-LF.

> Therefore, a system where characters are six bits long would conflict with
> the C standard [...]

Right, there is a lower limit; a C char must be *at least* 8 bits wide.

(Because CHAR_BIT >= 8 and UCHAR_MAX >= 255)

Regards.

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

#35777

Noob <root@127.0.0.1> writes:

> [ Adding comp.lang.c back since we're discussing C ]
>
> On 03/08/2016 04:37, Quadibloc wrote:
>
>> However, C does specify that string constants may include things like \n and
>> this means that char values must be able to represent lower-case letters.
>
> I don't follow your logic. What does '\n' have to do with lower-case?

Maybe all that's being said is that C source code needs lower case?  I
would not have picked on \n for that since the language is simple full
of the need for lower case so I may be misunderstand what Quadibloc
means here.

> On DOS systems, '\n' is encoded as CR-LF.

Just to clarify... A C implementation by translate '\n' into a sequence
like CR-LF on output to a text stream, but '\n' must be an integer value
in the range of char, and "\n" must be a string of length one.

<snip>
-- 
Ben.

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

#35796

Noob <root@127.0.0.1> writes:
> [ Adding comp.lang.c back since we're discussing C ]
>
> On 03/08/2016 04:37, Quadibloc wrote:
>
>> However, C does specify that string constants may include things like \n and
>> this means that char values must be able to represent lower-case letters.
>
> I don't follow your logic. What does '\n' have to do with lower-case?
> On DOS systems, '\n' is encoded as CR-LF.
>
>> Therefore, a system where characters are six bits long would conflict with
>> the C standard [...]
>
> Right, there is a lower limit; a C char must be *at least* 8 bits wide.
>
> (Because CHAR_BIT >= 8 and UCHAR_MAX >= 255)

And the basic character set includes both uppercase and lowecase
letters, and an implementation must distinguish between them both at
compile time and at run time.

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

#35797

On Wednesday, August 3, 2016 at 2:52:59 AM UTC-6, Noob wrote:
> [ Adding comp.lang.c back since we're discussing C ]
> On 03/08/2016 04:37, Quadibloc wrote:

> > However, C does specify that string constants may include things like \n and
> > this means that char values must be able to represent lower-case letters.

> I don't follow your logic. What does '\n' have to do with lower-case?
> On DOS systems, '\n' is encoded as CR-LF.

But the "n" is lower-case. Presumably, if you can put \n in a string, you're 
also allowed to put n in the string by itself.

John Savard

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

#35800

On Wed, 3 Aug 2016 09:36:47 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Wednesday, August 3, 2016 at 2:52:59 AM UTC-6, Noob wrote:
>> [ Adding comp.lang.c back since we're discussing C ]
>> On 03/08/2016 04:37, Quadibloc wrote:
>
>> > However, C does specify that string constants may include things like \n and
>> > this means that char values must be able to represent lower-case letters.
>
>> I don't follow your logic. What does '\n' have to do with lower-case?
>> On DOS systems, '\n' is encoded as CR-LF.
>
>But the "n" is lower-case. Presumably, if you can put \n in a string, you're 
>also allowed to put n in the string by itself.

Not necessarily.  If you are doing this, the presumably you are using
a cross compiler to begin with.  It might be reasonable for use of the
hardware unsupported case in source to be restricted to strings and
further restricted to designating control character escape sequences.

>John Savard
George

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

#35807

On 03/08/2016 18:36, Quadibloc wrote:
> On Wednesday, August 3, 2016 at 2:52:59 AM UTC-6, Noob wrote:
>> [ Adding comp.lang.c back since we're discussing C ]
>> On 03/08/2016 04:37, Quadibloc wrote:
> 
>>> However, C does specify that string constants may include things like \n and
>>> this means that char values must be able to represent lower-case letters.
> 
>> I don't follow your logic. What does '\n' have to do with lower-case?
>> On DOS systems, '\n' is encoded as CR-LF.
> 
> But the "n" is lower-case. Presumably, if you can put \n in a string, you're 
> also allowed to put n in the string by itself.

Are you trolling?

The letter "n" in the character '\n' stands for "newline".
It has no relationship to the actual character 'n'.

And why did you drop comp.lang.c if you want to discuss C?

You and supercat are getting on my nerve, dropping cross-posts
willy-nilly.

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

#35811

On Thursday, August 4, 2016 at 2:06:20 PM UTC+3, Noob wrote:
> On 03/08/2016 18:36, Quadibloc wrote:
> > On Wednesday, August 3, 2016 at 2:52:59 AM UTC-6, Noob wrote:
> >> [ Adding comp.lang.c back since we're discussing C ]
> >> On 03/08/2016 04:37, Quadibloc wrote:
> > 
> >>> However, C does specify that string constants may include things like \n and
> >>> this means that char values must be able to represent lower-case letters.
> > 
> >> I don't follow your logic. What does '\n' have to do with lower-case?
> >> On DOS systems, '\n' is encoded as CR-LF.
> > 
> > But the "n" is lower-case. Presumably, if you can put \n in a string, you're 
> > also allowed to put n in the string by itself.
> 
> Are you trolling?
> 
> The letter "n" in the character '\n' stands for "newline".
> It has no relationship to the actual character 'n'.
> 
> And why did you drop comp.lang.c if you want to discuss C?
> 
> You and supercat are getting on my nerve, dropping cross-posts
> willy-nilly.

In your C source code file, "\n" contains four characters: '"', '\', 'n', '"' with ASCII/8859-1/utf-8 codes 34, 92, 110, 34 (0x22, 0x5C, 0x6E, 0x22).

All of these must be representable in the character set of the computer on which you run your text editor and compiler. This might or might not be the same computer on which the compiled program runs.

When you compile the program, "\n" becomes an array of two characters: LF = 10 (0x0A), and NULL = 0 (0x00) if the target uses ASCII/8859-1/utf-8. Or, this could also fit in a 6-bit character set such as ECMA-1, where the encodings are LF = 2 (0x02), and NULL = 32 (0x20)

ECMA-1 has encodings for '\' but not for '"' or 'n', so you can run this program on such a machine, but you can't write the C source code on it using the native character set.

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

#35814

In article <d6b93b11-6d6f-4874-8349-1cf769b6678b@googlegroups.com>,
Bruce Hoult  <bruce.hoult@gmail.com> wrote:
>
>In your C source code file, "\n" contains four characters: '"', '\',
>'n', '"' with ASCII/8859-1/utf-8 codes 34, 92, 110, 34 (0x22, 0x5C,
>0x6E, 0x22).
>
>All of these must be representable in the character set of the computer
>on which you run your text editor and compiler. This might or might not
>be the same computer on which the compiled program runs.

They must be in both the source and execution character sets
of the compiler, but '\' need not be in the character set of the
computer.  I have used such a compiler.  Look up trigraphs.


Regards,
Nick Maclaren.

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

#35775

In article <66682c36-81e9-481a-a4d2-1f61e9754ada@googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>On Tuesday, August 2, 2016 at 6:09:36 PM UTC-6, Walter Banks wrote:
>
>> C often is used as a reason to support charters and power of two data 
>> sizes but there is no language limit that restricts its use for other 
>> data formats.
>
>I'm not aware of a language limit myself.

The restriction was introduced in C99, against opposition.  6.2.6
in C99.

>In the FORTRAN standard, it is specified that DOUBLE PRECISION values are to 
>occupy two "storage cells" while REAL ones occupy one.
>
>This would not make sense on many computers with a 24-bit word length. On such 
>a computer, one possibility is that single precision will be 48 bits long, and 
>double precision will be 72 bits, or three words, long.

Nuts.  Sorry, but ....  Such machines were common, and they almost
all had 48 bit floats and 96 bit double precision.  The latter was
implemented in various ways, not all with 96-bit accuracy.


Regards,
Nick Maclaren.

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

#35798

On Wednesday, August 3, 2016 at 3:40:06 AM UTC-6, Nick Maclaren wrote:

> Nuts.  Sorry, but ....  Such machines were common, and they almost
> all had 48 bit floats and 96 bit double precision.  The latter was
> implemented in various ways, not all with 96-bit accuracy.

It's true that the ICL 1900 had 48-bit floats and 96-bit double precision, and 
likely the Control Data 1604A and its successors did too.

The Foxboro FOX-1 is another compliant example; its double precision was 48 
bits long, but its single precision was only 24 bits long.

I don't call that "almost all", though. Actually, machines with 24-bit words were rather rare. But several did not follow this FORTRAN rule.

Datacraft DC6024, Harris Series 500
48-bit single precision (16 bits unused), 48-bit double precision

3C DDP-24, DDP-124, DDP-224
48-bit single precision (15 bits unused), 48-bit double precision

SEL 840
48-bit single precision, 72-bit double precision

Four-Phase Systems IV/70
48-bit single precision, 72-bit double precision

Other examples of machines that broke the FORTRAN standard:

18-bit word
Univac 418 - 36 bit single precision, 54 bit double precision (3 bits unused).

PDP-4/7/9/15 - 36 bit single precision, 54 bit double precision

16-bit word
IBM 1130 - 32 bit single precision, 48 bit double precision (8 bits unused).

Hewlett-Packard 211x - 32 bit single precision, 48 bit double precision

MIL-STD-1750 - 32 bit single precision, 48 bit double precision.

John Savard

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web