Re: "core C"

From	Bartc <bc@freeuk.com>
Newsgroups	comp.lang.c
Subject	Re: "core C"
Date	2015-07-04 20:25 +0100
Organization	A noiseless patient Spider
Message-ID	<mn9bsp$aji$1@dont-email.me> (permalink)
References	(5 earlier) <148aee8c-8afc-476c-a200-51fded30fdea@googlegroups.com> <mmu7vc$eak$1@dont-email.me> <47f5d704-4ab6-4afc-a558-cbed67915a76@googlegroups.com> <mmugvp$mpc$1@dont-email.me> <mn975d$44i$1@news.albasani.net>

Show all headers | View raw

On 04/07/2015 18:59, BGB wrote:
> On 6/30/2015 11:44 AM, Bartc wrote:

[Implementing variant types]
>> 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.

I've been overhauling my dynamic language and interpreter, initially to 
be a lot more Python-like, but have since rejected most new ideas (as I 
decided mine were better and yielded a faster interpreter!).

That including looking at using 64-bit references as the main way of 
moving data around. Both with scalars stored on the heap, and by means 
of bit-tagging within the pointers.

Ultimately I decided my old way was best, which is to use a composite 
(tag, value) object as the main way to push and pop data. On a 64-bit 
system, this is only double the size that's needed anyway (128-bits), 
but the advantages are:

* Full-size 64-bit int and float types
* No need do any bit-fiddling because the pointer and value are mixed up

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

* And, with 128-bits, there is space to store both the tag for the 
pointer, the type that it points to, and the pointer itself.

(In fact, on a 32-bit target, or on my 64-bit compiler with 32-bit 
pointers, I manage to store all the info I need for types such as 
strings and lists within the 128-bits. Obviously the string and list 
contents are at the other end of a pointer.)

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

I've also separated out all the type codes used for 'packed' types (all 
the ones you get in C), from those used within the variant system. So 
that the latter is more streamlined and far simpler.

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