Some Implementation Questions.

greybeard

1. My basic curiosity is whether the PROPGCC creates interpretive code just as the Propeller Tool does OR... does it generate PASM level code that would increase execution speed for anything in the hub.

2. I have browsed the source code and noticed there is code related to debugging SPIN and PASM code. Or.. at least code generated by PROPGCC. I do hope that's where your going. I'm really in the market for a good PASM debugger.

3. I have looked at the CATALINA compiler and found it cumberson. Seems to want to load everything but the kitchen sink. I want to keep things lean. I don't even want to use PRINTF routines except for debugging and some testing purposes. My needs are to send binary data back and forth. Mostly using the serial port but moving into the lan domain soon. I swapping functionality in and out of cogs as situation changes. Serious data collectiona and control decisions done on a host computer as needed.

4 I assume that the linker used represents the latest level of technology. At one time, the linkers would bring in 'All' the functions in the library. Modern linkers just bring in routines that are used by the app. The main reason I don't want to use PRINTF or FPRINTF is that it uses most of the individual routines in the library and can really bloat code.

5. I'll continue to browse the source code but I'll not recompile it. Other things are more pressing right now.


I look forward to working with the App as it develops.

ersmith

greybeard wrote: »

1. My basic curiosity is whether the PROPGCC creates interpretive code just as the Propeller Tool does OR... does it generate PASM level code that would increase execution speed for anything in the hub.

It generates PASM code. In -mcog mode this is executed directly in the 2K memory of the cog. In the more typical LMM mode the PASM code is "running" out of hub memory via a very simple interpreter loop, which basically consists of "fetch the instruction from hub memory and then execute it in cog memory". GCC also caches small loops and recursive functions into something called FCACHE, so that the loop or function stays in cog memory and is entirely executed there.

2. I have browsed the source code and noticed there is code related to debugging SPIN and PASM code. Or.. at least code generated by PROPGCC. I do hope that's where your going. I'm really in the market for a good PASM debugger.

We are working on a port of gdb, but there's no estimated delivery date yet. gdb is really designed for debugging LMM code (i.e. from hub memory), so it probably won't be as much use for debugging cog programs.

4 I assume that the linker used represents the latest level of technology. At one time, the linkers would bring in 'All' the functions in the library. Modern linkers just bring in routines that are used by the app. The main reason I don't want to use PRINTF or FPRINTF is that it uses most of the individual routines in the library and can really bloat code.

We are using the standard GNU linker. If a file is used from the library then all of that file from the library is linked in, but not the rest of the library (except what is used, as you noted for PRINTF).

Eric