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

Groups > comp.lang.c > #64522 > unrolled thread

"core C"

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

Contents

  "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

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

#64583

On Wednesday, July 1, 2015 at 6:46:13 AM UTC-4, Bart wrote:
> On 30/06/2015 18:04, Rick C. Hodgin wrote:
> > On Tuesday, June 30, 2015 at 12:45:08 PM UTC-4, Bart wrote:
> 
> >> 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?
> > Same size.
> 
> I'm curious: how can a pointer and offset together be the same size
> as a pointer?

I misunderstood you.  I thought you were asking about the size of
the pointer to the bit array.

Best regards,
Rick C. Hodgin

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

#64587

Bartc <bc@freeuk.com> writes:
> On 30/06/2015 18:04, Rick C. Hodgin wrote:
>> On Tuesday, June 30, 2015 at 12:45:08 PM UTC-4, Bart wrote:
>>> 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?
>>
>> Same size.
>
> I'm curious: how can a pointer and offset together be the same size as a 
> pointer?
>
> Or do all pointers have a spare 32-bit field on the off-chance they 
> might have to store an offset?

An example I've mentioned here many times: Cray vector machines are
word-oriented, where a word is 64 bits.  A machine-level address/pointer
is a 64-bit quantity containing the address of a word.  Cray's C
compiler has CHAR_BIT==8 (for Unix/POSIX compatibility), and implements
a byte pointer as a word pointer with the byte offset stored in the
otherwise unused high-order 3 bits.

Any system with 64-bit pointers that doesn't actually support 16
exabytes of memory is likely to be able to do something similar.

> (I also think that a normal byte-addressed pointer to a single value 
> ought to be the same size regardless of the type it points to. But it is 
> also reasonable that a bit pointer, bit-field pointer, slice, or 
> bit/bitfield slice might all need extra information and could therefore 
> be wider. You wouldn't then expect a void* type to accommodate all those 
> special forms too.)

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

#64590

On 01/07/2015 16:05, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:

>> I'm curious: how can a pointer and offset together be the same size as a
>> pointer?
>>
>> Or do all pointers have a spare 32-bit field on the off-chance they
>> might have to store an offset?
>
> An example I've mentioned here many times: Cray vector machines are
> word-oriented, where a word is 64 bits.  A machine-level address/pointer
> is a 64-bit quantity containing the address of a word.  Cray's C
> compiler has CHAR_BIT==8 (for Unix/POSIX compatibility), and implements
> a byte pointer as a word pointer with the byte offset stored in the
> otherwise unused high-order 3 bits.
>
> Any system with 64-bit pointers that doesn't actually support 16
> exabytes of memory is likely to be able to do something similar.

We're talking about offsets into an array which could be as big as 
available memory, and that's for a byte array. For a bit-array, the 
offset could be 8 times as big!

So it's not just a few extra bits.

With 32-bit pointers, there is nowhere to put a substantial offset. With 
64-bit ones, you might get away with it if pointers are limited to a 4GB 
range (2GB user and 2GB system), and offsets are limited to +2GB or +4GB 
(the latter being the maximum offset within a 500MB bit-array). And if 
the OS and everything else plays along.

Otherwise it gets tight. My point was that the natural way to do this 
was with a discrete pointer/offset pair that is larger (perhaps double 
the size) than a regular pointer. (With my preferred method of using bit 
pointers, then there's a better chance of storing the 0..7 bit offset in 
a spare corner of the pointer.)

-- 
Bartc

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

#64595

Bartc <bc@freeuk.com> writes:
> On 01/07/2015 16:05, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> I'm curious: how can a pointer and offset together be the same size as a
>>> pointer?
>>>
>>> Or do all pointers have a spare 32-bit field on the off-chance they
>>> might have to store an offset?
>>
>> An example I've mentioned here many times: Cray vector machines are
>> word-oriented, where a word is 64 bits.  A machine-level address/pointer
>> is a 64-bit quantity containing the address of a word.  Cray's C
>> compiler has CHAR_BIT==8 (for Unix/POSIX compatibility), and implements
>> a byte pointer as a word pointer with the byte offset stored in the
>> otherwise unused high-order 3 bits.
>>
>> Any system with 64-bit pointers that doesn't actually support 16
>> exabytes of memory is likely to be able to do something similar.
>
> We're talking about offsets into an array which could be as big as 
> available memory, and that's for a byte array. For a bit-array, the 
> offset could be 8 times as big!
>
> So it's not just a few extra bits.

Ok, I missed some of the context.

If the base pointer points to the word containing the data, then the
offset can be no bigger than 6 bits (assuming 64-bit pointers and 1-bit
elements).  If the base pointer points to the beginning of an array
object, and the offset can refer to any element of the array, then the
offset has to be a size_t or equivalent.

[...]

> Otherwise it gets tight. My point was that the natural way to do this 
> was with a discrete pointer/offset pair that is larger (perhaps double 
> the size) than a regular pointer. (With my preferred method of using bit 
> pointers, then there's a better chance of storing the 0..7 bit offset in 
> a spare corner of the pointer.)

It can vary a bit if the maximum size of an object is substantially
smaller than the total size of the memory space; then size_t can be
smaller than void*.  Of course monolithic address spaces are all the
rage these days.

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

#64669

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

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

#64673

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

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

#64679

On 7/4/2015 2:25 PM, Bartc wrote:
> 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
>

I had come from the opposite direction, originally mostly using 32-bit 
values with a mix of dynamic lookup, and parts of the address space used 
for literal values (had 28 bit fixnum and flonum).

the transition to 64-bit (in the BSVM) was mostly because it actually 
saved memory, due to significant reductions in the amount of boxing 
(outweighing the increased reference size), and similarly made things 
faster.

also partly it was because the BSVM was technically difficult to move 
entirely over to static types.

mostly-full-sized types was sufficient.
the main priorities at the time had been to unbox 'int' and 'double', 
and to these ends it has been successful.


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

but, 128 bits is a bit steep.
more so for a VM that is mostly still used on 32-bit hardware (a lot of 
it not particularly high-stat).

like, if your memory is measured in MB, there is still some need to be 
concerned with memory footprint.

this is partly why the BSVM wasn't being used (besides latency and code 
size), was that it had a memory footprint of around 150MB, which is 
pretty steep if used on a board with 256MB RAM. though, a lot of the 
memory use was due to how the FFI and metadata system worked.

luckily, the FRVM currently needs nowhere near this much memory (my CNC 
program running, with this VM in use, currently has a footprint of 
around 5MB).


then again, the tagged reference type isn't used all that prominently in 
FRVM (unlike in the BSVM).

currently in C-Aux, it isn't used at all.
in BS-RT, it is mostly (besides 'variant') likely to be used for 
'string', mostly because some tagging is needed to separate between 
various 'string' sub-types (they may be UTF-16, UTF-8, CP-1252, or CP-437).

basically, the BS-RT 'string' type is essentially a thinly veiled 
character pointer, relying on the type-tag to know what character set it 
is using.


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

these ones here are mostly to represent raw pointer types.
this type numbering is derived from what is used in the FRBC bytecode.

note that the same basic part of the tag space could likely also 
represent struct pointers.


both C-Aux and BS-RT use a C-like type-systems.

FWIW, core BS-RT types, their C-Aux equivalents:
	byte   , unsigned char      , 8-bit unsigned byte
	sbyte  , signed char        , 8-bit signed byte
	short  , short              , 16-bit signed short
	ushort , unsigned short     , 16-bit unsigned short
	int    , int                , 32-bit signed integer
	uint   , unsigned int       , 32-bit unsigned integer
	long   , long long          , 64-bit signed integer
	ulong  , unsigned long long , 64-bit unsigned integer
	nlong  , long               , 32/64-bit signed integer
	unlong , unsigned long      , 32/64-bit unsigned integer
         char   , wchar_t            , 16-bit character
         float  , float              , 32-bit float
         double , double             , 64-bit double

both make use of structs, pointers, and pointer arithmetic.

in BS-RT, the dynamic type-system will exist partly as an extension of 
the static type-system, rather than as a separate system. both languages 
will be primarily statically-typed.

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

#64540

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
>> On 30/06/2015 12:27, Rick C. Hodgin wrote:
<snip>
>> > #12 Two new arbitrary size variable type are introduced:  bi, bfp
>> >     (bi=big integer, bfp=big floating point)
>> 
>> Not exactly part of a core language. You would expect a core language to 
>> implement features like this.
>
> Would or wouldn't expect a core language to implement a feature like
> this?  Core C defines it.

I think BartC means that truly "core" language -- one that's widely
implemented and can be used to write fast, portable code (a bit C, for
example), would be used to provide such features for languages like RDC
(and Haskell and Python and so on).

Interesting that you don't have a br type (big rational), and whist I
find the topic of bfp very interesting, I am guessing you don't know
what you mean by it yet.

<snip>
-- 
Ben.

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

#64537

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> We can define Core C here if you'd like. :-)  I appoint myself chair,
> and the rest of us a "committee of the whole" to address the issue.
>
> #1 Little endian.
> #2 Two's complement.
> #3 All pointers are the same size per target.
> #4 All memory is executable.
> #5 All memory is read/write unless explicitly flagged as read-only.
> #6 No default support for char, short, int, long, long long, etc.,
>    but these keywords are reserved for use with typedef or #define
>    statements to map to the appropriate target for the machine.
> #7 Signed variable types:  s8, s16, s32, s64
> #8 Unsigned variable types:  u8, u16, u32, u64
> #9 Floating point types all IEEE 754-2008 compliant:  f32, f64

This is, basically, C on an Intel chip.  My guess is that all the other
parts of the C standard that you've left undefined or implementation
defined are just parts you don't yet know about.  Would it be fair to
assume that everywhere the C standard does not mandate the behaviour you
are used to, you will just go on adding #3a, #3b, #7a etc. until it's
all pinned down to match your parochial expectations?

> #10 A new "flag" variable type is introduced which is 1-bit,
>     assigned with yes/true/up and no/false/down keywords.
> #11 A new "bits" variable is introduce which is n-bits, where:
>     1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
>     checked on use with inquiries being thrown (see #16 below).
> #12 Two new arbitrary size variable type are introduced:  bi, bfp
>    (bi=big integer, bfp=big floating point)
> #13 A new weakly typed variable type is introduced:  var
> #14 The basic class is introduced.
> #15 The concept of edit-and-continue compilation is mandatory.
> #16 A new exception framework is introduced based on inquiries
>     rather than errors.  These allow the machine to suspend for
>     edit-and-continue guidance when an "error" condition arises,
>     which will now be called an "inquiry" condition.
> #17 Flow control blocks are introduced.
> #18 Adhoc functions are introduced.
> #19 The #marker is introduced (for named return destinations, as in:
>     returnto markerName).
> #20 The cask is introduced allowing for arbitrary code injection,
>     and calling protocols on logical tests to meta (true) and
>     mefa (false), as well as message passing using mema.
> #21 A new self-documenting protocol is introduced, which allows
>     the software to be documented in source code (similar to Java's).
> #22 A new metadata set of tags is made available on a line-by-line
>     basis, or at the function / struct level.  These explicitly
>     tag source code lines to be of a particular type, making a new
>     type of search and/or replace possible (such as /* md: a, b, c */).
> #23 All standard libraries are available and #include'd by default.
>     They must be explicitly excluded if they are not needed.
> #24 All functions are linked to (1) a bare minimum for standard
>     libraries, (2) all are included for developer code; unless
>     otherwise directed by compiler/linker flags.

So "core C" is a new language, surprising like your pet language -- the
one you've not yet been able to specify or implement?  That not a good
name for something the much bigger than C.  I would wholly support your
plan if you picked another name for it like, like... I don't
know... RDC, perhaps?

<snip>
-- 
Ben.

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

#64539

On Tuesday, June 30, 2015 at 9:03:11 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > We can define Core C here if you'd like. :-)  I appoint myself chair,
> > and the rest of us a "committee of the whole" to address the issue.
> >
> > #1 Little endian.
> > #2 Two's complement.
> > #3 All pointers are the same size per target.
> > #4 All memory is executable.
> > #5 All memory is read/write unless explicitly flagged as read-only.
> > #6 No default support for char, short, int, long, long long, etc.,
> >    but these keywords are reserved for use with typedef or #define
> >    statements to map to the appropriate target for the machine.
> > #7 Signed variable types:  s8, s16, s32, s64
> > #8 Unsigned variable types:  u8, u16, u32, u64
> > #9 Floating point types all IEEE 754-2008 compliant:  f32, f64
> 
> This is, basically, C on an Intel chip.  My guess is that all the other
> parts of the C standard that you've left undefined or implementation
> defined are just parts you don't yet know about.  Would it be fair to
> assume that everywhere the C standard does not mandate the behaviour you
> are used to, you will just go on adding #3a, #3b, #7a etc. until it's
> all pinned down to match your parochial expectations?
> 
> > #10 A new "flag" variable type is introduced which is 1-bit,
> >     assigned with yes/true/up and no/false/down keywords.
> > #11 A new "bits" variable is introduce which is n-bits, where:
> >     1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
> >     checked on use with inquiries being thrown (see #16 below).
> > #12 Two new arbitrary size variable type are introduced:  bi, bfp
> >    (bi=big integer, bfp=big floating point)
> > #13 A new weakly typed variable type is introduced:  var
> > #14 The basic class is introduced.
> > #15 The concept of edit-and-continue compilation is mandatory.
> > #16 A new exception framework is introduced based on inquiries
> >     rather than errors.  These allow the machine to suspend for
> >     edit-and-continue guidance when an "error" condition arises,
> >     which will now be called an "inquiry" condition.
> > #17 Flow control blocks are introduced.
> > #18 Adhoc functions are introduced.
> > #19 The #marker is introduced (for named return destinations, as in:
> >     returnto markerName).
> > #20 The cask is introduced allowing for arbitrary code injection,
> >     and calling protocols on logical tests to meta (true) and
> >     mefa (false), as well as message passing using mema.
> > #21 A new self-documenting protocol is introduced, which allows
> >     the software to be documented in source code (similar to Java's).
> > #22 A new metadata set of tags is made available on a line-by-line
> >     basis, or at the function / struct level.  These explicitly
> >     tag source code lines to be of a particular type, making a new
> >     type of search and/or replace possible (such as /* md: a, b, c */).
> > #23 All standard libraries are available and #include'd by default.
> >     They must be explicitly excluded if they are not needed.
> > #24 All functions are linked to (1) a bare minimum for standard
> >     libraries, (2) all are included for developer code; unless
> >     otherwise directed by compiler/linker flags.
> 
> So "core C" is a new language, surprising like your pet language -- the
> one you've not yet been able to specify or implement?  That not a good
> name for something the much bigger than C.  I would wholly support your
> plan if you picked another name for it like, like... I don't
> know... RDC, perhaps?
> 
> <snip>
> -- 
> Ben.

I think you're quite solidly in the "before" camp, Ben.  So, I'll just
leave that there. :-)

Best regards,
Rick C. Hodgin

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

#64543

On 30/06/15 13:27, Rick C. Hodgin wrote:
> We can define Core C here if you'd like. :-)  I appoint myself chair,
> and the rest of us a "committee of the whole" to address the issue.

That would be the "royal we"?  This is entirely /your/ thoughts on a
language.  Others (like me) might comment, but don't pretend that any
one other than /you/ thinks this is a useful idea in practice.

However, it can always be fun to think about what would make up a
"perfect" C language, from an almost entirely subjective viewpoint.

> 
> #1 Little endian.

There are far too many big endian systems around for this to be defined
as "core".  I'd be happy to say it should support big endian and little
endian systems, but not mixed endian systems.

More usefully, I would like to see type/variable qualifiers for
specifying endianness, which would eliminate all issues that different
endianness causes today (e.g., when specifying a binary file format, you
would explicitly give the endianness of the fields).

The bit-endianness (order of bitfields) would also need to be specified.

> #2 Two's complement.

I'm OK with that.

> #3 All pointers are the same size per target.

I don't see the point of this restriction, and it would cause limitation
on real-world microcontrollers.

> #4 All memory is executable.

Nope - that's a terrible idea.  C does not currently distinguish between
types of memory (code, data, bss and stack sections are all
implementation details, not part of the standards).  But if you want to
make memory areas part of "Core C", then you definitely want
restrictions on executable parts.

And for many real-world microcontrollers, only some of the memory can be
executable.  If "Core C" is to have a point, it must be suitable for a
range of "normal" systems, even if it excludes odd or outdated systems.

> #5 All memory is read/write unless explicitly flagged as read-only.

Again, that's a terrible idea.  And it would not work on
microcontrollers, which have read-only memory regardless of what the
user might try to do with flagging.

> #6 No default support for char, short, int, long, long long, etc.,
>    but these keywords are reserved for use with typedef or #define
>    statements to map to the appropriate target for the machine.

That's going to upset a lot of people...

> #7 Signed variable types:  s8, s16, s32, s64

No, these are called int8_t, int16_t, int32_t and int64_t.  Don't change
these to non-standard names that could easily be mixed up, just to save
a couple of keystrokes.

> #8 Unsigned variable types:  u8, u16, u32, u64

Again, these are uint8_t, uint16_t, uint32_t and uint64_t.

Note that some systems (in particular, some DSP's) have minimum 16-bit
or 32-bit accesses.  I'm okay with these not being fully compatible with
"Core C", but you need to be aware of them.

> #9 Floating point types all IEEE 754-2008 compliant:  f32, f64

That would be float32_t and float64_t.

> #10 A new "flag" variable type is introduced which is 1-bit,
>     assigned with yes/true/up and no/false/down keywords.

That would be "bool", with "true" and "false" values.  It would be fine
to make those keywords (just like in C++), and save #include'ing <stdbool.h>

> #11 A new "bits" variable is introduce which is n-bits, where:
>     1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
>     checked on use with inquiries being thrown (see #16 below).

That is not in the spirit of C - and certainly not in a "Core C".

> #12 Two new arbitrary size variable type are introduced:  bi, bfp
>    (bi=big integer, bfp=big floating point)

That is not in the spirit of C - and certainly not in a "Core C".

> #13 A new weakly typed variable type is introduced:  var

That is not in the spirit of C - and certainly not in a "Core C".

> #14 The basic class is introduced.

That is not in the spirit of C - and certainly not in a "Core C".

If you want to invent a language that is half-way towards C++, and call
it "Core C+", that's fine - but it's a different language.

> #15 The concept of edit-and-continue compilation is mandatory.

That has no place in a language.  Even though you like
edit-and-continue, you must surely see that!

> #16 A new exception framework is introduced based on inquiries
>     rather than errors.  These allow the machine to suspend for
>     edit-and-continue guidance when an "error" condition arises,
>     which will now be called an "inquiry" condition.

That is not in the spirit of C - and certainly not in a "Core C".

> #17 Flow control blocks are introduced.

C already has plenty of flow control keywords - it doesn't need any more.

> #18 Adhoc functions are introduced.

I'd be fine with local nested functions - but call them local functions
or nested functions, since that is what they are.  "Adhoc" means
something completely different from the way you use it (look the word up
in a dictionary).

> #19 The #marker is introduced (for named return destinations, as in:
>     returnto markerName).

Nope.

> #20 The cask is introduced allowing for arbitrary code injection,
>     and calling protocols on logical tests to meta (true) and
>     mefa (false), as well as message passing using mema.

Nope.

"casks" have no place in C of any sort, "core" or otherwise.  They may
be part of RDC, but that's because RDC is a different sort of language.

> #21 A new self-documenting protocol is introduced, which allows
>     the software to be documented in source code (similar to Java's).

doxygen already exists, and is very popular.  You can't mandate
documentation as part of a programming language.

> #22 A new metadata set of tags is made available on a line-by-line
>     basis, or at the function / struct level.  These explicitly
>     tag source code lines to be of a particular type, making a new
>     type of search and/or replace possible (such as /* md: a, b, c */).

That makes almost no sense at all - and if it is nothing more than an
attempt to standardise comments, then forget it.  Comments are entirely
at the discretion of the programmer - that's the nature of comments.

> #23 All standard libraries are available and #include'd by default.
>     They must be explicitly excluded if they are not needed.

Nope, bad idea - polluting the namespace and making compilation far
slower and more complicated.  I would have nothing against a bit of
restructuring, simplifying, and improving the standard library - but it
should not be included automatically.

> #24 All functions are linked to (1) a bare minimum for standard
>     libraries, (2) all are included for developer code; unless
>     otherwise directed by compiler/linker flags.
> 

Terrible idea.

> An incomplete list.  I'll add more as I think of them.  Please feel
> free to comment or propose.
> 
> Best regards,
> Rick C. Hodgin
> 

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

#64548

On Tuesday, June 30, 2015 at 9:47:07 AM UTC-4, David Brown wrote:
> [snip]

I am considering your post.  Give me some time.

Best regards,
Rick C. Hodgin

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

#64643

On Tue, Jun 30, 2015 at 03:46:58PM +0200, David Brown wrote:
> On 30/06/15 13:27, Rick C. Hodgin wrote:
> > We can define Core C here if you'd like. :-)  I appoint myself chair,
> > and the rest of us a "committee of the whole" to address the issue.
> 
> That would be the "royal we"?  This is entirely /your/ thoughts on a
> language.  Others (like me) might comment, but don't pretend that any
> one other than /you/ thinks this is a useful idea in practice.
> 
> However, it can always be fun to think about what would make up a
> "perfect" C language, from an almost entirely subjective viewpoint.

It must be a coincidence that his "Core C" feature enumeration has a
close correspondence with several of the features I am putting in my
VM project.  It must be the nature of the beast; C-derived systems
will tend to be similar, right?  At any rate, my thing is a research
project and not something I am worried about promoting on Usenet.
 
> > 
> > #1 Little endian.
> 
> There are far too many big endian systems around for this to be defined
> as "core".  I'd be happy to say it should support big endian and little
> endian systems, but not mixed endian systems.
> 
> More usefully, I would like to see type/variable qualifiers for
> specifying endianness, which would eliminate all issues that different
> endianness causes today (e.g., when specifying a binary file format, you
> would explicitly give the endianness of the fields).
> 
> The bit-endianness (order of bitfields) would also need to be specified.

That's a pretty good idea.  If you had a CPU instruction to byteswap
16-64 bit words it would be easy to implement.
 
> > #2 Two's complement.
> 
> I'm OK with that.
> 
> > #3 All pointers are the same size per target.
> 
> I don't see the point of this restriction, and it would cause limitation
> on real-world microcontrollers.

Doesn't really make sense with some of his criterion.
 
> > #4 All memory is executable.
> 
> Nope - that's a terrible idea.  C does not currently distinguish between
> types of memory (code, data, bss and stack sections are all
> implementation details, not part of the standards).  But if you want to
> make memory areas part of "Core C", then you definitely want
> restrictions on executable parts.
> 
> And for many real-world microcontrollers, only some of the memory can be
> executable.  If "Core C" is to have a point, it must be suitable for a
> range of "normal" systems, even if it excludes odd or outdated systems.
> 
> > #5 All memory is read/write unless explicitly flagged as read-only.
> 
> Again, that's a terrible idea.  And it would not work on
> microcontrollers, which have read-only memory regardless of what the
> user might try to do with flagging.

His "core C" is not going to work where there is no hardware memeory
protection.

> > #6 No default support for char, short, int, long, long long, etc.,
> >    but these keywords are reserved for use with typedef or #define
> >    statements to map to the appropriate target for the machine.
> 
> That's going to upset a lot of people...
> 
> > #7 Signed variable types:  s8, s16, s32, s64
> 
> No, these are called int8_t, int16_t, int32_t and int64_t.  Don't change
> these to non-standard names that could easily be mixed up, just to save
> a couple of keystrokes.
> 
> > #8 Unsigned variable types:  u8, u16, u32, u64
> 
> Again, these are uint8_t, uint16_t, uint32_t and uint64_t.

These types should have been defined way back when C was an unruly
teenager and used then instead of char, int, etc.

How much trouble has the indeterminate range of int types caused when
porting code?



Regards,

Steve Thompson

-- 
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden."  -- MysteryDog in 24hoursupport.helpdesk.

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

#64586

Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> We can define Core C here if you'd like. :-)  I appoint myself chair,
> and the rest of us a "committee of the whole" to address the issue.

> #1 Little endian.
> #2 Two's complement.
> #3 All pointers are the same size per target.
> #4 All memory is executable.
> #5 All memory is read/write unless explicitly flagged as read-only.
> #6 No default support for char, short, int, long, long long, etc.,
>    but these keywords are reserved for use with typedef or #define
>    statements to map to the appropriate target for the machine.
> #7 Signed variable types:  s8, s16, s32, s64
> #8 Unsigned variable types:  u8, u16, u32, u64
> #9 Floating point types all IEEE 754-2008 compliant:  f32, f64
> #10 A new "flag" variable type is introduced which is 1-bit,
>     assigned with yes/true/up and no/false/down keywords.
> #11 A new "bits" variable is introduce which is n-bits, where:
>     1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
>     checked on use with inquiries being thrown (see #16 below).
> #12 Two new arbitrary size variable type are introduced:  bi, bfp
>    (bi=big integer, bfp=big floating point)
> #13 A new weakly typed variable type is introduced:  var
> #14 The basic class is introduced.
> #15 The concept of edit-and-continue compilation is mandatory.
> #16 A new exception framework is introduced based on inquiries
>     rather than errors.  These allow the machine to suspend for
>     edit-and-continue guidance when an "error" condition arises,
>     which will now be called an "inquiry" condition.
> #17 Flow control blocks are introduced.
> #18 Adhoc functions are introduced.
> #19 The #marker is introduced (for named return destinations, as in:
>     returnto markerName).
> #20 The cask is introduced allowing for arbitrary code injection,
>     and calling protocols on logical tests to meta (true) and
>     mefa (false), as well as message passing using mema.
> #21 A new self-documenting protocol is introduced, which allows
>     the software to be documented in source code (similar to Java's).
> #22 A new metadata set of tags is made available on a line-by-line
>     basis, or at the function / struct level.  These explicitly
>     tag source code lines to be of a particular type, making a new
>     type of search and/or replace possible (such as /* md: a, b, c */).
> #23 All standard libraries are available and #include'd by default.
>     They must be explicitly excluded if they are not needed.
> #24 All functions are linked to (1) a bare minimum for standard
>     libraries, (2) all are included for developer code; unless
>     otherwise directed by compiler/linker flags.

All this can't be done without an interpreter or a kind of VM,
in which the program is run. With this you're throwing every-
thing out of the window what has made C such a success. And
that is that you can do bare-metal programming at nearly the
fastest possible speed - for which C has been called, not
too far off the mark, a "portable assembler:. With an inter-
preter or a VM it's impossible to use it for writing opera-
ting systems or using it as the implementation language for
higher-level languages. So, what you propose here is a new
language with a C-like syntax, but without any of the funda-
mental benefits of C. And such languages are a dime for the
dozend.

And with such a language all these points about endianess,
numbers of bits in variables, pointer sizes become mostly
irrelevant. These aren't language properties but are deter-
minded by the hardware the program is running on. They all
become implementation details the author of the interpreter/
VM has to care about, but which the user of the language has
no reason to care (or even to know) about - the interpreter/
VM has to somehow map the variables of that language to the
real hardware (or it is impossible to implement it on any
hardware that doesn't exactly fits your model).

And when you start designing a new language then you really
should look a lot further than just reproducing the syntax
of C with a few new bits added while giving up all what makes
C the lingua franca of computing. There's, for example, no
discernable reason why you're so fixated on integer vari-
ables with sizes of 8 bits and multiples of that. In C there
is a reason: it's often the "natural" size of the underlying
hardware. But for something that runs in an interpreter/VM
this is rather unimportant. Since you wil have to check each
and every calculation with such variables for over- and
underflows anyway, why not start with a fresh appproach
(but not new, e.g. ADA does that since a long time)  and
have variables with e.g. user-defined ranges? So, if the
problem requires it, I can define a variable that can only
hold values between, say, -17 and 541? Since you already
have thrown out the speed advantage of C the tiny bit of
extra checking this would require won't make any major dif-
ference. And it might help writing much more secure programs
since all the checking the user has to do himself in C (but
too often forgets) are done automatically.

On the other hand, if the user doesn't know in advance whar
range he's going to need, why not make the variables adapt
themselves to what's needed? You'll have to check each assign-
ment to a variable anyway, so if the new value does not fit
anymore into an int32_t why not transparently upgrade it into
an int64_t (or your 'bi' type)?

Anything this "Core C" as stated will have to do with C (except
some similarities in the syntax) will be that the interpreter/VM
will need to be written in C or C++. (or some other languange
that probably is itself implemented in C if you don't mind to
run your interpreter/VM in another interpreter/VM;-). But it
won't be of any real interest to anyone if it hasn't any fea-
tures that make it a lot better than C when it just runs a lot
slower and doesn't allow you to do most things C typically is
used for.
                           Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#64588

On Wednesday, July 1, 2015 at 11:04:41 AM UTC-4, Jens Thoms Toerring wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> > We can define Core C here if you'd like. :-)  I appoint myself chair,
> > and the rest of us a "committee of the whole" to address the issue.
> 
> > #1 Little endian.
> > #2 Two's complement.
> > #3 All pointers are the same size per target.
> > #4 All memory is executable.
> > #5 All memory is read/write unless explicitly flagged as read-only.
> > #6 No default support for char, short, int, long, long long, etc.,
> >    but these keywords are reserved for use with typedef or #define
> >    statements to map to the appropriate target for the machine.
> > #7 Signed variable types:  s8, s16, s32, s64
> > #8 Unsigned variable types:  u8, u16, u32, u64
> > #9 Floating point types all IEEE 754-2008 compliant:  f32, f64
> > #10 A new "flag" variable type is introduced which is 1-bit,
> >     assigned with yes/true/up and no/false/down keywords.
> > #11 A new "bits" variable is introduce which is n-bits, where:
> >     1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
> >     checked on use with inquiries being thrown (see #16 below).
> > #12 Two new arbitrary size variable type are introduced:  bi, bfp
> >    (bi=big integer, bfp=big floating point)
> > #13 A new weakly typed variable type is introduced:  var
> > #14 The basic class is introduced.
> > #15 The concept of edit-and-continue compilation is mandatory.
> > #16 A new exception framework is introduced based on inquiries
> >     rather than errors.  These allow the machine to suspend for
> >     edit-and-continue guidance when an "error" condition arises,
> >     which will now be called an "inquiry" condition.
> > #17 Flow control blocks are introduced.
> > #18 Adhoc functions are introduced.
> > #19 The #marker is introduced (for named return destinations, as in:
> >     returnto markerName).
> > #20 The cask is introduced allowing for arbitrary code injection,
> >     and calling protocols on logical tests to meta (true) and
> >     mefa (false), as well as message passing using mema.
> > #21 A new self-documenting protocol is introduced, which allows
> >     the software to be documented in source code (similar to Java's).
> > #22 A new metadata set of tags is made available on a line-by-line
> >     basis, or at the function / struct level.  These explicitly
> >     tag source code lines to be of a particular type, making a new
> >     type of search and/or replace possible (such as /* md: a, b, c */).
> > #23 All standard libraries are available and #include'd by default.
> >     They must be explicitly excluded if they are not needed.
> > #24 All functions are linked to (1) a bare minimum for standard
> >     libraries, (2) all are included for developer code; unless
> >     otherwise directed by compiler/linker flags.
> 
> All this can't be done without an interpreter or a kind of VM,
> in which the program is run. With this you're throwing every-
> thing out of the window what has made C such a success. And
> that is that you can do bare-metal programming at nearly the
> fastest possible speed - for which C has been called, not
> too far off the mark, a "portable assembler:. With an inter-
> preter or a VM it's impossible to use it for writing opera-
> ting systems or using it as the implementation language for
> higher-level languages. So, what you propose here is a new
> language with a C-like syntax, but without any of the funda-
> mental benefits of C. And such languages are a dime for the
> dozend.
> 
> And with such a language all these points about endianess,
> numbers of bits in variables, pointer sizes become mostly
> irrelevant. These aren't language properties but are deter-
> minded by the hardware the program is running on. They all
> become implementation details the author of the interpreter/
> VM has to care about, but which the user of the language has
> no reason to care (or even to know) about - the interpreter/
> VM has to somehow map the variables of that language to the
> real hardware (or it is impossible to implement it on any
> hardware that doesn't exactly fits your model).
> 
> And when you start designing a new language then you really
> should look a lot further than just reproducing the syntax
> of C with a few new bits added while giving up all what makes
> C the lingua franca of computing. There's, for example, no
> discernable reason why you're so fixated on integer vari-
> ables with sizes of 8 bits and multiples of that. In C there
> is a reason: it's often the "natural" size of the underlying
> hardware. But for something that runs in an interpreter/VM
> this is rather unimportant. Since you wil have to check each
> and every calculation with such variables for over- and
> underflows anyway, why not start with a fresh appproach
> (but not new, e.g. ADA does that since a long time)  and
> have variables with e.g. user-defined ranges? So, if the
> problem requires it, I can define a variable that can only
> hold values between, say, -17 and 541? Since you already
> have thrown out the speed advantage of C the tiny bit of
> extra checking this would require won't make any major dif-
> ference. And it might help writing much more secure programs
> since all the checking the user has to do himself in C (but
> too often forgets) are done automatically.
> 
> On the other hand, if the user doesn't know in advance whar
> range he's going to need, why not make the variables adapt
> themselves to what's needed?

RDC allows this to be done using casks in the definition.  You
can set casks which look at min's and/or max's and then call
the appropriate function if violated, which presumably corrects
the value.

> You'll have to check each assign-
> ment to a variable anyway, so if the new value does not fit
> anymore into an int32_t why not transparently upgrade it into
> an int64_t (or your 'bi' type)?

I had set up some rules for this, and had capped them at 64-bits.
They could upgrade to a bi, however.

> Anything this "Core C" as stated will have to do with C (except
> some similarities in the syntax) will be that the interpreter/VM
> will need to be written in C or C++. (or some other languange
> that probably is itself implemented in C if you don't mind to
> run your interpreter/VM in another interpreter/VM;-). But it
> won't be of any real interest to anyone if it hasn't any fea-
> tures that make it a lot better than C when it just runs a lot
> slower and doesn't allow you to do most things C typically is
> used for.
>                            Regards, Jens
> -- 
>   \   Jens Thoms Toerring  ___      jt@toerring.de
>    \__________________________      http://toerring.de

I appreciate your well thought out input, Jens.  Thank you.

Best regards,
Rick C. Hodgin

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

#64663

On 6/30/2015 6:27 AM, Rick C. Hodgin wrote:
> We can define Core C here if you'd like. :-)  I appoint myself chair,
> and the rest of us a "committee of the whole" to address the issue.
>

late to this party, but.
may compare with my own C-Aux language variant and similar where relevant.


> #1 Little endian.

possible, but limits range of target.
C-Aux supports either endianess, but it is nominally left as runtime issue.

default is little-endian though, for cases where the choice is nearly 
equal weight. in a way it is ironic though that the VM's compiled image 
format is big-endian (it reused the TLV format from some of my other 
efforts, which was big-endian, so everything else was done this way in 
the format for consistency).


> #2 Two's complement.

sane.


> #3 All pointers are the same size per target.

probably sane.


> #4 All memory is executable.

probably a bad idea in general.

internally, the VM used by C-Aux essentially treats executable code and 
normal memory differently. potentially, you could produce bytecode and 
shove it into the VM, but this is outside its current use-case.


> #5 All memory is read/write unless explicitly flagged as read-only.

depends.

some of my past VMs have actually used a Unix-like security model (RWX 
and UID/GID) for memory access, enforced by the VM (similar to file 
access). with some trickery, I was able to basically make a lot of the 
access-rights checking cacheable.

the premise was that ideally VM code could be sandboxed, and thus kept 
mostly safe.

this mostly ended up unused as it is a bit much code overhead (it 
required a lot of boilerplate in declarations).


the VM used by C-Aux currently just exposes raw memory, with it 
basically using OS/hardware level access protections. but, this is 
itself mostly about current use-case, and may be different for other 
use-cases.

a simpler model is just splitting code into two levels, such as 
'trusted' and 'untrusted', and restricting what is accessible from 
untrusted code.


> #6 No default support for char, short, int, long, long long, etc.,
>     but these keywords are reserved for use with typedef or #define
>     statements to map to the appropriate target for the machine.

probably not viable.


> #7 Signed variable types:  s8, s16, s32, s64
> #8 Unsigned variable types:  u8, u16, u32, u64

can be done, but another option is making the normal types fixed size by 
default.

for example, in C-Aux:
   char, signed 8 bit;
   short, signed 16-bit;
   int, signed 32-bit;
   long long, signed 64-bit.

some remained variable:
   long, 32 or 64 depending on target.
     internally defaults to 64-bit treatment in the VM.
     technically, it is similar to 'short' (which internally uses 'int').
       it is a type/converting load/store hack.
     internally to the VM, and in my 'BS-RT' language,
       this type is called 'native long'.
     in the VM, 'long' actually refers to 'long long'.
   pointers:
     32 or 64 bit, depending on target.

the VM leaves off support for 16-bit targets, as pretty much all the 
current 16-bit targets still in active use (typically small 
microcontrollers) have too little RAM to make such a VM viable.

like, probably sane to at least require a higher-end 32-bit microcontroller.

other type names:
   __int8_t, alias to char
   __int16_t, alias to short
   __int32_t, alias to int
   __int64_t, alias to long long
   __int128_t, special, non-core type.

core types and non-core types get different treatment from the VM:
   core types have assigned bit-patterns and operators in the bytecode:
     the bytecode mostly uses an ILFDA model similar to the JVM.
     some other types are core by having short bit-codes.
   non-core types generally use operations which depend on signatures.
     this includes most extended types, as well as structures.
   current core uses a 4-bit type-code.
     possible could be to create an "extended core" with 8-bit type-IDs.


> #9 Floating point types all IEEE 754-2008 compliant:  f32, f64

mostly sane.

C-Aux and its VM define:
   short float, 16-bit IEEE half-float.
     like short, it is mostly a load/store hack.
     non-core type.
   float, 32-bit IEEE float.
   double, 64-bit IEEE double.
   long double, mostly an alias for double.
     internally, the VM does not distinguish them.
   __float128_t, non-core, 128-bit float.


> #10 A new "flag" variable type is introduced which is 1-bit,
>      assigned with yes/true/up and no/false/down keywords.
> #11 A new "bits" variable is introduce which is n-bits, where:
>      1 <= n <= 7.  Defined as "bits:2" for a 2-bit width, range-
>      checked on use with inquiries being thrown (see #16 below).

could just make bitfields not suck (such as by better nailing down their 
behavior).


> #12 Two new arbitrary size variable type are introduced:  bi, bfp
>     (bi=big integer, bfp=big floating point)

possible, but these sorts of things are difficult to support with much 
of any real semblance of efficiency (the added complexity of dealing 
with the variable size tends to outweigh any gains).

hence, why large fixed-size types tend to be a more popular option.

this includes things like 2048-bit packed decimal types and similar.


> #13 A new weakly typed variable type is introduced:  var

similar has been considered for C-Aux, but it is more likely to be fully 
dynamically typed (weak typing and dynamic typing are different), and 
partly as a side-effect from both C-Aux and BS-RT sharing the same VM.

in the current VM, it is a 64-bit tagged reference type, generally with 
the type of the pointed-to object squirreled in the reference:
   on 32-bit targets, there were 28 bits left over;
   on current 64 bit targets, about 12 (Linux) or 16 (Win64).

currently, it uses 12 bits for the type-tag, with any remaining bits 
reserved. future-proofing? dunno...

a challenge though is supporting these types (and also dynamic objects) 
in the VM without risking screwing up timing constraints. as-is, there 
are some limits to the type-system to try to keep the timing for 
everything bounded and reasonably predictable.



there is may also be an 'auto' type, which uses type inference.

ex:
   auto x=3LL; //x is implicitly long long
   auto y=x; //y is also implicitly long long

my past language ('BS') had used 'var' for both cases, but BS-RT and 
C-Aux would likely have separate dynamically-typed and type-inferred 
variables.


> #14 The basic class is introduced.

I decided against this for C-Aux.

there may or not (eventually) be a C+Aux which does classes (and is 
probably a lazy mimic of C++ syntax).



> #15 The concept of edit-and-continue compilation is mandatory.

not viable in my case.

the VM is mostly intended for controllers for my robotics projects, and 
it is generally easier to use generic tools (text editors), and some 
offline simulation.

granted, the simulators don't really show what actual hardware will do.
something like a 3D and maybe physics-based simulator could be useful, 
but the effort of making such a thing would likely not outweigh the 
effort it would require to make it.

like, it isn't too difficult to render or animate an action, but 
realistic simulation of things like motors and mechanics is non-trivial.

IRL also has all this fun, like stuff not sliding for crap because the 
rails aren't quite perfectly parallel (like, they diverge by a small 
fraction of an inch along their length, causing things to stick when 
sliding along them), ...

well, and also real-world fun like motors getting burnt up because IO 
pins get stuck on (... rewinding motors is fun ...).


also cats help, like one can use a PC or laptop for controlling 
something (dealing with the controller), and cats will hop up and do a 
little dance all over the keyboard, fouling things up or sending the 
computer into hibernate or whatever, then one has a mess.


> #16 A new exception framework is introduced based on inquiries
>      rather than errors.  These allow the machine to suspend for
>      edit-and-continue guidance when an "error" condition arises,
>      which will now be called an "inquiry" condition.

typically one would glue on some variant of try/catch.


> #17 Flow control blocks are introduced.
> #18 Adhoc functions are introduced.

ok.


currently no plans for this personally in C-Aux, but they will exist in 
BS-RT.

possible syntax choices (if added to C-Aux):
   carrot:
     ^ { ... }
     ^(args)->rtype { ... }
   bracket:
     [](args)->rtype { ... }
   keyword:
     __function rtype(args) { ... }


slightly uncertain is whether or not a call/cc type mechanism should 
exist (AKA: "call with current continuation"). these allow basically 
having more explicit control over control flow.

as-is, nothing like this is supported (and is generally not often useful 
enough to justify the added complexity of supporting it).


> #19 The #marker is introduced (for named return destinations, as in:
>      returnto markerName).

... hmm ...


> #20 The cask is introduced allowing for arbitrary code injection,
>      and calling protocols on logical tests to meta (true) and
>      mefa (false), as well as message passing using mema.

?


> #21 A new self-documenting protocol is introduced, which allows
>      the software to be documented in source code (similar to Java's).
sort of lazily-done already.


> #22 A new metadata set of tags is made available on a line-by-line
>      basis, or at the function / struct level.  These explicitly
>      tag source code lines to be of a particular type, making a new
>      type of search and/or replace possible (such as /* md: a, b, c */).
> #23 All standard libraries are available and #include'd by default.
>      They must be explicitly excluded if they are not needed.

why?...


> #24 All functions are linked to (1) a bare minimum for standard
>      libraries, (2) all are included for developer code; unless
>      otherwise directed by compiler/linker flags.

some OS libraries and the C runtime tend to be included by default in 
most compilers anyways.

for non-hosted code, you explicitly don't have or can't use libraries.

>
> An incomplete list.  I'll add more as I think of them.  Please feel
> free to comment or propose.
>
> Best regards,
> Rick C. Hodgin
>

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

#64529

The thing we're creating is called "Core C" and the body responsible
for it will be the "Core C Group".

Core C will be comprised of:

    (1) The Core C language definition.
    (2) The Core C known extensions definition.
    (3) The Core C guide for adding unknown extensions.
    (4) The Core C compiler.
    (5) The Core C debugger.
    (6) The Core C editor and/or IDE.
    (7) The Core C virtual machine.

-----
The Core C compiler will implement all Core C features.  It will be
designed to run on the Core C virtual machine, but written in a way
that allows immediate recompilation onto native hardware (for
generating code which runs on the virtual machine), with a well-
documented front-end, middle, and back-end for support of other
languages, and other hardware.

The Core C virtual machine will be comprised of a very thin machine
with opcodes sufficient to represent a virtual CPU that is easily
mapped onto x86-64 and ARM hardware in emulation.  The Core C virtual
machine will implement a JIT compiler to translate VM opcodes into
native machine opcodes at load-time.

The Core C debugger and editor and/or IDE will be designed to run on
the virtual machine, and will help define the VM's API for OS/host
services.

The Core C language definition will include a list of known
extensions or allowances, such as allowing big-endian, one's
complement, pointers of various sizes, and these will be given
a definition on use.

A guide will also be given on how to implement things that are not
known to Core C, so they can still be added "within the definition."

Best regards,
Rick C. Hodgin

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

#64541

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> The thing we're creating is called "Core C" and the body responsible
> for it will be the "Core C Group".

I think you misspoke.  You are trying to define your language RDC and
since you don't know much about programming langage design you like
comp.lang.c to help out.

<snip>
-- 
Ben.

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

#64542

On Tuesday, June 30, 2015 at 9:19:59 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > The thing we're creating is called "Core C" and the body responsible
> > for it will be the "Core C Group".
> 
> I think you misspoke.  You are trying to define your language RDC and
> since you don't know much about programming langage design you like
> comp.lang.c to help out.
> 
> <snip>
> -- 
> Ben.

I get that you don't like me, Ben.  And that' fine.  Hate away all
you want to.  Be insulting and mean.  It will bring you nothing but
pain and torment though, and I advise against it.

I have come here to work on Core C.  It is different than RDC.
RDC doesn't define a virtual machine.  RDC has ports and other
data types and abilities which are not defined here, such as
line-if statements, and full-if statements.

I am posting here to get help with Core C.  If there's no interest
it will die quickly.  If there is interest, then it will move on
its own -- your non-help notwithstanding.

Best regards,
Rick C. Hodgin

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

#64545

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, June 30, 2015 at 9:19:59 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > The thing we're creating is called "Core C" and the body responsible
>> > for it will be the "Core C Group".
>> 
>> I think you misspoke.  You are trying to define your language RDC and
>> since you don't know much about programming langage design you like
>> comp.lang.c to help out.
<snip> 
>
> I get that you don't like me, Ben.  And that' fine.  Hate away all
> you want to.

I hate your ideas.  They are bad ideas.  The world does not need another
half-baked language from the 90s.

<snip>
-- 
Ben.

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

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

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

csiph-web