avr-libc-dev
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]