BIT

[jpc]

now that you fixed the bug in the bit-acces on word , would it be possible to implement BIT as simple type ? idealy declarations of this type would automatically occupy one bit and the compiler should reserve ram accordingly. so the first 8 bit's declared would occupy just one byte of ram yet be individually accessible .

eventually i would already be happy with the possibility to declare a bit-variable inside an existing type , e.g. var MYSIGNAL : BIT @ mylongint.5
of course i would have to reserve RAM by first declaring mylongint but again , working on bit-level would be more efficient if we could acces individual bits by their own name.

JPC

[zristic]

It complicates life a lot, we have to write new interpretation for each operator, since + will not be the same for byte and for bit vars. Also, there are many controls that will have to be introduced, such as setting bit of a bit variabel. Moreover, passing a bit as a parameter is tricky. Finally, the library structure has to be expanded in order to accept the new type.

A lot of work, is it really worth it?

[jpc]

ok , i accept that it complicate's your life but we are talking about boolean math by the nature of this type. This should not be too complicated , typecasting as such already exists.
My second proposal is possibly less complicated , concerns mainly referencing to exeisting construct except for the automatic reserving of ram .
Anyway , its an idea , thanks for looking at it.

JPC

[gambrose]

Is it complicated to get the compilers to accept a bit for boolean operations i.e. if statements. At the moment

Code: Select all

if(PORTA.F0)

(sorry for the C code in the Pascal forum)
the bit value is first converted to a byte and then this byte is then evaluated as a boolean value. I think this is madness and very complicated.

Thanks for listening to my rant.

[Messenga]

The trick here would be to use the testbit function

if (testbit(PORTA,F0))

[LGR]

I think that they are trying to abandon testbit, clearbit, etc. in favor of direct reference to byte.bit. At least in dsPIC Pascal, there are no test/clear/set procedures.

[Werner]

The trick here would be to use the testbit function

if (testbit(PORTA,F0))

You probably mean:

Code: Select all

if (testbit(PORTA,F0) = 1)

Testbit unfortunately does not return booleans

[zristic]

Testbit unfortunately does not return booleans

TestBit tests a bit. Therefore, it cannot return 255. If you like, you can make the function TestIfBitIsOne that will return 255 and 0.

Anyway, the code

Code: Select all

if TestBit(portb,2) <> 0 then

will generate the same assembly as

Code: Select all

if TestIfBitIsOne(portb,2)  then

[gambrose]

Werner is right it does not return booleans and so if you look at code produced.

first PORTB.2 is turned into a byte value either 1 or 0

Code: Select all

MOVLW	0
BTFSC	PORTB, 2
MOVLW	1
MOVWF	STACK_1

then this value (STACK_1) is evaluated

Code: Select all

MOVLW	255
SUBWF	STACK_1, W
BTFSS	STATUS, Z

all this code code be simplified to

Code: Select all

BTFSS     PORTB, 2

So you can see how this sort of thing can really bulk up the size of your code.

I have every respect for mE's work and enjoy using their tools and compilers. But with them implementing increasing complex libraries i.e. enternet which is very complicated and big I think it is important not to forget to continue to develop the basics that these libraries are built on so in response to your question.

A lot of work, is it really worth it?

I think yes.
Could the Boolean value not be introduced in stages i.e. compiler recognises Boolean expressions for if statements with out having to do a full blown Boolean type?

[LGR]

the bit value is first converted to a byte and then this byte is then evaluated as a boolean value. I think this is madness and very complicated.

This is one of these things where the best way depends on what you are doing. Sometimes you are more interested in execution efficiency than RAM efficiency, in which case this is actually the best way to do it. If you are working with a lot of bits, and are short on RAM, you would be better off working with packed bits, as you describe. I would like to see a type bit (or boolean packed, or whatever) for those situations, but the assembly created will necessarily be longer, and take longer to execute. It will only be worth it in certain specific applications.

[gambrose]

This is one of these things where the best way depends on what you are doing. Sometimes you are more interested in execution efficiency than RAM efficiency, in which case this is actually the best way to do it.

7 instructions is less efficient than 1

even if you have lots of RAM and store your boolean value in it's own byte you still need 3 instructions where one would do.

[LGR]

7 instructions is less efficient than 1

even if you have lots of RAM and store your boolean value in it's own byte you still need 3 instructions where one would do.

To actually perform the operation, you're correct, however the addressing of bits gets a lot more complicated. If, for example, you have an array of 256 bits, the array index has to be split into a 5-bit selector for the bytes, and then a 3-bit selector for the bits. A lot of shifting and masking. But, sometimes it would be worth it. I think that it is a good long-term goal, but I'd wager that the overall number of clock cycles and words of ROM for a typical actual usage would be higher with individual bits, just because of the overhead in addressing.

[gambrose]

I take you point about bit arrays having a lot of overhead.

I still think that bit type could be introduced in stages and having the compiler understand that it didn't need to evaluate a bit as a byte in if and while statements would be a very good start.

[LGR]

I agree that individual bit addressing is a good goal. In certain instances, it's the only way that makes any sense. Particularly on these microcontrollers that are so RAM poor.

[gambrose]

So were agreed then

now we just got to convince mE.