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 1 of 3  [1] 2 3  Next page →

#64522 — "core C"

"core C" already exist

it is the use of
"intxx_t" type that would make all operation +-/* all the same for
differents machine/compiler

it is one float of fixed size

it is some macro value for aligned 

it is a pointer linear of 32 bit
and a pointer   linear of 64 bit

end

endianes of cpu for me has no rilevance
the only place that it count something is when integers are sent
code-decode

endianes not count for operators
0x2 & 0x7  
would be the same number for all computer whaterver endianess they
have, or am i wrong?

[toc] | [next] | [standalone]

#64523

Rosario19 <Ros@invalid.invalid> wrote:
> "core C" already exist

Yes?

> it is the use of
> "intxx_t" type that would make all operation +-/* all the same for
> differents machine/compiler

There's one drawback with the intN_t types: they're optional.
Thus this only will work on systems were these typedefs
actually exist. Systems with CHAR_BIT larger than 8 will
have real problems supporting all or at least some of them.
And the behaviour on overflow is still not defined for
the intN_t types, so the result of a simple addition that
overflows can be different on different systems.

> it is one float of fixed size

And which is that? There's, as far as I am aware, float,
double and long double. But none of them have a fixed size.

> it is some macro value for aligned 

> it is a pointer linear of 32 bit
> and a pointer   linear of 64 bit

No idea what you're talking about.

> end

> endianes of cpu for me has no rilevance
> the only place that it count something is when integers are sent
> code-decode

Endianess is very relevant whenever you exchange data with
a different system, either over the network or when reading
a file thatwas created on a different system. And it not
only concerns integers but also floating point numbers.

> endianes not count for operators
> 0x2 & 0x7  
> would be the same number for all computer whaterver endianess they
> have, or am i wrong?

Yes, but that requires that you have the data already read
in correctly into memory.
                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#64527

On Tuesday, June 30, 2015 at 8:54:20 AM UTC+1, Jens Thoms Toerring wrote:
> Rosario19 <Ros@invalid.invalid> wrote:
> 
> > it is one float of fixed size
> 
> And which is that? There's, as far as I am aware, float,
> double and long double. But none of them have a fixed size.
> 
If floating point precision is important to your application, then it's likely
that you a re doing heavy-duty floating point number crunching. So it's
only practical to use the hardware floating point unit. If it isn't strictly
conforming to IEEE then the results won't be consistent with runs on
other platforms, and there's not much you can do about it.

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

#64554

On 30 Jun 2015 07:54:13 GMT,(Jens Thoms Toerring) wrote:
>Rosario19 <Ros@invalid.invalid> wrote:
>> "core C" already exist
>
>Yes?
>
>> it is the use of
>> "intxx_t" type that would make all operation +-/* all the same for
>> differents machine/compiler
>
>There's one drawback with the intN_t types: they're optional.
>Thus this only will work on systems were these typedefs
>actually exist. Systems with CHAR_BIT larger than 8 will
>have real problems supporting all or at least some of them.

in that sys would be a little more slow

>And the behaviour on overflow is still not defined for
>the intN_t types, so the result of a simple addition that
>overflows can be different on different systems.

overflow would be: as mod_n wighout UBs and something for see if there
is overflow for the last operation

>> it is one float of fixed size
>
>And which is that? There's, as far as I am aware, float,
>double and long double. But none of them have a fixed size.

double [float 64 bit]  float [float 32 bit]

>> it is some macro value for aligned 
>
>> it is a pointer linear of 32 bit
>> and a pointer   linear of 64 bit
>
>No idea what you're talking about.

>> end
>
>> endianes of cpu for me has no rilevance
>> the only place that it count something is when integers are sent
>> code-decode
>
>Endianess is very relevant whenever you exchange data with
>a different system, either over the network or when reading
>a file thatwas created on a different system. And it not
>only concerns integers but also floating point numbers.

i used it only thru OS function when send trhu internet
never see other use

>> endianes not count for operators
>> 0x2 & 0x7  
>> would be the same number for all computer whaterver endianess they
>> have, or am i wrong?
>
>Yes, but that requires that you have the data already read
>in correctly into memory.

yes

>                             Regards, Jens

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

#64556

On Tue, 30 Jun 2015 17:31:41 +0200, Rosario19 wrote:
>On 30 Jun 2015 07:54:13 GMT,(Jens Thoms Toerring) wrote:
>>Rosario19 <Ros@invalid.invalid> wrote:
>>> "core C" already exist
>>
>>Yes?
>>
>>> it is the use of
>>> "intxx_t" type that would make all operation +-/* all the same for
>>> differents machine/compiler
>>
>>There's one drawback with the intN_t types: they're optional.
>>Thus this only will work on systems were these typedefs
>>actually exist. Systems with CHAR_BIT larger than 8 will
>>have real problems supporting all or at least some of them.
>
>in that sys would be a little more slow
>
>>And the behaviour on overflow is still not defined for
>>the intN_t types, so the result of a simple addition that
>>overflows can be different on different systems.
>
>overflow would be: as mod_n wighout UBs and something for see if there
>is overflow for the last operation

possible something more rivolutionary...
u32  has  0xFFFFFFFF as error element

so if  "u32 n1, n2;"

n1 b 0xFFFFFFFF=n2 b 0xFFFFFFFF=0xFFFFFFFF  the error element
n1 b n2        =0xFFFFFFFF    if operation b overflow the result

where b is a binary operator

operator 0xFFFFFFFF = 0xFFFFFFFF

so no UB, overflow detected in the result even if long operations

a+b+c*f=m

if m=0xFFFFFFFF

some error or overflow somewhere

the same for integer, where the overflow element is 0x80000000
the same for double or float where the overflo element would be
doubleMax and floatMax

but i don't know if all that is ok

there is a problem for big number in array of u32 [or u8 or u16]
c=a*b  has to be mod_FFFFFFFF for build the big number [using in some
way overflow too of that operation]
this just above not allow that

so in the end i prefer all mod_n and something for detec overflow

a=b+c; v=ov();

where ov() calculate overflow last statement

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

#64563

On Tuesday, June 30, 2015 at 12:15:53 PM UTC-4, Rosario19 wrote:
> On Tue, 30 Jun 2015 17:31:41 +0200, Rosario19 wrote:
> >On 30 Jun 2015 07:54:13 GMT,(Jens Thoms Toerring) wrote:
> >>Rosario19 <Ros@invalid.invalid> wrote:
> >>> "core C" already exist
> >>
> >>Yes?
> >>
> >>> it is the use of
> >>> "intxx_t" type that would make all operation +-/* all the same for
> >>> differents machine/compiler
> >>
> >>There's one drawback with the intN_t types: they're optional.
> >>Thus this only will work on systems were these typedefs
> >>actually exist. Systems with CHAR_BIT larger than 8 will
> >>have real problems supporting all or at least some of them.
> >
> >in that sys would be a little more slow
> >
> >>And the behaviour on overflow is still not defined for
> >>the intN_t types, so the result of a simple addition that
> >>overflows can be different on different systems.
> >
> >overflow would be: as mod_n wighout UBs and something for see if there
> >is overflow for the last operation
> 
> possible something more rivolutionary...
> u32  has  0xFFFFFFFF as error element
> 
> so if  "u32 n1, n2;"
> 
> n1 b 0xFFFFFFFF=n2 b 0xFFFFFFFF=0xFFFFFFFF  the error element
> n1 b n2        =0xFFFFFFFF    if operation b overflow the result
> 
> where b is a binary operator
> 
> operator 0xFFFFFFFF = 0xFFFFFFFF
> 
> so no UB, overflow detected in the result even if long operations
> 
> a+b+c*f=m
> 
> if m=0xFFFFFFFF
> 
> some error or overflow somewhere
> 
> the same for integer, where the overflow element is 0x80000000
> the same for double or float where the overflo element would be
> doubleMax and floatMax
> 
> but i don't know if all that is ok
> 
> there is a problem for big number in array of u32 [or u8 or u16]
> c=a*b  has to be mod_FFFFFFFF for build the big number [using in some
> way overflow too of that operation]
> this just above not allow that
> 
> so in the end i prefer all mod_n and something for detec overflow
> 
> a=b+c; v=ov();
> 
> where ov() calculate overflow last statement

I have defined something similar in RDC and Visual FreePro.  It is
a cask, and it allows injection at any point to identify the range
values expected.  It performs that test, and if the test fails it
calls the adhoc function named on the cask.

    (|reference cask|)     // References something which exists
    [|definition cask|]    // Defines something new (sets a flag)
    <|logic cask|>         // Performs a test
    ~|utility cask|~       // Arbitrary code injection without adhoc

Simplified, the casks can be single, left, right, or both:

    (|cask|)               // Single
    (||left|cask|)         // Left
    (|cask|right||)        // Right
    (||left|cask|right||)  // Both

And each of the right or left sides can have pips between (|
and |), which identify if that portion is raised or lowered.
For example:

    (o|cask|o)

This would graphically present as two closed pips.

    (O|cask|o)

This would graphically present as left-open, right-closed pips.
And the same is true with other things on the sides:

    (o||left|cask|o)
    (o|cask|right||o)
    (o||left|cask|right||o)

And to add multiple pips up to three, open or closed:

    (oo|cask|oo)
    (ooo|cask|ooo)

Graphically you can see the forms here in this template:

    https://raw.githubusercontent.com/RickCHodgin/libsf/master/source/vjr/source/bmps/graphics/raw_tiled/cask_icons.bmp

And here in something Visual FreePro uses (upper right):

    http://www.visual-freepro.org/images/vjr_046.png

-----
For ranges, overflows, underflows, you can setup casks which will
be called when those hit, such as:

    s32 x, y;
    flag failure;

    adhoc underflow(s32& x) {
        // Underflow handler code goes here, log, report
        failure = yes;
    }

    adhoc overflow(s32& x) {
        // Overflow handler code goes here, log, report
        failure = yes;
    }

    // Some code which populates y
    failure = no;
    x = y  <|x < 0|underflow(x)||>  <|x > 200|overflow(x)||>;
    if (failure)
        returnto(restart_process);

Best regards,
Rick C. Hodgin

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

#64528

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.

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]

#64531

On Tuesday, June 30, 2015 at 7:27:25 AM UTC-4, Rick C. Hodgin wrote:
> #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).

I think this should be defined as "bN" where N is the number of bits,
and the range should be 1 <= n <= 64.  It is designed, by default, to
contain an unsigned integer of that width.  To use it in another form,
cast it to another destination:

    b17 lbMyBitVar;
    s32 lnSigned32;

    lnSigned32 = (s32)lbMyBitVar;
    ...
    lbMyBitVar = (b17)lnSigned32;

In each of these casts, whatever raw bit sequence exists is
transferred to the destination.  No sign extensions or interpolation.

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

Best regards,
Rick C. Hodgin

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

#64533

On 30/06/2015 12:48, Rick C. Hodgin wrote:
> On Tuesday, June 30, 2015 at 7:27:25 AM UTC-4, Rick C. Hodgin wrote:
>> #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).
>
> I think this should be defined as "bN" where N is the number of bits,
> and the range should be 1 <= n <= 64.  It is designed, by default, to
> contain an unsigned integer of that width.  To use it in another form,
> cast it to another destination:
>
>      b17 lbMyBitVar;
>      s32 lnSigned32;
>
>      lnSigned32 = (s32)lbMyBitVar;
>      ...
>      lbMyBitVar = (b17)lnSigned32;
>
> In each of these casts, whatever raw bit sequence exists is
> transferred to the destination.  No sign extensions or interpolation.

OK, this shows you haven't properly thought these through... (...if you 
can make a significant change even before someone can respond to the 
original proposals!)

So, what is the difference between b17 and u17? And what exactly does it 
mean to have standalone variables 17 bits wide? Is it to impose the 
range of values 0 to 131071? Which would be a rather odd range. And what 
happens on overflow: should it wrap (as happens in C with unsigned), or 
be undefined, or trap?

-- 
Bartc

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

#64535

On Tuesday, June 30, 2015 at 8:07:44 AM UTC-4, Bart wrote:
> On 30/06/2015 12:48, Rick C. Hodgin wrote:
> > On Tuesday, June 30, 2015 at 7:27:25 AM UTC-4, Rick C. Hodgin wrote:
> >> #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).
> >
> > I think this should be defined as "bN" where N is the number of bits,
> > and the range should be 1 <= n <= 64.  It is designed, by default, to
> > contain an unsigned integer of that width.  To use it in another form,
> > cast it to another destination:
> >
> >      b17 lbMyBitVar;
> >      s32 lnSigned32;
> >
> >      lnSigned32 = (s32)lbMyBitVar;
> >      ...
> >      lbMyBitVar = (b17)lnSigned32;
> >
> > In each of these casts, whatever raw bit sequence exists is
> > transferred to the destination.  No sign extensions or interpolation.
> 
> OK, this shows you haven't properly thought these through... (...if you 
> can make a significant change even before someone can respond to the 
> original proposals!)
> 
> So, what is the difference between b17 and u17? And what exactly does it 
> mean to have standalone variables 17 bits wide? Is it to impose the 
> range of values 0 to 131071? Which would be a rather odd range. And what 
> happens on overflow: should it wrap (as happens in C with unsigned), or 
> be undefined, or trap?

u17 is not defined in Core C.  u8, u16, u32, u64.  If you go into
extensions of Core C which support a type of u17, then there would
be no difference between b17 and u17.

Typically b17 is needed as a bit-packed value, and u32 would be
used to manipulate it, and then it's stored back as b17.

In RDC I have defined a set of auto-expanding variables which
do that.  They are always their fundamental type, but the upsize
in calculations to another size for normal use.

Best regards,
Rick C. Hodgin

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

#64532

On 30/06/2015 12: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.
>
> #1 Little endian.
> #2 Two's complement.
> #3 All pointers are the same size per target.
> #4 All memory is executable.

No way of turning it into non-executable? A bit dangerous.

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

No 'char' type?

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

I bet it won't be 1-bit! How much storage will an array of 1000 flags 
take up? Anything smaller than 1000 bytes means you have to deal with 
bits and bit-pointers, which might compromise #3, making all pointers 
the same size.

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

Anywhere, or just inside structs or as array elements? But the same 
objection as before. What about bits:12 and bits:20 (which tidily fit 
into a 32-bit type)?

What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to 
+1 for example)? Will bits:N ever cross a byte-boundary? (In which case, 
you might want bits:8 starting halfway through a byte.)

Range-checking on assignment is going to slow down any operations, as 
presumably this encompasses all possible overflows on arithmetic as well 
as when assigning to and from a bits:N from a different type.

How many bytes and/or bits will a [5] array of bits:7 take up?

Just saying bit types and bitfields take a lot of support.

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

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

And this is completely misplaced. I assume this would be dynamically 
typed? Then it would make nonsense of whatever type system you're trying 
to impose.

Example, in A=&B; you would expect that if B is of type T, then A ought 
to be of type T*. But both could of of 'var' type with nothing amiss; 
anything goes. And you need to make a distinction between the static 
'var' type of something, and the dynamic type it contains. Would a var* 
type be allowed? Would var types be passed by value or by reference? Etc.

Another can of worms inappropriate in a 'core' language.

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

And this is where you're going to lose everyone who's made it this far. 
This is nothing to do with languages or compilers as they are normally 
understood.

-- 
Bartc

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

#64534

On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
> On 30/06/2015 12:27, Rick C. Hodgin wrote:
> > #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).
> 
> Anywhere, or just inside structs or as array elements? But the same 
> objection as before. What about bits:12 and bits:20 (which tidily fit 
> into a 32-bit type)?

When defined separately, they are bit-merged into local or global
memory space, and then bit-masked and bit-shifted for use.

> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to 
> +1 for example)? Will bits:N ever cross a byte-boundary? (In which case, 
> you might want bits:8 starting halfway through a byte.)

All bit types are unsigned integers.

> Range-checking on assignment is going to slow down any operations, as 
> presumably this encompasses all possible overflows on arithmetic as well 
> as when assigning to and from a bits:N from a different type.

Yes.  They are used to migrate the need to range check from developer
code to compiler code.  If you don't want range checking, do it
manually in developer code.

> How many bytes and/or bits will a [5] array of bits:7 take up?

When defined as an array, they are bit-packed.

> Just saying bit types and bitfields take a lot of support.

Yup.

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

> > #13 A new weakly typed variable type is introduced:  var
> 
> And this is completely misplaced. I assume this would be dynamically 
> typed? Then it would make nonsense of whatever type system you're trying 
> to impose.

It is based on usage:

    var x;

    x = 5;        // assumed s32
    x = "rick";   // assumed s8[]

It is not a literal type, but points to a simple structure, which
then conveys the type within.  It must be converted or translated
to fundamental types, and there are new features which allow for
a var type to be tested to see what type it is.

> Example, in A=&B; you would expect that if B is of type T, then A ought 
> to be of type T*. But both could of of 'var' type with nothing amiss; 
> anything goes. And you need to make a distinction between the static 
> 'var' type of something, and the dynamic type it contains. Would a var* 
> type be allowed? Would var types be passed by value or by reference? Etc.

If B is var, A will point to the base of the var structure.

> Another can of worms inappropriate in a 'core' language.
> 
> > #15 The concept of edit-and-continue compilation is mandatory.
> 
> And this is where you're going to lose everyone who's made it this far. 
> This is nothing to do with languages or compilers as they are normally 
> understood.

No problem.  I would say it's a division.  I'm talking about dividing
things here into the before, and after camps.

Best regards,
Rick C. Hodgin

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

#64536

On 30/06/2015 13:13, Rick C. Hodgin wrote:
> On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:

>> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to
>> +1 for example)?

> All bit types are unsigned integers.

Suppose you want a signed 7-bit value?

>> How many bytes and/or bits will a [5] array of bits:7 take up?
>
> When defined as an array, they are bit-packed.

>> Just saying bit types and bitfields take a lot of support.

So an element of a 7-bit array could start at any offset into a byte, 
and could cross a byte boundary (so most accesses will need to be 16-bit 
ones). Also, a 7-bit array passed to a function, if you don't start from 
element [0] but choose the slice starting at [3] for example, might not 
be byte-aligned on the first element.

What about a 2D array of 7-bit values? It get's hairy!

(Which is why I limited bit-types in one language to 1, 2 or 4 bits; as 
the sequence tidily continues 8, 16, 32, 64 (and then to 128 bits and up).

You don't find integer types of 43 bits for example. But the same 
language is happy to provide bit operations, such as extracting a 23-bit 
field from a 32- or 64-bit int.

For accessing fields that cross boundaries, this is a bitfield pointer 
type that is supposed to be capable of that: accessing fields 1-64 bits 
at any byte address and starting at any bit offset. But you then get 
into questions of bit-order and byte-order. Beyond that, there is a 
separate bit-slice pointer where you can have a bit (or bit:2 or bit:4) 
sequence of any length.

If it gets complicated enough that you have to think twice about what 
things mean, then it might be too advanced for a core language.

I would advise limiting bit ops to 1, 2 or 4 bits, or even 1 bit, and 
limiting them to use as array elements. (C already has bitfields for 
structs, with limited capabilities.) And providing bit/bitfield 
operations instead.

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

No, I mean a core language would be used to implement them in a language 
or extension beyond the core language. How many times are big integers 
needed anyway? There are rather specialised. Better is built-in support 
for 128- and 256-bits.

>>> #13 A new weakly typed variable type is introduced:  var
>>
>> And this is completely misplaced. I assume this would be dynamically
>> typed? Then it would make nonsense of whatever type system you're trying
>> to impose.
>
> It is based on usage:
>
>      var x;
>
>      x = 5;        // assumed s32
>      x = "rick";   // assumed s8[]

So characters are signed; why?

>> Example, in A=&B; you would expect that if B is of type T, then A ought
>> to be of type T*. But both could of of 'var' type with nothing amiss;
>> anything goes. And you need to make a distinction between the static
>> 'var' type of something, and the dynamic type it contains. Would a var*
>> type be allowed? Would var types be passed by value or by reference? Etc.
>
> If B is var, A will point to the base of the var structure.

And the type of A will be what? (apart from 'var'). Don't forget the 
compiler may not know what type it contains. Try this:

  var A, B;

  B = 632;
  A = &B;

will A contain a var* type or a s32* type?

I think people programming at this level will have trouble dealing with 
code such as:

   var A;
   A = &A;        // or:
   A = *A;        // or:
   A = A->month;  // or:
   A = A.month;   // or:
   A = strlen(A);

with all equally valid as far as the compiler is concerned.

-- 
Bartc

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

#64538

On Tuesday, June 30, 2015 at 8:58:34 AM UTC-4, Bart wrote:
> On 30/06/2015 13:13, Rick C. Hodgin wrote:
> > On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
> 
> >> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to
> >> +1 for example)?
> 
> > All bit types are unsigned integers.
> 
> Suppose you want a signed 7-bit value?

Two's complement.  Use an s8 value and store as b7 when done.

> >> How many bytes and/or bits will a [5] array of bits:7 take up?
> > When defined as an array, they are bit-packed.
> >> Just saying bit types and bitfields take a lot of support.
> 
> So an element of a 7-bit array could start at any offset into a byte, 
> and could cross a byte boundary (so most accesses will need to be 16-bit 
> ones). Also, a 7-bit array passed to a function, if you don't start from 
> element [0] but choose the slice starting at [3] for example, might not 
> be byte-aligned on the first element.

An array of bit variables cannot be passed except by pointer to
element 0.

> What about a 2D array of 7-bit values? It get's hairy!

The 2nd dimension will append to the first.  The third onto
that, etc.  It's just math.

> (Which is why I limited bit-types in one language to 1, 2 or 4 bits; as 
> the sequence tidily continues 8, 16, 32, 64 (and then to 128 bits and up).
> 
> You don't find integer types of 43 bits for example. But the same 
> language is happy to provide bit operations, such as extracting a 23-bit 
> field from a 32- or 64-bit int.
> 
> For accessing fields that cross boundaries, this is a bitfield pointer

Bitfield pointers do not exist in Core C.  Bits are designed to be
accessed as values, stored back out as values.  If you want to have
a particular group of bits being manipulated in some way, put them
in a struct and pass a pointer to the struct around and access them
there.

> type that is supposed to be capable of that: accessing fields 1-64 bits 
> at any byte address and starting at any bit offset. But you then get 
> into questions of bit-order and byte-order. Beyond that, there is a 
> separate bit-slice pointer where you can have a bit (or bit:2 or bit:4) 
> sequence of any length.
> 
> If it gets complicated enough that you have to think twice about what 
> things mean, then it might be too advanced for a core language.
> 
> I would advise limiting bit ops to 1, 2 or 4 bits, or even 1 bit, and 
> limiting them to use as array elements. (C already has bitfields for 
> structs, with limited capabilities.) And providing bit/bitfield 
> operations instead.
> 
> >>> #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.
> 
> No, I mean a core language would be used to implement them in a language 
> or extension beyond the core language. How many times are big integers 
> needed anyway? There are rather specialised. Better is built-in support 
> for 128- and 256-bits.

They will be defined as part of Core C as there are many well-mature
libraries out there which support them.  The expense is minimal, and
they are another tool in the arsenal.

> >>> #13 A new weakly typed variable type is introduced:  var
> >>
> >> And this is completely misplaced. I assume this would be dynamically
> >> typed? Then it would make nonsense of whatever type system you're trying
> >> to impose.
> >
> > It is based on usage:
> >
> >      var x;
> >
> >      x = 5;        // assumed s32
> >      x = "rick";   // assumed s8[]
> 
> So characters are signed; why?
> 
> >> Example, in A=&B; you would expect that if B is of type T, then A ought
> >> to be of type T*. But both could of of 'var' type with nothing amiss;
> >> anything goes. And you need to make a distinction between the static
> >> 'var' type of something, and the dynamic type it contains. Would a var*
> >> type be allowed? Would var types be passed by value or by reference? Etc.
> >
> > If B is var, A will point to the base of the var structure.
> 
> And the type of A will be what? (apart from 'var'). Don't forget the 
> compiler may not know what type it contains. Try this:
> 
>   var A, B;
> 
>   B = 632;
>   A = &B;
> 
> will A contain a var* type or a s32* type?

A would be a var, whose type is var*, which points to B.  If you
were to reference A after that, you would be referencing and
manipulating B's s32 value.

struct SVar
{
    s32 type;
    union {
        // Whole bunch of values from s8..s64, u8..u64, f32, f64,
        // As well as pointers to fundamental types.
        // For s8[] data, it would have an SDatum struct, which
        // holds a pointer, and length.
    };
};

> I think people programming at this level will have trouble dealing with 
> code such as:
> 
>    var A;
>    A = &A;        // or:
>    A = *A;        // or:
>    A = A->month;  // or:
>    A = A.month;   // or:
>    A = strlen(A);
> 
> with all equally valid as far as the compiler is concerned.

Using a weakly typed variable comes at performance expense, but it
can also be fantastic for certain data manipulations.  I think it
will be good.

Best regards,
Rick C. Hodgin

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

#64544

On 30/06/2015 14:11, Rick C. Hodgin wrote:
> On Tuesday, June 30, 2015 at 8:58:34 AM UTC-4, Bart wrote:
>> On 30/06/2015 13:13, Rick C. Hodgin wrote:
>>> On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
>>
>>>> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to
>>>> +1 for example)?
>>
>>> All bit types are unsigned integers.
>>
>> Suppose you want a signed 7-bit value?
>
> 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.

>> So an element of a 7-bit array could start at any offset into a byte,
>> and could cross a byte boundary (so most accesses will need to be 16-bit
>> ones). Also, a 7-bit array passed to a function, if you don't start from
>> element [0] but choose the slice starting at [3] for example, might not
>> be byte-aligned on the first element.
>
> An array of bit variables cannot be passed except by pointer to
> element 0.
>
>> What about a 2D array of 7-bit values? It get's hairy!
>
> The 2nd dimension will append to the first.  The third onto
> that, etc.  It's just math.

Then some rows of the array won't be aligned to the start of a byte. 
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.

In fact, each row will start at a different bit position from most of 
the other rows.

>> (Which is why I limited bit-types in one language to 1, 2 or 4 bits; as
>> the sequence tidily continues 8, 16, 32, 64 (and then to 128 bits and up).
>>
>> You don't find integer types of 43 bits for example. But the same
>> language is happy to provide bit operations, such as extracting a 23-bit
>> field from a 32- or 64-bit int.
>>
>> For accessing fields that cross boundaries, this is a bitfield pointer
>
> Bitfield pointers do not exist in Core C.  Bits are designed to be
> accessed as values, stored back out as values.  If you want to have
> a particular group of bits being manipulated in some way, put them
> in a struct and pass a pointer to the struct around and access them
> there.

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?

>> No, I mean a core language would be used to implement them in a language
>> or extension beyond the core language. How many times are big integers
>> needed anyway? There are rather specialised. Better is built-in support
>> for 128- and 256-bits.
>
> They will be defined as part of Core C as there are many well-mature
> libraries

That's part of the problem; which library will you choose to be 
standard? The authors of the other libraries might be put out!

>>>> Example, in A=&B; you would expect that if B is of type T, then A ought
>>>> to be of type T*. But both could of of 'var' type with nothing amiss;
>>>> anything goes. And you need to make a distinction between the static
>>>> 'var' type of something, and the dynamic type it contains. Would a var*
>>>> type be allowed? Would var types be passed by value or by reference? Etc.
>>>
>>> If B is var, A will point to the base of the var structure.
>>
>> And the type of A will be what? (apart from 'var'). Don't forget the
>> compiler may not know what type it contains. Try this:
>>
>>    var A, B;
>>
>>    B = 632;
>>    A = &B;
>>
>> will A contain a var* type or a s32* type?
>
> A would be a var, whose type is var*, which points to B.  If you
> were to reference A after that, you would be referencing and
> manipulating B's s32 value.

That's not clear. What does *A give you? Would you need **A to get the 
s32 value?

Suppose you had a function taking an s32* parameter, and you wanted to 
pass B to it so that it could modify the s32 value inside B; what would 
you pass? Would you need to insert run-time checks to ensure B contains 
the right type? Could you pass either A or B to it (with A containing &B)?

> struct SVar
> {
>      s32 type;
>      union {
>          // Whole bunch of values from s8..s64, u8..u64, f32, f64,
>          // As well as pointers to fundamental types.
>          // For s8[] data, it would have an SDatum struct, which
>          // holds a pointer, and length.
>      };
> };

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?

If you want the particular semantics associated with u8 (so 255+1 gives 
you 0 rather than 256), there must be better ways of doing that. (In C, 
255+1 will give 256 even using uint8_t unless casts and such are used.)

Inside variants you want a simpler set of numeric types.

You might instead look at ways of having flexible strings and arrays, 
which could be a better fit into a core language which is a little 
higher level than C.

> Using a weakly typed variable comes at performance expense, but it
> can also be fantastic for certain data manipulations.  I think it
> will be good.

If performance doesn't matter then people will just use a more apt 
language for that. Mixing static and dynamic types is difficult.

-- 
Bartc

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

#64546

On Tuesday, June 30, 2015 at 10:11:19 AM UTC-4, Bart wrote:
> On 30/06/2015 14:11, Rick C. Hodgin wrote:
> > On Tuesday, June 30, 2015 at 8:58:34 AM UTC-4, Bart wrote:
> >> On 30/06/2015 13:13, Rick C. Hodgin wrote:
> >>> On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
> >>
> >>>> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to
> >>>> +1 for example)?
> >>
> >>> All bit types are unsigned integers.
> >>
> >> Suppose you want a signed 7-bit value?
> >
> > 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.

> >> So an element of a 7-bit array could start at any offset into a byte,
> >> and could cross a byte boundary (so most accesses will need to be 16-bit
> >> ones). Also, a 7-bit array passed to a function, if you don't start from
> >> element [0] but choose the slice starting at [3] for example, might not
> >> be byte-aligned on the first element.
> >
> > An array of bit variables cannot be passed except by pointer to
> > element 0.
> >
> >> What about a 2D array of 7-bit values? It get's hairy!
> >
> > The 2nd dimension will append to the first.  The third onto
> > that, etc.  It's just math.
> 
> Then some rows of the array won't be aligned to the start of a byte.

Correct.

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

> In fact, each row will start at a different bit position from most of 
> the other rows.
> 
> >> (Which is why I limited bit-types in one language to 1, 2 or 4 bits; as
> >> the sequence tidily continues 8, 16, 32, 64 (and then to 128 bits and up).
> >>
> >> You don't find integer types of 43 bits for example. But the same
> >> language is happy to provide bit operations, such as extracting a 23-bit
> >> field from a 32- or 64-bit int.
> >>
> >> For accessing fields that cross boundaries, this is a bitfield pointer
> >
> > Bitfield pointers do not exist in Core C.  Bits are designed to be
> > accessed as values, stored back out as values.  If you want to have
> > a particular group of bits being manipulated in some way, put them
> > in a struct and pass a pointer to the struct around and access them
> > there.
> 
> 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.

> >> No, I mean a core language would be used to implement them in a language
> >> or extension beyond the core language. How many times are big integers
> >> needed anyway? There are rather specialised. Better is built-in support
> >> for 128- and 256-bits.
> >
> > They will be defined as part of Core C as there are many well-mature
> > libraries
> 
> That's part of the problem; which library will you choose to be 
> standard? The authors of the other libraries might be put out!

It would be defined.  Discussed.  Debated.  And ultimately approved.
But I think if a function is known to C, and it's referenced, there
should not need to be an #include for it.  It is known to the C libs
that are provided for by Core C, or by the implementation extensions
to Core C, and they should automatically be known.

> >>>> Example, in A=&B; you would expect that if B is of type T, then A ought
> >>>> to be of type T*. But both could of of 'var' type with nothing amiss;
> >>>> anything goes. And you need to make a distinction between the static
> >>>> 'var' type of something, and the dynamic type it contains. Would a var*
> >>>> type be allowed? Would var types be passed by value or by reference? Etc.
> >>>
> >>> If B is var, A will point to the base of the var structure.
> >>
> >> And the type of A will be what? (apart from 'var'). Don't forget the
> >> compiler may not know what type it contains. Try this:
> >>
> >>    var A, B;
> >>
> >>    B = 632;
> >>    A = &B;
> >>
> >> will A contain a var* type or a s32* type?
> >
> > A would be a var, whose type is var*, which points to B.  If you
> > were to reference A after that, you would be referencing and
> > manipulating B's s32 value.
> 
> That's not clear. What does *A give you? Would you need **A to get the 
> s32 value?

When you refer to A, it would resolve for you automatically to the
value pointed to in B.

> Suppose you had a function taking an s32* parameter, and you wanted to 
> pass B to it so that it could modify the s32 value inside B; what would 
> you pass? Would you need to insert run-time checks to ensure B contains 
> the right type? Could you pass either A or B to it (with A containing &B)?

I think I'll define a default data item for each var type to be
something like d, so you would reference A.d for the data item,
and in that way you could pass it as an s32* i B was holding an
s32.

> > struct SVar
> > {
> >      s32 type;
> >      union {
> >          // Whole bunch of values from s8..s64, u8..u64, f32, f64,
> >          // As well as pointers to fundamental types.
> >          // For s8[] data, it would have an SDatum struct, which
> >          // holds a pointer, and length.
> >      };
> > };
> 
> 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.

> If you want the particular semantics associated with u8 (so 255+1 gives 
> you 0 rather than 256), there must be better ways of doing that. (In C, 
> 255+1 will give 256 even using uint8_t unless casts and such are used.)
> 
> Inside variants you want a simpler set of numeric types.
> 
> You might instead look at ways of having flexible strings and arrays, 
> which could be a better fit into a core language which is a little 
> higher level than C.

I agree, but C is low level in terms of its strings and arrays.  I
like that.  But, we could provide standard library extensions which
allow for those features.  I would like them a lot.

> > Using a weakly typed variable comes at performance expense, but it
> > can also be fantastic for certain data manipulations.  I think it
> > will be good.
> 
> If performance doesn't matter then people will just use a more apt 
> language for that. Mixing static and dynamic types is difficult.

They're another tool in the toolbox.  Nobody has to use them.  But,
when needed, they're there (so you don't need to go to a higher
level language).

I appreciate your thoughtful feedback, Bart.

Best regards,
Rick C. Hodgin

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

#64550

On Tue, 30 Jun 2015 07:50:19 -0700 (PDT), "Rick C. Hodgin" wrote:
>On Tuesday, June 30, 2015 at 10:11:19 AM UTC-4, Bart wrote:
>> On 30/06/2015 14:11, Rick C. Hodgin wrote:
>> > On Tuesday, June 30, 2015 at 8:58:34 AM UTC-4, Bart wrote:
>> >> On 30/06/2015 13:13, Rick C. Hodgin wrote:
>> >>> On Tuesday, June 30, 2015 at 8:02:16 AM UTC-4, Bart wrote:
>> >>
>> >>>> What is the range of bits:2? Is it 0 to 3, or can be it anything (-2 to
>> >>>> +1 for example)?
>> >>
>> >>> All bit types are unsigned integers.
>> >>
>> >> Suppose you want a signed 7-bit value?

such basic type would not exist
if the problem is one array of 7 bit 
possible better one array of u32 with functions that access to it for
make it appair as array of 7 bit

>> > 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.
>> >> So an element of a 7-bit array could start at any offset into a byte,
>> >> and could cross a byte boundary (so most accesses will need to be 16-bit
>> >> ones). Also, a 7-bit array passed to a function, if you don't start from
>> >> element [0] but choose the slice starting at [3] for example, might not
>> >> be byte-aligned on the first element.
>> >
>> > An array of bit variables cannot be passed except by pointer to
>> > element 0.
>> >
>> >> What about a 2D array of 7-bit values? It get's hairy!

ND array of element of type size x bit 
is a matter of function for access one 1D array of u32 elements

>> > The 2nd dimension will append to the first.  The third onto
>> > that, etc.  It's just math.
>> 
>> Then some rows of the array won't be aligned to the start of a byte.
>
>Correct.
>
>> 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.

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

#64557

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

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

#64559

On Tuesday, June 30, 2015 at 12:45:08 PM UTC-4, Bart 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:
> 
> >>> 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.

There's a problem with using sN or uN as they don't relate to another
type.  They need to be identified as the wieldable type in calculations,
only being transformed back into their target storage type when stored
back.

It's like the bit structs:

    struct SWhatever
    {
        char    field1 : 5;
        int     field2 : 20;
    };

In Core C it would be:

    b5:s8   field1;
    b20:s32 field2;

And we could set it up so it's auto-upsizing to the appropriate value.
In that case it would only be:

    b5:s  field1;  // Auto-upsized in calculations to s8
    b20:s field2;  // Auto-upsized in calculations to s32

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

You can do whatever you want to the data by casting it to another form.
By going through the bit array protocols, you will need a pointer to
the bits, and the offset to either read content, or write content, to
that element.

    b5 array[200];

    // Manual population
    array[5] = 9;

    // Or:
    set_array(array, 5, 9);

    void set_array(b5 array[], int element, int value)
    {
        array[element] = value;
    }

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

Same size.  And the array passed would be more like b5& than b5* so
there would be no null checking.  And we can add bounds settings to
it so there is a scope that must be adhered to with element
references.

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

Except that when you go to pass A to some function, it is converted to
"char" (s8) rather than "int" (s32) or "long long" (s64).

It has proper context for follow-on use based on how it was stored.

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

Yes.  There will be combinations written to support every combination.
I do this presently in Visual FreePro for all of the types there are
weakly typed.  It is the only variable type that is supported.

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

You don't have to use it, Bart.  It is a tool that has validity and
can be useful.  In XBASE languages there is a function called TYPE()
used for this:

    if (type(A) == _S8) { ... }

And we can add these:

    if (isNumeric(A))
    if (isFloatingPoint(A))
    if (isInteger(A))

Et cetera.

Best regards,
Rick C. Hodgin

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

#64582

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?

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

-- 
Bartc

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web