I had never heard of the GCC label variable, so I had to google it... wow, I learned something new tonight!
https://stackoverflow.com/questions/1777990/is-it-possible-to-store-the-address-of-a-label-in-a-variable-and-use-goto-to-jum On Tue, Jun 30, 2020 at 8:57 PM Jon Wolfe via TriEmbed < [email protected]> wrote: > > > There is a trick you can use with gcc that is a non-standard C construct > where you can use ‘goto’ and give it a variable containing the address of a > label. You then create an array of label address and you can then > dynamically index that array to jump to various locations. I’ve seen it > used as an optimization technique, and you can also have more control over > the program flow, though it is using the infamous keyword, Essentially > though it end up looking pretty much like a switch-case. > > > > That is really odd about that gcc bug. It’s not like I’ve never seen > them, but 99.9% of the time when I thought I had found a compiler bug in > C/C++, it turns out to be something else. (hafl the time one of those > things that disappears with a “clean/rebuild all”) I remember the Arduino > /AVR/gcc linker used to have a bug related to 8-bit AVR chips that had more > than 64KB of flash memory, such as the ATMega 1284. Those chips address by > 16 bit words not bytes, so 128kb of flash is accessible without trick likes > far pointers, but the linker would mess up the address calculations > sometimes I think for interrupt handlers or functions called by interrupt > handlers that crossed the 64kb boundary. > > > > > > *From: *Huan Truong via TriEmbed <[email protected]> > *Sent: *Tuesday, June 30, 2020 12:48 PM > *To: *Brian <[email protected]> > *Cc: *Triangle Embedded Computing Discussion <[email protected]> > *Subject: *Re: [TriEmbed] Hacking a fake vintage radio (with Arduino + Pi > 0) > > > Oh yeah, that explains my issue. I definitely ran into that issue > where I have checked and had no reason to believe I was doing > something wrong, yet, when I evacuated each switch to a function, the > switch worked correctly. But neither scoping with an anonymous scope > nor renaming the variables work. > > The reason I used the switch was that I read on stackoverflow at one > point and someone said that we should use switches instead of elseifs > when we have a lot of cases. Then, using switches, the compiler will > be able to (at some point) create a lookup table for you so it's > faster. I doubt that was what happening at least on the Arduino case. > You'll need a giant lookup table which the uCs don't have memory for. > I suspect that in a lot of cases, using switches is probably just as > slow as using elseifs. Now as I see that it is so buggy, I probably > will not use switches, at least on Arduino. > > Cheers, > - Huan. > > On Tue, Jun 30, 2020 at 9:23 AM Brian via TriEmbed > <[email protected]> wrote: > > > > Side note: > > > > The arduino compiler has bugs in how it handles switch statements. I've > > run into situations lately where the order of the case statements matter > > (which it never should); cases are completely ignored, etc. > > > > I believe it may be tied to the use of local scoping within a case, e.g.: > > > > switch(thing) { > > case 1: > > { > > // stuff with case-local scope > > } > > break; > > } > > > > Syntactically- and semantically-correct code has proven to generate > > incorrect runtime results. > > > > I haven't had time/motivation to submit a bug report, but I should do > > that. At any rate, a potential workaround is to reorder your cases. > > > > -B > > > > On 6/24/20 9:51 PM, Huan Truong via TriEmbed wrote: > > > Thanks Pete! > > > > > > I feel like there was something really mysterious about the switch > statement. Even if I pasted the whole blocks of code of each function I > would have called to the {} inside a case, the code still wouldn’t work. > That baffled me by a mile. > > > > > > But yeah, I spent way too much time on the project that I’m > comfortable with the idea of not understanding some of it now. The watchdog > timer code was baffling too. > > > > > > Please excuse my typos, sent from phone. > > > > > > On Jun 24, 2020, at 10:14 AM, Pete Soper via TriEmbed < > [email protected]> wrote: > > > > > > What a beautifully presented adventure. Loved reading it. And when > you say a problem "could be bad" you make your point. :-) (meant as a "find > Waldo" exercise for alert readers) > > > > > > Hadn't heard of "kev" or any other Arduino emulator for that matter. > That aspect was interesting too. > > > > > > The other issue with redeclaration of the vars local to the switch > statement is that they literally don't exist outside it, so communicating > their values outside the block would be difficult. :-) In general, every {} > defines a local scope in C/C++ and you can declare variables inside that > scope but they cease to be defined outside the scope. The scope outside any > {} (aka "global") or vars declared "static" can avoid this issue but not > the redefine issue. > > > > > > Thanks for sharing this! > > > > > > Pete > > > > > > > > >> On 6/24/20 12:43 PM, Huan Truong via TriEmbed wrote: > > >> This has taken me way more time than I thought, but finishing this > > >> retrofit is a big achievement for me. It's really silly and serves > > >> exactly no purpose other than RE'ing something no one cares about. So > > >> I just want to share for some shits and giggles. > > >> > > >> > http://www.tnhh.net/posts/adventures-hacking-fake-vivitar-vintage-radio.html > > >> > > >> > > >> > > >> > > >> > > > > > > _______________________________________________ > > > Triangle, NC Embedded Computing mailing list > > > > > > To post message: [email protected] > > > List info: > http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > > > TriEmbed web site: http://TriEmbed.org > > > To unsubscribe, click link and send a blank message: mailto: > [email protected]?subject=unsubscribe > > > > > > > > > _______________________________________________ > > > Triangle, NC Embedded Computing mailing list > > > > > > To post message: [email protected] > > > List info: > http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > > > TriEmbed web site: http://TriEmbed.org > > > To unsubscribe, click link and send a blank message: mailto: > [email protected]?subject=unsubscribe > > > > > > > > > _______________________________________________ > > Triangle, NC Embedded Computing mailing list > > > > To post message: [email protected] > > List info: > http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > > TriEmbed web site: http://TriEmbed.org > > To unsubscribe, click link and send a blank message: mailto: > [email protected]?subject=unsubscribe > > > > > -- > > Huan Truong > www tnhh.net / twitter @huant > > _______________________________________________ > Triangle, NC Embedded Computing mailing list > > To post message: [email protected] > List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > TriEmbed web site: http://TriEmbed.org > To unsubscribe, click link and send a blank message: mailto: > [email protected]?subject=unsubscribe > > _______________________________________________ > Triangle, NC Embedded Computing mailing list > > To post message: [email protected] > List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org > TriEmbed web site: http://TriEmbed.org > To unsubscribe, click link and send a blank message: mailto: > [email protected]?subject=unsubscribe > >
_______________________________________________ Triangle, NC Embedded Computing mailing list To post message: [email protected] List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org TriEmbed web site: http://TriEmbed.org To unsubscribe, click link and send a blank message: mailto:[email protected]?subject=unsubscribe
