22.03.2018, 20:26, "Christopher Head" <open...@chead.ca>: > Yes please! If I may make a suggestion, however: I am not sure what you > planned to put in the rest of the dictionary
I planned to essentially reflect the FreeRTOS target description struct and load it from C. I even thought of partial automation of key parsing by using gperf to convers strings to enums. 22.03.2018, 20:26, "Christopher Head" <open...@chead.ca>: > 2. TCL defines a proc. When C needs a thread’s registers, it calls the proc. > The proc does whatever it needs to (probably lots of mem2array calls) and then > returns the registers to C in some way (perhaps returns a dictionary or > something). > > I would really like to see #2. It has the advantage that different threads can > have different stack frame layouts (e.g., some threads have floating point > registers and some don’t, some have some memory protection data saved on the > stack and others don’t, or whatever more complex examples you care to > make up), and only TCL, not C, needs to change to accommodate such things. > It could even handle ports that don’t store their registers on the stack at > all, but rather in something vaguely like a traditional x86 TSS! My personal opinion is that I dislike dynamically typed languages, especially ones where everything is a string. Putting actual "business logic" into TCL would make code way more error-prone. I think as initial step it would be better to reuse existing C code and just go with struct reflection and using TCL as simple data input format. As for x86 TSS, I think it's C that should be changed here — maybe adding the concept of task states to some internal API. 22.03.2018, 20:26, "Christopher Head" <open...@chead.ca>: > Taking this even further, what if the business of enumerating threads were > also done by TCL? It would shorten the development cycle of ports to new > RTOSs as well as just new ports. > > I don’t suspect that any of this work is so performance-critical that using > TCL would slow it down top much. I would suspect so — imagine single-stepping in a program with 10 tasks or so. Overall, my biggest problem with a lot of TCL code is that it's error prone and almost no static checks can be done. Any kind of refactoring would be hard to do and would potentially break something. There are tests but the efforts required to cover 100% of code just to catch some weird type error make the notion not so rational. Regards, Vlad Ivanov ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
