Kirk Wallace wrote:
> [snip]
> Sorry for rattling the cage.
>
> What I am trying to do is learn enough C to be able to evaluate what the
> code is trying to do. Also, to clarify, I added everything after all of
> the //'s, therefore they carry no weight.
>
> For the issue of whether operator precedence trumps short circuit, I
> suppose that is up to what gcc was programed to do, so I could reference
> gcc. Or, I could just write some code to test the different scenarios.
>
> But... if
> " if(new_in&& new_in != last_in) {"
> tests for an edge in the the proper direction, why does the previous
> line normalize the edge?
> " if(in_edge) new_in = ! new_in;"
> or did I get this wrong too?
>
There is a fundamental difference between operator precedence and
short-circuit evaluation. Actually several, but here's one important
one. Operator precedence is something that is determined at compile
time. Short-circuit evaluation is done at run-time, and is data dependent.
Normalizing the edge is done so that the test can always look for new_in
to be "true". If you have asked to invert the sense of the input, then
new_in will be true when the HAL pin is false.
Note that there will be a spurious edge detected if you change the
invert parameter while the input pin is 0. In that case, last_in will
be 0, new_in will be 1 (since it is now supposed to invert), and so the
test will be true (new_in is true, so the second half new_in!=last_in
will be evaluated and is also true).
> Somehow I got the impression that comp needed to have all variables
> declared in the top portion of the file, and that comp stripped off the
> top and placed the variables as needed.
That is true for HAL pins. You can still have local variables in
functions, as well as other variables declared after the HAL-related I/O
and data declarations.
> I also found that "comp
> --compile foobar" creates a file "foobar.c" which might provide some
> insight into this. It's like I see what might be a trunk, but I am not
> seeing the elephant. I just need to be patient and look for it.
>
(I thought that was --preprocess ...)
Looking at the code generated by comp may not be the best way to
understand what's going on. There is no reason for it to be
"human-readable", only for it to work. Machine-generated code can be ugly.
- Steve
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
