On Wed Aug 19 8:15 , '[email protected]' <[email protected]> sent:
>On Tue Aug 18 13:38 , "[email protected]" sent:
>
>>On Tue Aug 18 11:47 , ThomasK [email protected]> sent:
>
>>>Behaviour in simulavr is now like in M128, means read complete byte,
>>>modify, write complete byte. For the new behaviour we need a new
>>>interface for IO registers, one is clearBit(bitnum), the other
>>>setBit(bitnum), not only read byte: operator char() and write byte:
>>>operator=. And then, of course, for all the hardware units, which have
>>>to provide this, not only a get and set method, but also a getbit/setbit
>>>method or other modifybit(bitval, bitnum).
>>
>>I'd use the names sbi and cbi.
>
>class RWMemoryMembers {
>...
>virtual unsigned char operator=(unsigned char val) =0;
>#ifndef SWIG
>virtual operator unsigned char() const =0 ;
>
>virtual void sbi(unsigned bitnum) { *this= *this | (1
>virtual void cbi(unsigned bitnum) { *this= *this & ~(1
>#endif
>...
>};
>
>I don't understand the need for #ifndef SWIG .
I also don't understand what is trashing my code.
It's not the list server. I get the same results without it.
See attachment.
>To list owner:
It would be nice if the list mechanism inserted a Reply-To: header line.
--
Michael Hennebry
[email protected]
"War is only a hobby."
---- Msg sent via CableONE.net MyMail - http://www.cableone.netclass RWMemoryMembers {
...
virtual unsigned char operator=(unsigned char val) =0;
#ifndef SWIG
virtual operator unsigned char() const =0 ;
virtual void sbi(unsigned bitnum) { *this= *this | (1<<bitnum); }
virtual void cbi(unsigned bitnum) { *this= *this & ~(1<<bitnum); }
#endif
...
};
I don't understand the need for #ifndef SWIG .
_______________________________________________
Simulavr-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/simulavr-devel
