@ersmith said:
... so at least in theory someone could hook up multiple SD cards to a single P2.
I've done it. I've bulk copied files from one card to another as one of my test programs ... Or at least I tried, it was a while back and I don't remember the outcome to be honest.
EDIT2: Err, maybe this is all a rubbish idea? I see the struct __using("filesys/block/sdmm.cc") *SDMM; is located in _sdmm_open() function. That's where things are different.
Ada/Eric,
Just thinking about the recent relocation of _sdmm_open() and co. for init of the inbuilt driver. In my driver, I've been happily placing that functionality all directly into the driver source file. It feels tidy to me ... I'm thinking the same could be done here as example for any future third-party driver endeavours. Then all drivers internally get the same API layout.
Only different becomes the whereabouts a driver gets loaded. With third-party it is explicitly a struct __using() in the user code as opposed to buried in the headers.
EDIT: On achieving identical API, splitting off _vfs_open_sdcardx() from _sdmm_open() would be in order. While _sdmm_open() would go into the driver, the legacy functions of _vfs_open_sdcard() and _vfs_open_sdcardx() could go back where they came from. And sdmm_vfs.c would be no more.
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored __asm volatile {} code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.
I'm not seeing any way to do it without throwing away all locality. Also, I need to keep parameter passing feature of function calling so can't use a global __pasm code section.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
@evanh said:
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored __asm volatile {} code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.
I don't think there'd be much advantage to that, would there? a SETQ / RDLONG will fetch the parameters at 1 cycle/long once it gets going, the same as the time taken to load them with the FCACHE invocation.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
I see you did figure out how to get __pasm going; it is pretty straightforward, and I think there are examples in the flexprop samples directory. It is an area where we could use more documentation.
@ersmith said:
I don't think there'd be much advantage to that, would there? a SETQ / RDLONG will fetch the parameters at 1 cycle/long once it gets going, the same as the time taken to load them with the FCACHE invocation.
Right, the plan was to make it a single fast burst copy. I was also hoping to find other additional hand optimisations along the way ... alas Ada pointed out my big oversight in doing the merge in the first place. Which made me decide I was chasing imaginary savings.
So I didn't even bother to find out why there was some massive overhead occurring in the first attempt.
Next idea, is there any easy way to port include/filesys/fatfs/ff.c to a spin2 object that Pnut can compile?
I've already ported the 4-bit SD mode driver to work with FSRW and co but those handlers are slow and old in comparison. So slow that Flexspin's SPI mode is a lot faster.
@evanh said:
Next idea, is there any easy way to port include/filesys/fatfs/ff.c to a spin2 object that Pnut can compile?
That's a good question. At one I was working on a "wrapper" mode that would produce Spin wrappers for the generated assembly code, with the intention that PNut could compile these -- this is triggered by the -w option of flexspin. But it never got finished, so I'm sure it's bit-rotted. You could try starting with the -w output and manually fixing it up, depending on how many entry points were required. The whole mechanism was intended to run in another COG though (it was originally for P1 where the Spin cog just isn't available) so it may or may not be useful for you. And -w is probably only practical for small objects, which ff.c isn't .
Hmm, it chews a lot of cogRAM, 105 longwords, that wouldn't really have any place to hide other than consuming almost half of the inline assembly caching space. I guess that's not an impossible layout.
Of that there is 9 var, 5 arg and 18 local registers. I know Pnut has 16 registers that are used for inline scratch space but I wouldn't know if they have any symbolic names. Not a big loss really.
@evanh said:
I had to compile from fatfs.cc to satisfy dependencies but I have got something - A 10,000 line source file. I'll look at it tomorrow.
Ugh, that sounds like it's probably a mess. I hate to say it, but the odds of it working are very low, given how incomplete the -w code is. You may be better off translating it by hand.
I tried to use Google's new AI mode and upload source file but it goes out to lunch on each attempt - Javascript Smile that's entirely unneeded. I looked at Claude too but that appears to need an account setup before it'll do anything.
EDIT: Ah, and ChatGPT won't take an upload without an account either, I wonder if that's Google's hang-up as well.
Comments
I've done it. I've bulk copied files from one card to another as one of my test programs ... Or at least I tried, it was a while back and I don't remember the outcome to be honest.
EDIT2: Err, maybe this is all a rubbish idea? I see the
struct __using("filesys/block/sdmm.cc") *SDMM;is located in _sdmm_open() function. That's where things are different.Ada/Eric,
Just thinking about the recent relocation of _sdmm_open() and co. for init of the inbuilt driver. In my driver, I've been happily placing that functionality all directly into the driver source file. It feels tidy to me ... I'm thinking the same could be done here as example for any future third-party driver endeavours. Then all drivers internally get the same API layout.
Only different becomes the whereabouts a driver gets loaded. With third-party it is explicitly a
struct __using()in the user code as opposed to buried in the headers.EDIT: On achieving identical API, splitting off _vfs_open_sdcardx() from _sdmm_open() would be in order. While _sdmm_open() would go into the driver, the legacy functions of _vfs_open_sdcard() and _vfs_open_sdcardx() could go back where they came from. And sdmm_vfs.c would be no more.
Eric,
In the 4-bit SD card driver, in the name of performance, I'm thinking about the idea of patching the presets directly into the hubRAM stored
__asm volatile {}code section. This is instead of the current approach of prefilling a structure and then copying the presets from there to cogRAM upon each inline entrance.I'm not seeing any way to do it without throwing away all locality. Also, I need to keep parameter passing feature of function calling so can't use a global __pasm code section.
EDIT: I guess, what I really need from the parameter passing is its efficient register passing. A global __pasm section could probably be coded to be loaded like fcache and also use a specific set of registers for parameters too ...?
On that note I've never seen how to define a __pasm code section in C. There's no examples that I've seen and the docs don't say much I don't think.
Never mind, I took a stab and got it right. Tested and working as expected.
__pasm { testpasm mov pr0, #456 ret }Used an inline call to branch ...
... pr0 = 123; printf("testpasm=%d\n", pr0); __asm { call #testpasm } printf("testpasm=%d\n", pr0); ...Terminal output:
Here’s a crazy question …
Would it be possible to mix spin2 and basic code within one c file?
Sorta like the way you have pasm blocks?
Just wondering how impossible that would be…. Or, maybe already possible?
Guess could include as objects and be sorta the same thing?
That's what you need to do. Can't have different languages in the same object for various reasons.
I don't think there'd be much advantage to that, would there? a
SETQ / RDLONGwill fetch the parameters at 1 cycle/long once it gets going, the same as the time taken to load them with the FCACHE invocation.I see you did figure out how to get __pasm going; it is pretty straightforward, and I think there are examples in the flexprop samples directory. It is an area where we could use more documentation.
Things can get complicated with pasm in c…
Think sometimes gets loaded into cog first and other times just run via hubexec right?
Right, the plan was to make it a single fast burst copy. I was also hoping to find other additional hand optimisations along the way ... alas Ada pointed out my big oversight in doing the merge in the first place. Which made me decide I was chasing imaginary savings.
So I didn't even bother to find out why there was some massive overhead occurring in the first attempt.
Next idea, is there any easy way to port
include/filesys/fatfs/ff.cto a spin2 object that Pnut can compile?I've already ported the 4-bit SD mode driver to work with FSRW and co but those handlers are slow and old in comparison. So slow that Flexspin's SPI mode is a lot faster.
That's a good question. At one I was working on a "wrapper" mode that would produce Spin wrappers for the generated assembly code, with the intention that PNut could compile these -- this is triggered by the
.
-woption of flexspin. But it never got finished, so I'm sure it's bit-rotted. You could try starting with the-woutput and manually fixing it up, depending on how many entry points were required. The whole mechanism was intended to run in another COG though (it was originally for P1 where the Spin cog just isn't available) so it may or may not be useful for you. And-wis probably only practical for small objects, which ff.c isn'tI had to compile from fatfs.cc to satisfy dependencies but I have got something - A 10,000 line source file. I'll look at it tomorrow.
Hmm, it chews a lot of cogRAM, 105 longwords, that wouldn't really have any place to hide other than consuming almost half of the inline assembly caching space. I guess that's not an impossible layout.
Of that there is 9
var, 5argand 18localregisters. I know Pnut has 16 registers that are used for inline scratch space but I wouldn't know if they have any symbolic names. Not a big loss really.Ugh, that sounds like it's probably a mess. I hate to say it, but the odds of it working are very low, given how incomplete the
-wcode is. You may be better off translating it by hand.I tried to use Google's new AI mode and upload source file but it goes out to lunch on each attempt - Javascript Smile that's entirely unneeded. I looked at Claude too but that appears to need an account setup before it'll do anything.
EDIT: Ah, and ChatGPT won't take an upload without an account either, I wonder if that's Google's hang-up as well.