Subject:
|
Re: GNU C wizards?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 4 Jan 1999 19:32:15 GMT
|
Original-From:
|
John A. Tamplin <jat@SAYNOTOSPAMtraveller.com>
|
Viewed:
|
1244 times
|
| |
|
|
On Mon, 4 Jan 1999, dave madden wrote:
> I'd tried doing this, but the generated code (-O6) only infrequently
> reduces to "bset #n,...", and never to "bset #n,@xx:8". (It also
> seemed to allocate/construct stack space for the Bit sometimes...) If
> you need to pass Bit references around, of course, then you have to do
> something like BitVector<T>, but for simple linear code, keeping the
> port backreference and and mask around just make the compiler work
> harder.
GCC has in general done a very good job removing unnecessary code from
templates. You can certainly optimize the generated code further, but you
are getting the facilities of a high-level language in exchange for the
(usually) small losses in performance.
Personally, I generally go for higher levels of abstraction and expect
that the lost performance won't be objectionable.
> Anyway, I kept at it a little longer last night and got the templates
> working in the "Port6.Bit3 = true; if (Port6.Bit5) do_something( );"
> mode. The DDR access is clumsier because, as you note, the register
> is write-only, so you have to keep a shadow copy around. I'll take
> another shot at expressing things as arrays and post the best version
> I can come up with.
Since you are creating a separate object for the ports, you should put
the shadows there.
> =>I don't think you need to use asm - the compiler will use those
> =>instructions. Just do it in C++:
> => value|=(1<<bit) to set
> => value&= ~(1<<bit) to clear
>
> I saw "bset" and "bclr" generated for these types of statements in
> some places, but my test case (Port6[3] = true;) resulted in
>
> mov.b @0xffbb,r2l ; (this is from memory...)
> or.b #x08,r2l
> mov.b r2l,@0xffbb
>
> Wastes space, and worse, throws off the timing. (Although the LCD
> driver doesn't seem to be *that* sensitive to those delay loops
> getting shortened.)
Hmm, you are correct. It does seem to reliably generate btst instructions
for things like if(*p & 4) ..., but the set/clear aren't always. That should
be something that can be fixed in the compiler, possibly creating a peephole
optimization.
> BTW, won't the "-r" option to gnu-ld work for your load-on-the-fly
> problem? The info page says:
The problem is that it doesn't do any relocation -- it just basically
combines all the .o files into a single file. What I want is for it to
relocate everything that is PC-relative and only leave the absolute
relocations. The kernel will have to do at least those anyway, so I
guess it isn't too much more work to do all of them there.
John A. Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 1 Reply:
 | | H8 bit operations (was Re: GNU C wizards?)
|
| (...) After looking into it further, if the compiler has the address in a register (or will use it more than once so it will load it in a register), it does use the bset/bclr instructions. However, there is this in h8300.md: ;; Bitfield operations (...) (25 years ago, 4-Jan-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: GNU C wizards?
|
| On Sun, 3 Jan 1999, I wrote: =>> =>> Are there any GNU C/C++ wizards out there? I'm trying to write an =>> asm() statement to describe the H8's bclr/bset instructions. I have a =>> wicked sweet tooth for C++ syntactic sugar, and I'd like to be able (...) (25 years ago, 4-Jan-99, to lugnet.robotics)
|
6 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
