[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-libc-dev] [RFC] Sleeping BOD API
From: |
Weddington, Eric |
Subject: |
RE: [avr-libc-dev] [RFC] Sleeping BOD API |
Date: |
Fri, 6 Feb 2009 16:09:57 -0700 |
> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Friday, February 06, 2009 3:55 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] Sleeping BOD API
>
>
> What I like about your piece of code is that it would automagically
> move from IN/OUT to LDS/STS when needed.
>
> What I don't like about it is that the actual action is made ``behind
> the scene'' so it's pretty unobvious how it works, and nobody can
> really tell you whether that semi abuse will do all the time. It
> somewhat reminds me my old Z80 days when it was pretty standard to
> have "self-modifying code"
I would say that that comparison is unfair. This is nothing so dangerous as
self-modifying code. Just because both are unobvious, doesn't make them
equivalent situations.
> but was so completely
> unobvious that anyone not acquainted with the technique would not get
> the slightest idea about how it actually worked.
Strangely, I got the inspiration from working with Anatoly so long now, and
seeing what gets done on the back-end code of gcc. The idea is that you want to
make the compiler do as much as possible. If it doesn't matter where something
should go (like a scratch register), then let the compiler pick it for you as
it knows more about the state of the code. My job is then to tell the compiler
what constraints it needs to work with and just the bare minimum of
instructions that is absolutely needed, so that it can make all the right
selections. Any more, and then you start taking over the job of the compiler,
which is never good.
So, of course, it will work "behind the scenes", because the compiler itself is
doing the work.
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, (continued)
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Dmitry K., 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Message not available
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- Message not available
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API,
Weddington, Eric <=
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/06
- RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/07
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Joerg Wunsch, 2009/02/07
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Krzysztof Kościuszkiewicz, 2009/02/09
- Re: [avr-libc-dev] [RFC] Sleeping BOD API, Krzysztof Kościuszkiewicz, 2009/02/09
RE: [avr-libc-dev] [RFC] Sleeping BOD API, Weddington, Eric, 2009/02/06
Re: [avr-libc-dev] [RFC] Sleeping BOD API, Bob Paddock, 2009/02/09
Re: [avr-libc-dev] [RFC] Sleeping BOD API, Bob Paddock, 2009/02/12