Re: "core C"

From	Bartc <bc@freeuk.com>
Newsgroups	comp.lang.c
Subject	Re: "core C"
Date	2015-06-30 17:44 +0100
Organization	A noiseless patient Spider
Message-ID	<mmugvp$mpc$1@dont-email.me> (permalink)
References	(3 earlier) <6106badd-4e24-47df-b3df-490005aa2fc9@googlegroups.com> <mmu3mv$rsv$1@dont-email.me> <148aee8c-8afc-476c-a200-51fded30fdea@googlegroups.com> <mmu7vc$eak$1@dont-email.me> <47f5d704-4ab6-4afc-a558-cbed67915a76@googlegroups.com>

Show all headers | View raw

On 30/06/2015 15:50, Rick C. Hodgin wrote:
> On Tuesday, June 30, 2015 at 10:11:19 AM UTC-4, Bart wrote:

>>> Two's complement.  Use an s8 value and store as b7 when done.
>>
>> Not elegant. You might as well go for ubit:N and sbit:N while you're at it.
>
> I agree.  Alright.  We won't limit it at all.  We'll handle them as
> structs, allowing for any type.  The syntax will be b9:type if you
> need it to some specific type, like b9:s32.  That will also help with
> ranging, which I could also be specified here using bN:type:rangemethod.

You've already got syntax sN and uN for signed/unsigned ints of N bits, 
and mixing it up with the syntax bN for signed/unsigned of N bits!

Either combine the two, so using s9 for your example, or keep them 
separate as sbits:9 or sbits9.

>> This can cause problems when passing one of those rows, even from
>> element[0] of that row, to a function if the mechanism assumes the
>> pointer will be aligned.
>
> You can't pass one of those rows.  If you have a bit array, only the
> entire thing can be passed, and you access it by referencing the
> elements within.

Suppose someone creates a 2D array by having an array of bit arrays (as 
is done in C anyway). Are you saying that you are now restricted in what 
you can do with a row of that array-of-bit-arrays?

>> But if you are going to have arrays of bits, then it's going to be hard
>> to manage without using bit pointers. Or are you going to pass a
>> 1000000-element array of bit:3 types by value?
>
> You would pass a pointer to the start of the array, and an offset to
> the element within.

Presumably this (pointer,offset) combo is the same size overall as the 
other pointers in the language? Or would you make an exception, or not 
call it a pointer, or would require two values to be passed?

>> Sorry, this doesn't look right. You are going to end up with a struct
>> which is likely to be 16 bytes (maybe 12 bytes if you put the values
>> first, unless it's padded anyway), to store a single u8 value; why?
>
> Because it's a universal type.  The same A you use in one moment to
> store a u8 can later be used to store a double, etc.  It requires no
> additional allocation, and is available to be used in this weakly
> typed form.

But you gain nothing from storing an 8-bit value int instead of 32 or 64 
bits.

And since this has now all got to be sorted out at runtime, it means 
that to execute:

   A+B

when each operand might be s8 s16 s32 s64 u8 u16 u32 u64 f32 f64 (to say 
nothing of big ints and bit floatS), that means up to 100 different 
combinations to consider. Per operator. Plus all the illegal 
combinations to be trapped (array plus a struct for example).

Small types such aa 8-bit values are only of use as storage types, to 
save space when you have an array of them, or to craft a particular 
shape of struct, or for forming strings. They are are of little use as 
standalone variables, let alone inside a variant type.

-- 
Bartc

Thread

"core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 08:38 +0200
  Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-06-30 07:54 +0000
    Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 02:55 -0700
    Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:31 +0200
      Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 18:15 +0200
        Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 12:19 -0700
  Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:27 -0700
    Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:48 -0700
      Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:07 +0100
        Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:15 -0700
    Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:02 +0100
      Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:13 -0700
        Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:58 +0100
          Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:11 -0700
            Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 15:11 +0100
              Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:50 -0700
                Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:24 +0200
                Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 17:44 +0100
                Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 10:04 -0700
                Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 11:46 +0100
                Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 04:40 -0700
                Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 08:05 -0700
                Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 17:01 +0100
                Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 10:56 -0700
                Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 12:59 -0500
                Re: "core C" Bartc <bc@freeuk.com> - 2015-07-04 20:25 +0100
                Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 20:56 -0500
        Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:17 +0100
    Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:03 +0100
      Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:16 -0700
    Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 15:46 +0200
      Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:54 -0700
      Re: "core C" Steve Thompson <stevet810@gmail.com> - 2015-07-03 12:25 +0000
    Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-07-01 15:04 +0000
      Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 08:12 -0700
    Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 10:36 -0500
  Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:41 -0700
    Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:19 +0100
      Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:25 -0700
        Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 15:48 +0100
          Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:52 -0700
  Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:42 -0700
  Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 08:28 -0700
    Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 22:28 +0200
      Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 08:45 +1200
        Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 13:56 -0700
          Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 10:27 +0200
        Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 14:56 -0700
          Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:03 +1200
            Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 15:31 -0700
              Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:52 +1200
                Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 16:58 -0700
                Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-06-30 17:30 -0700
                Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 08:54 +0200
                Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 07:54 -0700
                Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-01 09:42 -0700

csiph-web