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

Groups > comp.lang.c > #64669

Re: "core C"

Show all headers | View raw

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

...

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

for dynamic types, by stuff generally uses a full-width 'fixnum' and 
'flonum' for pretty much all the narrower integer and floating point types.

the fixnum type has a 62-bit range by default.
there is a subset of fixnum which is 32-bits, but it isn't really 
clearly distinguished, and mostly exists as a special-case.

the flonum type has full double precision over a large part of its range.


basic summary (stated before):
   variants are 64-bit, with the high 4 bits as a major tag:
   0: Pointer
   1/2: Fixnum (Positive)
   3/4: Flonum (+, E+/-256)
   5/6: currently reserved in FRVM
   7: smaller tagged literal spaces
   8: Flonum (large exponent, Inf/NaN)
   9/A: reserved in FRVM
   B/C: Flonum (-, E+/-256)
   D/E: Fixnum (Negative)
   F: Pointer (64-bit only)

the Fixnum coding is a little awkward, sadly, but is based mostly on 
wanting to be able to identity-map parts of the pointer and double spaces.

Fixnum-32 special cases:
   0x10000000'XXXXXXXX: Positive/Unsigned
   0xEFFFFFFF'XXXXXXXX: Negative
   or, basically, sign or zero extend and XOR high bits with 0x10000000.

in my past VM (BSVM), both pointer-cases were untagged (memory-objects 
were typed, rather than pointers), however, in the current FRVM:
   0x0TTTYYYY'XXXXXXXX: Pointer
     X is the low bits of the pointer.
     Y is also part of the pointer for 64 bits.
       currently it is reserved and MBZ for 32-bit targets.
     T: type-tag, index into a type-info table
       0 is special, and means a raw/untyped pointer.
   0xFXXXXXXX'XXXXXXXX: Pointer (64-bit only)
     BSVM: Negative Pointers only
     FRVM: Possibly may be used for 60-bit addresses (both signs).


TBD: currently there is no good way to encode a primitive-typed pointer 
in the FRVM tagged-reference.

ex, if one did something like:
   __variant v;
   int *pi;
   int i;
   ...
   v=pi;
   i=v[3];

then one has a problem if variant would not remember the type of the 
pointer and assumes it to be 'void *'. the tags are generally used for 
VM object types, rather than for arbitrary type signatures.

alternatively, it could do like BSVM, and have the VM use heap-allocated 
boxed pointers in this case.

possible:
   0x9TTTYYYY'XXXXXXXX: Primitive-Type Pointer
     X is the low bits of the pointer.
     Y is also part of the pointer for 64 bits.
       For 32-bits (Possible):
	High 3 bits:
           0: Signature
           1: '*'
           2: '**'
           3: '***'
           4: '****'
           5: '*****'
           6: '******'
           7: '*******'
         Low 13 bits:
           0: Unbounded / Signature Based
           1-8191: Bounded
     T: index into a type signature table.
       0-15 or 0-255 are special cases (built-in types).
	0: 'int *'
	1: 'long long *'
	2: 'float *'
	3: 'double *'
	4: 'void **'
	5: 'void *'
	6: reserved
	7: 'long *'
	8: 'char *'
	9: 'unsigned char *'
	10: 'short *'
	11: 'unsigned short *'
	12: 'unsigned int *'
	13: 'unsigned long long *'
	14: 'unsigned long *'
	15: reserved
       256+ would be for types defined via signatures (structs, ...).


or such...

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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