Well, I am seeing that the Prizm has these buffers from the 7730/6624 chips. There's a 16KB IL buffer for instruction storage, containing 4 pages. Does anyone know what this is intended for?

I also see this RS memory, used to store instructions or data. It is 2KB in size for the 7730, and reported 16KB for the 7305 (Prizm) in Simon's chm.

I know nothing about what either of these are supposed to do. Does anyone have any documentation on them? Or has/can anyone experiment on them?
It would help if you could point out exactly where you see these things mentioned. Which manual and what page.
A cursory look at the SH7730 hardware manual doesn't show anything matching your terminology, but I might guess that the "IL buffer" is the ITLB?

EDIT: found it. The IL memory region is comparable to L1 memories on other SoCs. It's documented in section 9 of the SH7730 hardware manual. If it's configured in a way conducive to our needs, performance can be improved by executing code from the IL region as well as using it for scratch space (perhaps even placing our stack pointer in that region).
Well, I did say already that it is in Simon's chm. It doesn't have page numbers, but it is under fx-CG 20 -> Registers, MPU.

Ok, that makes sense about the IL ram. Is there any info about RS memory? Are the two buffers used together?
I would be somewhat surprised if you had control over the instruction cache, even in assembly language.
elfprince13 wrote:
I would be somewhat surprised if you had control over the instruction cache, even in assembly language.
It's not a cache, just L1 memory. On embedded system like this, it's fairly common to have L1 memory instead of cache, under the theory that the user can identify hot sections at compile-time better than the processor can at runtime (and it simplifies the hardware). Especially in a non-multiprocessing system, it can avoid evicting things from caches needlessly (because nothing gets automatically evicted).
Compare to the Blackfins I've been using, which allow 16k of the L1 memory to switch between SRAM and cache modes while running.
Interesting, that seems reasonably helpful.
Are there compiler keywords or qualifiers to tag items that should be in L1, or do you have to manually manage the memory from within your program? Either with the Blackfin and/or the SH chips, I should specify.
So the compiler or the programmer must manually put code into the L1 cache? The CPU doesn't do anything on its own? Makes sense. Do you know how you would go about using it? I know about the addresses for each page, so would memcpy'ing a function (relocatable) to a page and executing it be the intended usage? Or is it handled a bit by gcc?
You'll usually handle this sort of thing with the linker. Add a section annotation to the function, and let the CRT handle setup. Assuming the linker is configured to place IL.* in fast memory:
Code:
int hot_code(int *a, int b, int c, int d) __attribute__((section("IL.text")))
{
    *a = b*c+d;
}

It also makes sense to do this with hot data:

Code:
const float sqrt_lut[256] __attribute__((section("IL.rodata"))) = {
    1,
    1.41421,
    1.73205,
    2,
    2.23607,
    2.44949,
    2.64575,
    2.82843,
    ...
};

If somebody can confirm that this memory is generally safe to use (writing to it doesn't crash the system, it doesn't get clobbered by syscalls, etc) I can plan to add support for this to our linker script and CRT.
How would I test that? Should I set the pages to something, call syscalls, run system addins, then check to see if it was changed? I also need to make sure it doesn't get wiped on power down (soft, not hard).
Yes, that sounds like a reasonable approach.
I have verified that the OS doesn't touch the IL cache. Here is what I did to check. Knowing that the cache exists as 4 pages from 0xE5200000 to 0xE5203FFF. I did memset(0xE5200000, 0x55, 0x3FFF); and verified that it all wrote. I exit the addin, run Link and connect to the PC, do file ops, disconnect. I then go into the file manager and view images. I then start graphing (testing math and drawing). I ran eActivity and edited a file.

I reran my addin and used memcmp to verify that the IL cache still read 0x55 for all 0x3FFF bytes, and it passed. Reading the docs, the hardware isn't preserved when you power down the SuperH. I turned off the calc, back on and reran the addin, and the cache was wiped as expected.

I didn't see the docs say that the IL memory should be reset to a specific value, and have verified that it isn't 0 when reset.

Also, the following must be noted. Once you copy instructions to the IL cache, you must execute the following asm:
Code:
SYNCO
ICBI @Rn
Where the jump target is inside the IL memory. I don't know how to properly copy code to the cache and execute the required asm, so my testing ends here for the IL cache. I will test the RS cache later on.
AHelper wrote:
Also, the following must be noted. Once you copy instructions to the IL cache, you must execute the following asm:
Code:
SYNCO
ICBI @Rn
Where the jump target is inside the IL memory. I don't know how to properly copy code to the cache and execute the required asm, so my testing ends here for the IL cache. I will test the RS cache later on.
That's not a jump, that's Invalidate Cache Block, Instruction. Combined with the synco, that's a memory barrier to ensure the CPU's view of memory is consistent with what it actually is.

EDIT: 30 minutes later..
I successfully ran this under the Renesas simulator, and it executed square() from IL memory:

Code:
#include <machine.h>

typedef int (*il_reloc)(int);

int square(int x) {
   return x * x;
}

void init_IL_section(const void *src, unsigned n) {   
   memcpy((void *)0xE5200000, src, n);
   // GCC version
   /*asm("synco\n\t"
      "icbi @%0" : "=r"(src));*/
   // Renesas (Hitachi) version
   synco();
   icbi(src);
}

void main(void)
{
   int r = 0;
   il_reloc doStuff = (il_reloc)0xE5200000;
   init_IL_section(square, 64);
   
   r += doStuff(4);
   r += doStuff(20);
}
I'll start looking at adding the relevant sections to libfxcg's linker script and crt tomorrow, probably.
Great work on getting it testing! A speed test should be done with executing in the ROM using the RAM vs. executing in IL using the IL as RAM. Before you mentioned doing '__attribute__((section("IL.text"))) ' to put the code in the IL. Does it manage putting multiple functions in the IL memory? If it will give memory errors when compiling/linking (writing a function too big for a page in the IL), is there a way that you can specify the page you want the function in so you can be sure that other pages are free to use as scratch ram?

Also, the RS memory shouldn't be touched as it is the memory used for bringing the calc into and out of sleep since it persists even when off.
AHelper wrote:
Before you mentioned doing '__attribute__((section("IL.text"))) ' to put the code in the IL. Does it manage putting multiple functions in the IL memory?
Yes. Not even necessarily code, but any data you specify.

AHelper wrote:
If it will give memory errors when compiling/linking (writing a function too big for a page in the IL), is there a way that you can specify the page you want the function in so you can be sure that other pages are free to use as scratch ram?
I'll see about specifying sections that are mapped to specific pages, but just saying section("IL.text") should place an object in the first available IL space. When using IL as scratch memory, don't just throw pointers at it; you should declare a chunk of memory with the correct section attribute. I think I can declare subsections in the linker to provide mappings for specific pages, though (since doing several operations at once from the same page introduces access latency).
(Reading 1 instruction from IL memory takes 1 clock cycle)

Will there be a function to copy the functions/data to IL memory? I say this because IL is not preserved and data must be copied back if the prizm powers down (run an add-in, hit MENU, the calc auto powers off)
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement