Ilya Minkov wrote:
> Ben Hinkle schrieb:
> 
>> I bet most people don't like bit because of bool. The fact that bits are not
>> addressable is just because bytes are the smallest addressable unit. If bits
>> were addressable I'd have to ask which bit is being addressed - and what about
>> the addresses of the other 7 bits sharing that same address?
> 
> 
> This simply means that bits requiere a completely separate infrastructure of the following:
> 
> * bit as a boolean type. Can be placed in a byte or int or whatever.
> * bit pointer type - consisiting of byte pointer and additional 3 bits offset.
> * bit array struct - conceptually consisting of 2 bit pointers for beginning and end. This may also be bit pointer and length, perhaps the range of length can even be limited to save space.
> 
> This is how it was intended to be implemented. Walter probably just doesn't have enough hands to do so. The latter 2 of these types would not work by the usual DMD types implementation (as now), but simply map separate to corresponding syntaxes. There's probably nothing fancy about it, it just takes some time and power to implement, and the current "implementation" is just a quick hack. The implementation itself can be in the library, the compiler would only have to translate the syntax.
> 
> The current implementation may not stay as it is, but discarding the good idea just because the implementation is not there yet would be a great pity. And Andy, please don't place any bets on bits staying crippled: they are not crippled by the spec, and you don't want them to be, do you?

Fair enough.  I'm just not convinced that fixing them would be worth the trouble. :)

What's the use case that justifies all this complexity?  I haven't seen any D at all that uses, or even calls for the use of bit[], nor can I think of any situation where they would be significantly better than a library implementation.

 -- andy

Andy Friesen wrote:
<snip>
>> This simply means that bits requiere a completely separate infrastructure of the following:
>>
>> * bit as a boolean type. Can be placed in a byte or int or whatever.

Do you mean that if one declares just a bit, not a bit[], it would occupy a byte or four?  IMM, it would make sense to pack multiple bit members of a struct or class into bytes or four-byte blocks.  Moreover, if in a struct, it ought to obey the alignment setting.  (I haven't checked this, and don't know how much impact it would have on existing code.)

>> * bit pointer type - consisiting of byte pointer and additional 3 bits offset.
>> * bit array struct - conceptually consisting of 2 bit pointers for beginning and end. This may also be bit pointer and length, perhaps the range of length can even be limited to save space.

This idea has been around for a while.  I coded up an implementation on roughly this basis a while back:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/495

Indeed, I recall from the change log that the current bit pointer implementation allows space to address individual bits, but hasn't implemented the use of it yet.

<snip>
> Fair enough.  I'm just not convinced that fixing them would be worth the trouble. :)
> 
> What's the use case that justifies all this complexity?  I haven't seen any D at all that uses, or even calls for the use of bit[],

I've used it experimentally, but I'm quite sure it could be put to practical use.  Otherwise, it probably wouldn't have been put in at all.

Some possible things that could benefit from bits/bit arrays:

- bit flags, which seem to be common in APIs
- data compression algorithms
- implementations of things such as Life or Turing machines

OK, so the latter could be done with bytes just as well, but it would bloat memory requirements.

> nor can I think of any situation where they would be significantly
> better than a library implementation.

Hmm....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <cheqr4$308q$1@digitaldaemon.com>, Ilya Minkov says...

>Perhaps we could develop our own cross-OS binary format for libraries, and embed a loader in Phobos. The task of this should be to provide both interface and object code on the one hand, and allow the library to use the object code from the main executable. It would not only solve the GC problem, but also all of the plug-in writing problems. DLL is not very adequate, i guess.

Is cross-OS actually what you mean? I don't see how an application running on a Windows OS can run object code compiled and running on a Linus OS. You mean two different-OS PCs networked together? Connected via the internet? What?

I am particularly intrigued by anything which claims to "solve the GC problem". Please could you define "the GC problem", and tell me how such a cross-OS-binary format would solve it? That would be amazing.

Arcane Jill

In article <chgd5m$pm5$1@digitaldaemon.com>, Andy Friesen says...

>What's the use case that justifies all this complexity?  I haven't seen any D at all that uses, or even calls for the use of bit[],

I do have one "use", but I wouldn't say that it justifies any complexity. I have an entropy provider thingy in development which uses bit[], allowing the user to get N bits of entropy for use in random-number stuff.

But the truth is, I only used bit[] because it was there. It would be no trouble at all to instead return a ubyte[], or some library bit-array implementation in its place.


>nor can I think of any situation where they would be significantly better than a library implementation.

Nor can I.

For that matter, I'm starting to wonder if even a library implementation is strictly necessary. I suspect we could get away with just the existing ubyte[] type, and the following four functions:

#    bool bitTest(ubyte[] array, uint bitNum);
#    bool bitSet(ubyte[] array, uint bitNum);
#    bool bitClear(ubyte[] array, uint bitNum);
#    bool bitToggle(ubyte[] array, uint bitNum);

(where bool is aliased to something other than bit, obviously).

Arcane Jill

Most of code is very OS undependent, mostly only the IO operations are os dependent and also the headers of the excecutables.

For example, if you write a math library, then only the header of this library is OS dependent, and it is quite simple to runtime convert it.

And if this library only uses input-output through D standart libraris, then is is the same situation.

I think it is a good idea.

By the way, what is THE GC problem?


In article <chhhp2$19td$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cheqr4$308q$1@digitaldaemon.com>, Ilya Minkov says...
>
>>Perhaps we could develop our own cross-OS binary format for libraries, and embed a loader in Phobos. The task of this should be to provide both interface and object code on the one hand, and allow the library to use the object code from the main executable. It would not only solve the GC problem, but also all of the plug-in writing problems. DLL is not very adequate, i guess.
>
>Is cross-OS actually what you mean? I don't see how an application running on a Windows OS can run object code compiled and running on a Linus OS. You mean two different-OS PCs networked together? Connected via the internet? What?
>
>I am particularly intrigued by anything which claims to "solve the GC problem". Please could you define "the GC problem", and tell me how such a cross-OS-binary format would solve it? That would be amazing.
>
>Arcane Jill
>
>

Stewart Gordon schrieb:

> Andy Friesen wrote:
> <snip>
> 
>>> This simply means that bits requiere a completely separate infrastructure of the following:
>>>
>>> * bit as a boolean type. Can be placed in a byte or int or whatever.
> 
> 
> Do you mean that if one declares just a bit, not a bit[], it would occupy a byte or four?  IMM, it would make sense to pack multiple bit members of a struct or class into bytes or four-byte blocks.  Moreover, if in a struct, it ought to obey the alignment setting.  (I haven't checked this, and don't know how much impact it would have on existing code.)

Yes, packing adjacent bits together may be done someday as well. However, it is not requiered for a complete and working implmentation. And now single bits are types as well, if i'm not mistaken.

>>> * bit pointer type - consisiting of byte pointer and additional 3 bits offset.
>>> * bit array struct - conceptually consisting of 2 bit pointers for beginning and end. This may also be bit pointer and length, perhaps the range of length can even be limited to save space.
> 
> 
> This idea has been around for a while.  I coded up an implementation on roughly this basis a while back:

I have been around for a while as well. This was how approximately it was intended to be implemented. A couple of years ago, bit pointer was not implemented at all and, there was just a problem that there were outstanding issues in different parts of compiler and the language so that Walter didn't want to deal with it, but the users actively requiered for a bit pointer so that inout bit parameters and such would work. I think we already had templates back then, added due to Daniel Yokomiso developing a template library. I had suggested that a temporary implementation would make a byte pointer out of it, and throw exception if a bit doesn't lie on a byte boundary. So did Walter implement it back then. Now, we still have many other issues outstanding in the language and the compiler.

Thanks for the Implementation. Chances are it can be put to use by Walter. I keep the link for it here for future reference.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/495

> Indeed, I recall from the change log that the current bit pointer implementation allows space to address individual bits, but hasn't implemented the use of it yet.

Ah, interesting.

>> Fair enough.  I'm just not convinced that fixing them would be worth the trouble. :)
>>
>> What's the use case that justifies all this complexity?  I haven't seen any D at all that uses, or even calls for the use of bit[],

Avoid adding another specialization to the templates which contain arrays and may be used on bit?

-eye

In article <chg524$n07$1@digitaldaemon.com>, Ilya Minkov says...
>
>Ben Hinkle schrieb:
>
>> I bet most people don't like bit because of bool. The fact that bits are not addressable is just because bytes are the smallest addressable unit. If bits were addressable I'd have to ask which bit is being addressed - and what about the addresses of the other 7 bits sharing that same address?
>
>This simply means that bits requiere a completely separate infrastructure of the following:
>
>* bit as a boolean type. Can be placed in a byte or int or whatever.
>* bit pointer type - consisiting of byte pointer and additional 3 bits
>offset.
>* bit array struct - conceptually consisting of 2 bit pointers for
>beginning and end. This may also be bit pointer and length, perhaps the
>range of length can even be limited to save space.
>
>This is how it was intended to be implemented. Walter probably just doesn't have enough hands to do so. The latter 2 of these types would not work by the usual DMD types implementation (as now), but simply map separate to corresponding syntaxes. There's probably nothing fancy about it, it just takes some time and power to implement, and the current "implementation" is just a quick hack. The implementation itself can be in the library, the compiler would only have to translate the syntax.

hmm - a pointer to bits should have the same size as pointers to anything else IMO. I want to be able to cast pointers to void* and back without losing information. Pascal had bit arrays (you put the word "packed" in front of the declaration) and they seemed to work fine back when I used Pascal. I don't know if I ever tried taking the address of a packed array in Pascal, though.

Ilya Minkov wrote:
<snip>
> Yes, packing adjacent bits together may be done someday as well. However, it is not requiered for a complete and working implmentation. And now single bits are types as well, if i'm not mistaken.
<snip>

But a clear specification of how bits are held within structs clearly is required.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon schrieb:

> Ilya Minkov wrote:
> <snip>
> 
>> Yes, packing adjacent bits together may be done someday as well. However, it is not requiered for a complete and working implmentation. And now single bits are types as well, if i'm not mistaken.

A typo. This should be bytes, not types.

> <snip>
> 
> But a clear specification of how bits are held within structs clearly is required.

You are right, haven't thought of that. You mean to relace C's bit fields with them?

However, in classes and on stack the layout is left unspecified.

-eye

Ben Hinkle schrieb:

> hmm - a pointer to bits should have the same size as pointers to anything else
> IMO. I want to be able to cast pointers to void* and back without losing
> information. 

Why do you want to be able to cast it to void*?

If you mean it for containers, then i'll have to think it over what kinds of solutions are possible. One of them would be that a cast to void* would new a bit pointer on the heap and copy the original one there, and return a void* which points to it. A cast back would return a bit pointer struct. The leftover place in the struct can be filled with checksum, which can be generated on one cast and checked on another, just to try to make sure that it's not random data. A garbage solution. :>

There is a problem with "walking" such a void*, but you cannot safely walk a pointer if you don't know the size of a type. It looks very differently with void[], which starts to be a real problem.

For templates, a separate solution can be figured out. I have to think over exactly how much trouble it is causing. Perhaps really much.

> Pascal had bit arrays (you put the word "packed" in front of the
> declaration) and they seemed to work fine back when I used Pascal. I don't know
> if I ever tried taking the address of a packed array in Pascal, though.

Oh, was it long ago that i used Delphi. If one declares a packed boolean array, can one take adress of a single element of it? I don't know any longer and don't have Delphi to test here. Perhaps Carlos can test it. And then whether it can be converted to a byte pointer is another question.

-eye