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

Groups > comp.lang.misc > #2067 > unrolled thread

C: 100 Things

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

Contents

  C: 100 Things "BartC" <bc@freeuk.com> - 2014-04-29 17:57 +0100
    Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 07:40 +0100
      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 12:16 +0100
        Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 13:54 +0100
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 14:39 +0100
            Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-04-30 20:18 +0100
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 22:40 +0100
                Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-04-30 22:09 +0000
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-04-30 23:36 +0100
                    Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:03 +1200
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:47 +0100
                Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-01 00:35 +0100
                  Re: 100 Things Andy Walker <news@cuboid.co.uk> - 2014-05-01 11:03 +0100
                    Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 20:16 +0100
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 12:44 +0100
                    Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 11:11 +0100
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 13:32 +0100
                        Re: 100 Things "James Harris" <james.harris.1@gmail.com> - 2014-05-02 16:42 +0100
                          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 17:54 +0100
            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 11:01 +1200
        Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 21:13 -0400
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:26 +0100
            Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
        Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 13:42 +1200
          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 09:35 +0100
            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 21:02 +1200
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 10:40 +0100
                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-01 22:06 +1200
            Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 11:08 +0200
              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 11:02 +0100
                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 13:57 +0200
                  Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 15:12 +0100
                    Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 17:18 +0200
                      Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 17:04 +0100
                        Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:30 +0000
                          Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                            Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-02 08:30 +1200
                              Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 01:29 -0400
                                Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 02:37 -0400
                                  Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-03 15:39 -0400
                                    Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 17:30 -0400
                                Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-04 20:05 +1200
                                  Re: 100 Things George Neuner <gneuner2@comcast.net> - 2014-05-04 13:28 -0400
                                    Re: 100 Things Ian Collins <ian-news@hotmail.com> - 2014-05-05 07:40 +1200
                        Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-01 22:00 +0200
                          Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-01 23:24 +0100
                            Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 08:59 +0200
                              Re: 100 Things "BartC" <bc@freeuk.com> - 2014-05-02 09:53 +0100
                                Re: 100 Things "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-02 11:22 +0200
                      Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-01 18:26 +0000
                        Re: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 16:08 -0400
                          Re: 100 Things Kaz Kylheku <kaz@kylheku.com> - 2014-05-02 02:49 +0000
    Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-30 22:08 -0400
    Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-25 23:53 +0100
      Re: C: 100 Things "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-26 05:38 -0400
        Re: C: 100 Things "BartC" <bc@freeuk.com> - 2014-07-26 13:51 +0100
          Re: C: 100 Things rick.c.hodgin@gmail.com - 2014-10-25 04:48 -0700
    Re: C: 100 Things "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2014-10-25 04:50 -0700

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

#2088 — Re: 100 Things

On Wed, 30 Apr 2014 07:16:19 -0400, BartC <bc@freeuk.com> wrote:

> As for C being minimalist, I don't know if a language needing these types
> and macros (remembering to substitute all the combinations of 8 16, 32
> and 64 every time you see N): [list]
>
> and maybe this lot too, as some of these seem to be different from those
> above: [list]
>
> and much more, could actually be called minimalist. (More like  
> maximalist,
> as this lot could easily be condensed into a handful of language  
> features.)
>

How often do you use those?

> It's a joke really, but not particularly funny as this language and its
> ideas seem to have permeated everywhere. You take the crude C for-loop,
> which is 'for (expr; expr; expr)', and you see it practically unchanged
> in C++, C#, Java, Javascript, PHP, Perl, even newer ones such as Go and
> Dart (although Go has at least dropped the parentheses!).
>

C's for() was a huge improvement over other languages of the time.
It put all the loop conditions in the same place.  This was very nice
when both programming and reading.  I used to love this.  However,
after over two decades of C, I don't like it anymore.  The problem isn't
the either of those two issues.  Those are still great.  The problem is
many C compilers optimize a "while(1)" loop with an "if() break;" better.
So, now, I'm unrolling for() loops in some instances ...

If C was truly minimalist, it'd just have a "loop" keyword for all loops,
no conditions, no termination, infinite.  "break" and "continue" would
still work.


Rod Pemberton

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

#2094 — Re: 100 Things

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xe5porqb6zenlw@localhost...
> On Wed, 30 Apr 2014 07:16:19 -0400, BartC <bc@freeuk.com> wrote:
>
>> As for C being minimalist, I don't know if a language needing these types
>> and macros (remembering to substitute all the combinations of 8 16, 32
>> and 64 every time you see N): [list]

[intN_t etc]

> How often do you use those?

It's common to use some of those at some time or other, if not all at the 
same time. You've never used CHARBIT or needed an exact 32-bit signed int?

>You take the crude C for-loop,
>> which is 'for (expr; expr; expr)', and you see it practically unchanged
>> in C++, C#, Java, Javascript, PHP, Perl, even newer ones such as Go and
>> Dart (although Go has at least dropped the parentheses!).
>>
>
> C's for() was a huge improvement over other languages of the time.

At the time being around 1970, means the world already had Algol60, Algol 68 
and even Fortran. These all had a dedicated way of doing  a straightforward 
iteration. Not as general as C's effort, but when you did have a simple 
loop, it was as lot easier to type (and to get right).

> If C was truly minimalist, it'd just have a "loop" keyword for all loops,
> no conditions, no termination, infinite.  "break" and "continue" would
> still work.

(The first time I had a compiler output C code, it was a kind of 'flat' C 
with all statement structure removed. It just used 'goto' and 'if (...) 
goto' for control flow. The resultant code was just as  fast as a properly 
structured program. So there are degrees of minimalism (and I could have 
gone a lot further).)

-- 
Bartc 

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

#2118 — Re: 100 Things

On Thu, 01 May 2014 04:26:11 -0400, BartC <bc@freeuk.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message  
> news:op.xe5porqb6zenlw@localhost...
>> On Wed, 30 Apr 2014 07:16:19 -0400, BartC <bc@freeuk.com> wrote:

>>> [intN_t etc]
>>
>> How often do you use those?
>
> It's common to use some of those at some time or other, if not all at
> the same time. You've never used CHARBIT

Um, I can say I generally never use them, and probably never.  I can't
say with 100% certainty that I've never, ever used them.  I'd need to
search my code which I have no desire to do.  It's possible I used them
long ago or in special, rare situations.

Mostly, I use a subset of ANSI C.  So, they're not a part of that subset,
but sometimes I do use other C features, library calls, and include
files, although I use those other things very rarely.

> or needed an exact 32-bit signed int?

Until recently, I've almost never used signed, unsigned only.  I've been
working on getting comfortable without 'unsigned' and dropping some of
the "unecessary" or "useless" 'unsigned' keywords with simple things
like 'int' returns or 'char'.

I do have one program that I'm aware of that uses signed.  It needed
to keep a value which could go positive or negative.  That can be done
with unsigned, but requires more work.  Also, I needed to display the
sign, and detecting negative values makes that easier.  So, I went
ahead and used signed for it.  I'm probably used signed decades ago
when I was first learning C.  Of course, I don't change other people's
code to use unsigned.

So, I use 'unsigned long' for 32-bits.  Fortunately, on x86, the compilers
I'm using use 32-bits for it, short 16, char 8.  If 'unsigned long' is
64-bits on some/all 64-bit compilers and 'unsigned long long' is 128-bits,
that could break some of my code, but probably not.  If 'unsigned long  
long'
is 64-bits on most 64-bit compilers, I'm probably good.  That would likely
mean 'unsigned long' is 32, short 16, char 8, as I prefer.  I.e.,each a
progressively larger multiple by 2 starting at 8.

I generally try to keep to ANSI C, so the C99 'uint' extensions aren't
formally available.  GCC generally allows but warns.  E.g., I sometimes
use 'long long' C99 sprintf() format specifiers in ANSI C code (-ansi)
with GCC.  Other compilers will fail that.


Rod Pemberton

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

#2090 — Re: 100 Things

BartC wrote:
>
> As for C being minimalist, I don't know if a language needing these types
> and macros (remembering to substitute all the combinations of 8 16, 32 and
> 64 every time you see N):

<snip long list>

Give a lowish level language such as C works "close to the metal" on a 
wide variety of hardware, how would you avoid having a collection of 
fixed width types?

I agree there's a better way of (but not within the limits of C) to 
specify the limits, but they require some form of generics (such as C++ 
std::numeric_limits).

-- 
Ian Collins

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

#2095 — Re: 100 Things

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:bsdn38Fd2otU3@mid.individual.net...
> BartC wrote:
>>
>> As for C being minimalist, I don't know if a language needing these types
>> and macros (remembering to substitute all the combinations of 8 16, 32 
>> and
>> 64 every time you see N):
>
> <snip long list>
>
> Give a lowish level language such as C works "close to the metal" on a 
> wide variety of hardware, how would you avoid having a collection of fixed 
> width types?

You don't avoid having the range of different types (you need many of those 
anyway have a flexible set of types for storing data). But there are elegant 
ways of doing it without  having sprawling lists of macros and typedefs.

For example, if T is any primitive type, then T:n could define a version 
which is n bits wide.

> I agree there's a better way of (but not within the limits of C) to 
> specify the limits, but they require some form of generics (such as C++ 
> std::numeric_limits).

If T is a numeric type, then T'min and T'max could give you the lower and 
upper limits (as could T'bounds, giving a range type). And you can write 
X'min etc when you have an expression.

You don't need exotic things such as generics. (I know the point of C++ is 
apparently as a tool to build your own language, but when some feature is a 
morning's work on a compiler, then that's a far simpler route.)

-- 
Bartc 

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

#2097 — Re: 100 Things

BartC wrote:
>
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:bsdn38Fd2otU3@mid.individual.net...
>> BartC wrote:
>>>
>>> As for C being minimalist, I don't know if a language needing these types
>>> and macros (remembering to substitute all the combinations of 8 16, 32
>>> and
>>> 64 every time you see N):
>>
>> <snip long list>
>>
>> Give a lowish level language such as C works "close to the metal" on a
>> wide variety of hardware, how would you avoid having a collection of fixed
>> width types?
>
> You don't avoid having the range of different types (you need many of those
> anyway have a flexible set of types for storing data). But there are elegant
> ways of doing it without  having sprawling lists of macros and typedefs.
>
> For example, if T is any primitive type, then T:n could define a version
> which is n bits wide.

So you substitute an underscore for a colon?

What about the least and fast types?  The former don't appear very 
often, but the latter are very useful.

>> I agree there's a better way of (but not within the limits of C) to
>> specify the limits, but they require some form of generics (such as C++
>> std::numeric_limits).
>
> If T is a numeric type, then T'min and T'max could give you the lower and
> upper limits (as could T'bounds, giving a range type). And you can write
> X'min etc when you have an expression.
>
> You don't need exotic things such as generics. (I know the point of C++ is
> apparently as a tool to build your own language, but when some feature is a
> morning's work on a compiler, then that's a far simpler route.)

Generics save you from having to extend the language.

-- 
Ian Collins

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

#2099 — Re: 100 Things

"Ian Collins" <ian-news@hotmail.com> wrote in message
news:bsegt5Fd2otU7@mid.individual.net...
> BartC wrote:

>> You don't avoid having the range of different types (you need many of
>> those
>> anyway have a flexible set of types for storing data). But there are
>> elegant
>> ways of doing it without  having sprawling lists of macros and typedefs.
>>
>> For example, if T is any primitive type, then T:n could define a version
>> which is n bits wide.
>
> So you substitute an underscore for a colon?

You mean when int32_t, for example, is written as int:32?

The "_t" could have been eliminated anyway, just have int32 as the type.
(int32 becomes a reserved word, what's the big deal?)

But the little thing with the colon thing actually eliminates dozens of
typedefs from the official headers. And the thing with the 'min and 'max
attributes eliminates dozens more. If you have:

unsigned long long int A;

then you need ULLONG_MAX for the highest value of A. But if the type of A
changes, you then have to search for and update all these ULLONG_MAXs. Or
you could just write A'max.

It is actually a big deal having these things properly supported by the
language and not crudely bolted on.

> What about the least and fast types?  The former don't appear very often,
> but the latter are very useful.

I don't really know what they are for. However, the T:n syntax (which is
only a suggestion after all), does give you the flexibility to specify /any/
width, not just those the C implementers have deigned to list in the include
file. int:36 for example.

>>> I agree there's a better way of (but not within the limits of C) to
>>> specify the limits, but they require some form of generics (such as C++
>>> std::numeric_limits).
>>
>> If T is a numeric type, then T'min and T'max could give you the lower and
>> upper limits (as could T'bounds, giving a range type). And you can write
>> X'min etc when you have an expression.
>>
>> You don't need exotic things such as generics. (I know the point of C++
>> is
>> apparently as a tool to build your own language, but when some feature is
>> a
>> morning's work on a compiler, then that's a far simpler route.)
>
> Generics save you from having to extend the language.

By having every user extend his own version, and in a different style to
everyone else? Because /someone/ has to add those 'min and 'max features!
BTW, if someone did want to do that, how exactly do they determine the
minimum and maximum values of a type?

Basic stuff like this should really be built-in. (I know language-building
features are intriguing, but my experience is that just implementing it
directly is a lot less work.)

-- 
Bartc 

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

#2103 — Re: 100 Things

BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote:
>>
>> Generics save you from having to extend the language.
>
> By having every user extend his own version, and in a different style to
> everyone else? Because /someone/ has to add those 'min and 'max features!
> BTW, if someone did want to do that, how exactly do they determine the
> minimum and maximum values of a type?

No, by including them in the language's library and allowing users to 
apply the standard rules to their own types.

> Basic stuff like this should really be built-in. (I know language-building
> features are intriguing, but my experience is that just implementing it
> directly is a lot less work.)

The you have to change the language for any new types.

-- 
Ian Collins

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

#2098 — Re: 100 Things

On Thu, 1 May 2014 09:35:42 +0100, BartC wrote:

> For example, if T is any primitive type, then T:n could define a version 
> which is n bits wide.

Let T be ... IEEE 754 float, UCS-2 character ... Does Int32:31 make
Positive? Negative? Maybe, Odd?

It is not that simple, and an abstraction inversion, to constrain a type,
even a scalar type, by the length of its memory representation.

Semantic constraints must be related to the type semantics. Representation
constraints (e.g. that Boolean is packed, 1 bit-length) is an absolutely
different thing and rarely required thing even in systems programming.

>> I agree there's a better way of (but not within the limits of C) to 
>> specify the limits, but they require some form of generics (such as C++ 
>> std::numeric_limits).
> 
> If T is a numeric type, then T'min and T'max could give you the lower and 
> upper limits (as could T'bounds, giving a range type).

This is again a simplification. There is no min/max if T is Complex. And
Complex is numeric (mathematically speaking, a field). If T is IEEE float
what T'Min means? The minimal number proper or -Inf?

The point is that stuff like T'Min is a part of interface (of some ordered
finite set, which Integer is, and Complex is not). The language must
support such interfaces and programs must be written in terms of such
interfaces.

> You don't need exotic things such as generics.

Yes. Parametric polymorphism (a decent name for macros) has no place in a
good (=typed) language. C++ templates proved that point.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2101 — Re: 100 Things

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:8muqscxvu33i$.22498hadddgj.dlg@40tude.net...
> On Thu, 1 May 2014 09:35:42 +0100, BartC wrote:
>
>> For example, if T is any primitive type, then T:n could define a version
>> which is n bits wide.
>
> Let T be ... IEEE 754 float, UCS-2 character ... Does Int32:31 make
> Positive? Negative? Maybe, Odd?
>
> It is not that simple, and an abstraction inversion, to constrain a type,
> even a scalar type, by the length of its memory representation.

At the level we're talking about, generally we know the hardware can deal
with integer values that are 8, 16, 32 or 64 bits wide, and floating point
values that are 32 or 64 bits. (There might be a few extra odd ones such as
80-bit floats, or software-supported 128-bit ints.)

One way of choosing whether to use 8, 16, 32 or 64 bits for a storage type
(for storing data in memory), is to actually specify 8, 16, 32, or bits! It
can't get any simpler.

(And I've tried using ranges to specify a width, but it doesn't really work
for me. Besides, does the range 10'000 .. 10'100 need 16 bits, or 8?)

> Semantic constraints must be related to the type semantics. Representation
> constraints (e.g. that Boolean is packed, 1 bit-length) is an absolutely
> different thing and rarely required thing even in systems programming.

I need to do this quite a lot. Try talking to Win32, for example, and dare
to so in a language which is not MS C or C++, or even not C at all, then you
need to go into to excruciating detail to get the various structs and so on
exactly compatible.

>> If T is a numeric type, then T'min and T'max could give you the lower and
>> upper limits (as could T'bounds, giving a range type).
>
> This is again a simplification. There is no min/max if T is Complex. And
> Complex is numeric (mathematically speaking, a field). If T is IEEE float
> what T'Min means? The minimal number proper or -Inf?

A minor detail. I never use Complex so can't comment on that, but min/max
can simply not be defined where it doesn't make sense.

But as this is about alternatives to C's list of limit macros, then it
doesn't mention any limits for Complex. While for floating point, 'min is be
the lowest non-zero value that can be represented, while 'max is be the 
highest before it overflows to Inf  (some 1e-308 to 1e+308 for 64-bits.) 
Anything else wouldn't be that useful.

-- 
bartc 

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

#2106 — Re: 100 Things

On Thu, 1 May 2014 11:02:17 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:8muqscxvu33i$.22498hadddgj.dlg@40tude.net...
>> On Thu, 1 May 2014 09:35:42 +0100, BartC wrote:
>>
>>> For example, if T is any primitive type, then T:n could define a version
>>> which is n bits wide.
>>
>> Let T be ... IEEE 754 float, UCS-2 character ... Does Int32:31 make
>> Positive? Negative? Maybe, Odd?
>>
>> It is not that simple, and an abstraction inversion, to constrain a type,
>> even a scalar type, by the length of its memory representation.
> 
> At the level we're talking about, generally we know the hardware can deal
> with integer values that are 8, 16, 32 or 64 bits wide, and floating point
> values that are 32 or 64 bits. (There might be a few extra odd ones such as
> 80-bit floats, or software-supported 128-bit ints.)
> 
> One way of choosing whether to use 8, 16, 32 or 64 bits for a storage type
> (for storing data in memory), is to actually specify 8, 16, 32, or bits! It
> can't get any simpler.

What do you do when there is no given machine type? Let you compile for
32-bit i686. There is no 64-bit integer. Wait, there is but you need
special instructions. It is not the way to deal with this. You don't make
the language semantics dependent on the target machine.

> (And I've tried using ranges to specify a width, but it doesn't really work
> for me. Besides, does the range 10'000 .. 10'100 need 16 bits, or 8?)

Why not 7 bits? It can be 32 bits on a DSP. Why should the programmer care?
I he cares he should spell his care in the language as a representation
constraint.

>> Semantic constraints must be related to the type semantics. Representation
>> constraints (e.g. that Boolean is packed, 1 bit-length) is an absolutely
>> different thing and rarely required thing even in systems programming.
> 
> I need to do this quite a lot. Try talking to Win32, for example, and dare
> to so in a language which is not MS C or C++, or even not C at all, then you
> need to go into to excruciating detail to get the various structs and so on
> exactly compatible.

Win32 defines a set of types, like BYTE, DWORD, LPARAM etc. The only thing
you should do is define these types using the means the language offers.
You don't need to have these types built-in.

BTW, speaking of representation constraints, it is not only memory unit
size (not all machines have byte as the memory unit), it is endianness and
complement.

>>> If T is a numeric type, then T'min and T'max could give you the lower and
>>> upper limits (as could T'bounds, giving a range type).
>>
>> This is again a simplification. There is no min/max if T is Complex. And
>> Complex is numeric (mathematically speaking, a field). If T is IEEE float
>> what T'Min means? The minimal number proper or -Inf?
> 
> A minor detail. I never use Complex so can't comment on that, but min/max
> can simply not be defined where it doesn't make sense.

As it does not make sense for numeric types in general. The point is, it is
finer than numeric even in such simplistic cases as merely upper and lower
bounds. You cannot build this in into the language. It should be deal with
in a more general manner.

> But as this is about alternatives to C's list of limit macros, then it
> doesn't mention any limits for Complex. While for floating point, 'min is be
> the lowest non-zero value that can be represented, while 'max is be the 
> highest before it overflows to Inf  (some 1e-308 to 1e+308 for 64-bits.)

According to which definition? Min and Max are defined in a certain way to
solve problems. From the definition depends which propositions hold and
which do not. E.g. for some sorting algorithm you might well prefer -Inf as
the starting point over least number greater than -Inf. Or consider a
program that checks if X in T'Min..T'Max. Is it a tautology? Must it be
tautology for any ordered type? Is NaN ordered?
 
> Anything else wouldn't be that useful.

Prove that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2109 — Re: 100 Things

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:i8gmjwf2beyz.12f8p3m5cxcnh$.dlg@40tude.net...
> On Thu, 1 May 2014 11:02:17 +0100, BartC wrote:

>> At the level we're talking about, generally we know the hardware can deal
>> with integer values that are 8, 16, 32 or 64 bits wide, and floating
>> point
>> values that are 32 or 64 bits. (There might be a few extra odd ones such
>> as
>> 80-bit floats, or software-supported 128-bit ints.)
>>
>> One way of choosing whether to use 8, 16, 32 or 64 bits for a storage
>> type
>> (for storing data in memory), is to actually specify 8, 16, 32, or [64]
>> bits! It
>> can't get any simpler.
>
> What do you do when there is no given machine type? Let you compile for
> 32-bit i686. There is no 64-bit integer. Wait, there is but you need
> special instructions. It is not the way to deal with this. You don't make
> the language semantics dependent on the target machine.

That machines generally work in powers-of-two bitwidths is well-known. It
doesn't matter so much if the machine doesn't fully support each width. Some
might have 32-bit operations but byte-addressed memory. Or 64-bits may need
a bit more work on a 32-bit processor (and may not be feasible on anything
less). It doesn't matter.

Whatever the likely choices are, there is a place for a low-level language
to specify those directly in terms of bit widths. The next level up can deal
with it your way.

>> (And I've tried using ranges to specify a width, but it doesn't really
>> work
>> for me. Besides, does the range 10'000 .. 10'100 need 16 bits, or 8?)
>
> Why not 7 bits? It can be 32 bits on a DSP. Why should the programmer
> care?
> I he cares he should spell his care in the language as a representation
> constraint.

Because 7-bits isn't a likely memory-width size. The likelihood is that it
will be 8 or 16 or 32.

(If someone needs to buy stationery, they might specify A5 or A4 or A3.
Those are the standard choices (in the EU). They might order it by
specifying a requirement in mm or cm, but that would be unusual. They work
out for themselves what a suitable standard size is.)

>>> Semantic constraints must be related to the type semantics.
>>> Representation
>>> constraints (e.g. that Boolean is packed, 1 bit-length) is an absolutely
>>> different thing and rarely required thing even in systems programming.
>>
>> I need to do this quite a lot. Try talking to Win32, for example, and
>> dare
>> to so in a language which is not MS C or C++, or even not C at all, then
>> you
>> need to go into to excruciating detail to get the various structs and so
>> on
>> exactly compatible.
>
> Win32 defines a set of types, like BYTE, DWORD, LPARAM etc. The only thing
> you should do is define these types using the means the language offers.
> You don't need to have these types built-in.

You need to find out what those types actually mean. Usually the API will
not tell you. One way is to run the MS compiler with 'sizeof(LONG)'. Or
maybe that info is buried deep in the docs somewhere.

That's the first step. But once you've found out that WORD means signed
16-bits, then what? You need to express this in your own language. But how?
Suddenly that int:16 denotation isn't so useless after all! Better than
defining a type around -32768..32767, which could conceivably be 
represented, for reasons best known to the compiler, as 32 bits in the range 
1000000 to 1065535. That's not good at all.

> BTW, speaking of representation constraints, it is not only memory unit
> size (not all machines have byte as the memory unit), it is endianness and
> complement.

Those are issues I've never really had to deal with. So it's up to someone 
else to offer suggestions as to how that can be handled, for example to 
create a struct where the values are the right way around when transmitted 
between
machines.

I'm not trying to create the perfect language here. (And AFAIK, C doesn't
concern itself with endian-ness either.)

> As it does not make sense for numeric types in general.

Yes it does. The odometer in my car displays a 6-digit decimal unsigned
type. The 'min value is 000000, and the 'max is 999999. That means I know
when it approaches 999999, that something will happen (probably, wrap around
to 000000, if the car lasts that long).

>> But as this is about alternatives to C's list of limit macros, then it
>> doesn't mention any limits for Complex. While for floating point, 'min is
>> be
>> the lowest non-zero value that can be represented, while 'max is be the
>> highest before it overflows to Inf  (some 1e-308 to 1e+308 for 64-bits.)
>
> According to which definition?

According to 'DBL_MAX' and similar macros in the C standard. Implementations
provide their own actual values. My suggestion is simply to do with
different ways to provide or access that information.

> Or consider a
> program that checks if X in T'Min..T'Max. Is it a tautology? Must it be
> tautology for any ordered type? Is NaN ordered?

If X is of type T, then perhaps that is not so useful. If not, then it could
certainly be useful, because if X is in byte'range (a more compact way of 
writint it; 0..255 in other words), then it can be written to a file using 
one byte.

Or in a compiler, if X in int32'range then that constant can be assigned
type int32. Etc.

>> Anything else wouldn't be that useful.

> Prove that.

You need to define what 'useful' might be. I certainly find them useful, but
not indispensable (I know most of the int limits already - for twos
complement machines anyway - or can express them in hex without much
trouble. But writing int64'max is easier).

-- 
Bartc 

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

#2110 — Re: 100 Things

On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:i8gmjwf2beyz.12f8p3m5cxcnh$.dlg@40tude.net...
>> On Thu, 1 May 2014 11:02:17 +0100, BartC wrote:
> 
>>> At the level we're talking about, generally we know the hardware can deal
>>> with integer values that are 8, 16, 32 or 64 bits wide, and floating point
>>> values that are 32 or 64 bits. (There might be a few extra odd ones such
>>> as 80-bit floats, or software-supported 128-bit ints.)
>>>
>>> One way of choosing whether to use 8, 16, 32 or 64 bits for a storage
>>> type (for storing data in memory), is to actually specify 8, 16, 32, or [64]
>>> bits! It can't get any simpler.
>>
>> What do you do when there is no given machine type? Let you compile for
>> 32-bit i686. There is no 64-bit integer. Wait, there is but you need
>> special instructions. It is not the way to deal with this. You don't make
>> the language semantics dependent on the target machine.
> 
> That machines generally work in powers-of-two bitwidths is well-known.

And those that don't, you program in another language... Right?

What should be the properties of this, another, clearly better language,
since it can be used for programming any machine?

>>> (And I've tried using ranges to specify a width, but it doesn't really work
>>> for me. Besides, does the range 10'000 .. 10'100 need 16 bits, or 8?)
>>
>> Why not 7 bits? It can be 32 bits on a DSP. Why should the programmer
>> care? I he cares he should spell his care in the language as a representation
>> constraint.
> 
> Because 7-bits isn't a likely memory-width size.

1-bit of Boolean isn't either. So what?

> (If someone needs to buy stationery, they might specify A5 or A4 or A3.
> Those are the standard choices (in the EU).

It does not mean you could not write a poem on a piece of letter paper
size.

>>>> Semantic constraints must be related to the type semantics. Representation
>>>> constraints (e.g. that Boolean is packed, 1 bit-length) is an absolutely
>>>> different thing and rarely required thing even in systems programming.
>>>
>>> I need to do this quite a lot. Try talking to Win32, for example, and dare
>>> to so in a language which is not MS C or C++, or even not C at all, then
>>> you need to go into to excruciating detail to get the various structs and so
>>> on exactly compatible.
>>
>> Win32 defines a set of types, like BYTE, DWORD, LPARAM etc. The only thing
>> you should do is define these types using the means the language offers.
>> You don't need to have these types built-in.
> 
> You need to find out what those types actually mean. Usually the API will
> not tell you.

Ah, but they do:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

>> BTW, speaking of representation constraints, it is not only memory unit
>> size (not all machines have byte as the memory unit), it is endianness and
>> complement.
> 
> Those are issues I've never really had to deal with.

You must if you deal with any I/O, which is a big part of systems
programming. I must deal with endianness daily, since much of hardware we
are talking with is big-endian. Intel is little-endian.

> I'm not trying to create the perfect language here. (And AFAIK, C doesn't
> concern itself with endian-ness either.)

C does not concern itself with pretty much anything. It is one of languages
designed ad-hoc. Guys had a free machine in their hands and nothing to
do... I envy them.

>> As it does not make sense for numeric types in general.
> 
> Yes it does.

Again, complex numbers *are* numbers.

>>> But as this is about alternatives to C's list of limit macros, then it
>>> doesn't mention any limits for Complex. While for floating point, 'min is be
>>> the lowest non-zero value that can be represented, while 'max is be the
>>> highest before it overflows to Inf  (some 1e-308 to 1e+308 for 64-bits.)
>>
>> According to which definition?
> 
> According to 'DBL_MAX' and similar macros in the C standard.

C standard might define "-" to be "+". There must be more serious reasons
why the upper bound of a real numeric type is to be defined this or other
way.

>> Or consider a
>> program that checks if X in T'Min..T'Max. Is it a tautology? Must it be
>> tautology for any ordered type? Is NaN ordered?
> 
> If X is of type T, then perhaps that is not so useful. If not, then it could
> certainly be useful, because if X is in byte'range (a more compact way of 
> writint it; 0..255 in other words), then it can be written to a file using 
> one byte.

The question was, if X in T'Min..T'Max is a tautology then the check can be
optimised away. If not, it cannot be. Let you implement binary search, you
can do it in a certain way when the above holds [the search invariant is
that the root is within the interval]. If not, then you must change the
code.

> Or in a compiler, if X in int32'range then that constant can be assigned
> type int32. Etc.

It was not about type conversions, as I have explained.
 
>>> Anything else wouldn't be that useful.
> 
>> Prove that.
> 
> You need to define what 'useful' might be.

No, *you* need to define it. I am trying to avoid arguing to usefulness,
and am aiming much lower, at merely correctness. Once the language is
correct (more or less), one can progress to its usefulness.

Yes, you could say that C is useful, though incorrect. But you didn't.
(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#2111 — Re: 100 Things

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:

>> That machines generally work in powers-of-two bitwidths is well-known.
>
> And those that don't, you program in another language... Right?

Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types, and so 
does Java. The sensibly decided not to try and support every conceivable 
computing platform, past and future, and up with a language that would tie 
itself up in knots.

> What should be the properties of this, another, clearly better language,
> since it can be used for programming any machine?
>
>>>> (And I've tried using ranges to specify a width, but it doesn't really 
>>>> work
>>>> for me. Besides, does the range 10'000 .. 10'100 need 16 bits, or 8?)
>>>
>>> Why not 7 bits? It can be 32 bits on a DSP. Why should the programmer
>>> care? I he cares he should spell his care in the language as a 
>>> representation
>>> constraint.
>>
>> Because 7-bits isn't a likely memory-width size.
>
> 1-bit of Boolean isn't either. So what?

OK, if we extend it a little to include sub-byte types, then in the sequence 
1, 2, 4, 8, 16, 32, 64 bits, 8 or 16 are still the best choices.

(The int:N syntax does, nevertheless, let you write int:7 if you want. 
Although I reject that at the moment since I don't support odd sizes. Not as 
a type anyway; it is possible to work with such such bit-fields though.)

 >> (If someone needs to buy stationery, they might specify A5 or A4 or A3.
>> Those are the standard choices (in the EU).
>
> It does not mean you could not write a poem on a piece of letter paper
> size.

>>> Win32 defines a set of types, like BYTE, DWORD, LPARAM etc. The only 
>>> thing
>>> you should do is define these types using the means the language offers.
>>> You don't need to have these types built-in.
>>
>> You need to find out what those types actually mean. Usually the API will
>> not tell you.
>
> Ah, but they do:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

Thanks. When I first delved into this, I didn't have the internet. But 
notice that the sizes, when given, are in terms of bits, and whether signed 
or unsigned. It would be simplest if the language to be used for interfacing 
to it could also define its own types the same way. In the language /you're/ 
proposing, it would be difficult.

>>> As it does not make sense for numeric types in general.
>>
>> Yes it does.
>
> Again, complex numbers *are* numbers.

Most people who are not mathematicians would disagree (actually most people 
would not know what a complex number is).

If you want to make 'max meaningful for complex, then fine; let's say that 
Complex'max just returns the same scalar value as Real'max (assuming the 
former is composed of two Reals), otherwise just apply 'max on each 
component.

(BTW what /is/ the largest value that can be represented in IEEE 754 64-bit 
floating point, which is not Inf?)

-- 
Bartc 

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

#2115 — Re: 100 Things

On 2014-05-01, BartC <bc@freeuk.com> wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>
>>> That machines generally work in powers-of-two bitwidths is well-known.
>>
>> And those that don't, you program in another language... Right?
>
> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types, and so 
> does Java.

These languages support *only* these types.

"All the world is VAX (or x86 or SPARC)."

> The sensibly decided not to try and support every conceivable 
> computing platform, past and future, and up with a language that would tie 
> itself up in knots.

C doesn't tie itself in knots; it is able to conform to the types provided
by the hardware, for the best efficiency.

On a 36 bit machine, a Java compiler has to generate wasteful instructions to
reduce intermediate numeric results to 32 bits in cases where it's not
necessary, and also denies the programmer the use of those four bits.

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

#2119 — Re: 100 Things

On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:

>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>
>>> And those that don't, you program in another language... Right?
>>
>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>> and so> does Java.
>
> These languages support *only* these types.
>

By "these languages", I'm assuming you mean C/C++ and derivatives.

If so, you've been doing pretty good with your understanding of C,
but not on that one.  C doesn't define a byte as 8-bits as defined
by the creators of EBCDIC and ASCII: Bob Bemer and Hugh McGregor Ross,
and Dr. Werner Buchholtz who defined a byte as 8-bits.  It defines
a byte as the natural word size or minimal address unit of the machine
or somesuch.  I'm not going to re-read the specifications on this.
E.g., most microprocessors have an 8-bit word size or address unit.
So, for those machines, a byte and a char are 8-bits.  They also
typically have an integer that is an even multiple of 8-bits, e.g,
16-bits, 32-bits, etc.  But, if we have a central processing unit
(cpu) with a 16-bit minimum address unit, then a C byte is 16-bits,
so is C's nul '\0' terminator.  It must have all 16-bits cleared.
This is to locate the end-of-string quickly without having to mask
or unpack characters.  This is documented in one of Ritchie's papers.
However, a char on such a machine could be 8-bits, for two char's
per C byte, or it could be 9-bits etc with only one char per C byte.


Rod Pemberton

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

#2121 — Re: 100 Things

Rod Pemberton wrote:
> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>
>>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>>
>>>> And those that don't, you program in another language... Right?
>>>
>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>> and so> does Java.
>>
>> These languages support *only* these types.
>>
>
> By "these languages", I'm assuming you mean C/C++ and derivatives.

Your understanding is arse about face.

-- 
Ian Collins

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

#2149 — Re: 100 Things

On Fri, 02 May 2014 08:30:49 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>Rod Pemberton wrote:
>> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:
>>
>>>>>> That machines generally work in powers-of-two bitwidths is well-known.
>>>>>
>>>>> And those that don't, you program in another language... Right?
>>>>
>>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>>> and so> does Java.
>>>
>>> These languages support *only* these types.
>>>
>>
>> By "these languages", I'm assuming you mean C/C++ and derivatives.
>
>Your understanding is arse about face.

Rod is correct that C defines 'byte' as a minimal addressable unit and
defines characters as data which fits into a byte.  Packing multiple
characters into a single 'byte' is non-compliant - but that doesn't
stop compilers for (wide-byte) word oriented machines [typically DSPs]
from doing so.


From the C99 standard:

 3.6
 byte   
   addressable unit of data storage large enough to hold any member of
   the basic character set of the execution environment
   NOTE 1 It is possible to express the address of each individual
          byte of an object uniquely.
   NOTE 2 A byte is composed of a contiguous sequence of bits, the
          number of which is implementation-defined.  The least
          significant bit is called the low-order bit; the most
          significant bit is called the high-order bit.

 3.7
 character
   < abstract > member  of  a  set  of  elements  used  for  the 
   organization,  control, or representation of data

 3.7.1
 character
   single-byte character
   < C > bit representation that fits in a byte

 
 See also:  5.2.1 - Character sets [too long to copy]

 See also:  5.2.4.2.1  Sizes of integer types <limits.h>

   — number of bits for smallest object that is not a bit-field (byte)
     CHAR_BIT      >= 8    [per 5.2.1]


The language in the C89/90 standard is not as clear, but the semantics
it describes are equivalent to above.  Unfortunately I don't have my
copy of C89/90 handy to provide exact cites.

George

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

#2150 — Re: 100 Things

On Sat, 03 May 2014 01:29:10 -0400, George Neuner <gneuner2@comcast.net>  
wrote:
> On Fri, 02 May 2014 08:30:49 +1200, Ian Collins <ian-news@hotmail.com>  
> wrote:
>> Rod Pemberton wrote:
>>> On Thu, 01 May 2014 14:30:17 -0400, Kaz Kylheku <kaz@kylheku.com>  
>>> wrote:
>>>> On 2014-05-01, BartC <bc@freeuk.com> wrote:
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>>> news:yryqqrizlv6f$.brqhfwfl79vg.dlg@40tude.net...
>>>>>> On Thu, 1 May 2014 15:12:34 +0100, BartC wrote:

>>>>>>> That machines generally work in powers-of-two bitwidths is  
>>>>>>> well-known.
>>>>>>
>>>>>> And those that don't, you program in another language... Right?
>>>>>
>>>>> Yes, exactly. C# supports 8, 16, 32 and (I assume) 64-bit data types,
>>>>> and so does Java.
>>>>
>>>> These languages support *only* these types.
>>>
>>> By "these languages", I'm assuming you mean C/C++ and derivatives.
>>
>> Your understanding is arse about face.
>
> Rod is correct that C defines 'byte' as a minimal addressable unit and
> defines characters as data which fits into a byte.

Oh, I thought Ian was saying I made the wrong assumption on which
languages were being discussed.  I thought C, C++, and variations
were under discussion.  So, I was going to go back and check what
languages were being discussed, but didn't.

Before that, I thought Kaz was saying C didn't support sizes other
than 8, 16, 32, 64, which it can.  Standardized microprocessor
architecture is what lends itself to 8-bits and multiples.
Central processing units (cpu), used on mainframes and such,
had widely varying architectures, some of which had C on them.


Rod Pemberton

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

#2170 — Re: 100 Things

On Sat, 03 May 2014 02:37:54 -0400, "Rod Pemberton"
<dont_use_email@xnothavet.cqm> wrote:

>On Sat, 03 May 2014 01:29:10 -0400, George Neuner <gneuner2@comcast.net>  
>wrote:
>>
>> Rod is correct that C defines 'byte' as a minimal addressable unit and
>> defines characters as data which fits into a byte.
>
>Oh, I thought Ian was saying I made the wrong assumption on which
>languages were being discussed.  I thought C, C++, and variations
>were under discussion.  So, I was going to go back and check what
>languages were being discussed, but didn't.
>
>Before that, I thought Kaz was saying C didn't support sizes other
>than 8, 16, 32, 64, which it can.  Standardized microprocessor
>architecture is what lends itself to 8-bits and multiples.

I haven't seen the whole thread, but ISTM Kaz [will correct me I'm
sure] is arguing that C doesn't have mechanism to semantically define
new numeric types (or subtypes), so programmers are de facto
constrained to those types that C provides.

Which is true with the minor exception that you can abuse bitfields to
create a restricted width integer.  It doesn't buy you very much
because bitfields are restricted to register width [or less!] and the
result still is just a C integer with the same semantics only having a
smaller +/- range and maybe slower access.  

E.g., there is no way to define your new integer type to have
different semantics such as arbitrary range, or a range with gaps, or
saturation vs wrap-around arithmetic, or overflow signaling, etc.  


>Central processing units (cpu), used on mainframes and such,
>had widely varying architectures, some of which had C on them.

Yes, though many of them predate C standardization.  Most of the early
machines would not be standard compliant due to restricted (6 or 7
bit) character sets and/or lack of individual character addressing.

The issue was not the size of their memory 'word', but if multiple
characters packed into a word could be individually addressed.  On
most mainframes that was not true - packed characters had to be
loaded/stored together and instructions manipulating them in a
register had to specify which character(s) to change by field selector
or mask.  [This still is true of many DSPs today.]

Recall that the C standard didn't emerge until 1989 [for ANSI, ISO
ratified a year later] and so it was colored more by exposure to
hardware of the late 70's and 80's than by anything that came before.
CPU design already had settled on power of 2 widths and the standard
effectively was software rubber stamping hardware.

George

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

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

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

csiph-web