Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: "core C" |
| Date | 2015-06-30 15:11 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <mmu7vc$eak$1@dont-email.me> (permalink) |
| References | (1 earlier) <f4001c33-3768-4c92-82c0-10825a331ea9@googlegroups.com> <mmu0dc$f67$1@dont-email.me> <6106badd-4e24-47df-b3df-490005aa2fc9@googlegroups.com> <mmu3mv$rsv$1@dont-email.me> <148aee8c-8afc-476c-a200-51fded30fdea@googlegroups.com> |
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
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
"core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 08:38 +0200
Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-06-30 07:54 +0000
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 02:55 -0700
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:31 +0200
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 18:15 +0200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 12:19 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:27 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:48 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:07 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:15 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:02 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 05:13 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 13:58 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:11 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 15:11 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:50 -0700
Re: "core C" Rosario19 <Ros@invalid.invalid> - 2015-06-30 17:24 +0200
Re: "core C" Bartc <bc@freeuk.com> - 2015-06-30 17:44 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 10:04 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 11:46 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 04:40 -0700
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 08:05 -0700
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-01 17:01 +0100
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 10:56 -0700
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 12:59 -0500
Re: "core C" Bartc <bc@freeuk.com> - 2015-07-04 20:25 +0100
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 20:56 -0500
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:17 +0100
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:03 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:16 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 15:46 +0200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:54 -0700
Re: "core C" Steve Thompson <stevet810@gmail.com> - 2015-07-03 12:25 +0000
Re: "core C" jt@toerring.de (Jens Thoms Toerring) - 2015-07-01 15:04 +0000
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-01 08:12 -0700
Re: "core C" BGB <cr88192@hotmail.com> - 2015-07-04 10:36 -0500
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:41 -0700
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 14:19 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 06:25 -0700
Re: "core C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-30 15:48 +0100
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 07:52 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 04:42 -0700
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 08:28 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-06-30 22:28 +0200
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 08:45 +1200
Re: "core C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-30 13:56 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 10:27 +0200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 14:56 -0700
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:03 +1200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 15:31 -0700
Re: "core C" Ian Collins <ian-news@hotmail.com> - 2015-07-01 10:52 +1200
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-30 16:58 -0700
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-06-30 17:30 -0700
Re: "core C" David Brown <david.brown@hesbynett.no> - 2015-07-01 08:54 +0200
Re: "core C" Keith Thompson <kst-u@mib.org> - 2015-07-01 07:54 -0700
Re: "core C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-01 09:42 -0700
csiph-web