Don't have an account? Register now to chat, post, use our tools, and much more.
Latest Headlines
Online Users
There are 117 users online: 7 members, 75 guests and 35 bots.
Members: Ashbad, CalebHansberry, HOMER-16, rfdave, xologist.
Bots: VoilaBot (1), Spinn3r (1), MSN/Bing (1), Magpie Crawler (3), VoilaBot (8), Googlebot (20), MSN/Bing (1).
RSS & Social Media
SAX
You must log in to view the SAX chat widget
|
| Author |
Message |
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
 Posted: 10 Aug 2012 12:47:21 am Post subject: SuperH RS and IL memory Exploration |
 |
|
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?
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
| Posted: 10 Aug 2012 08:32:04 am Post subject: |
|
|
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).
_________________
 
Ask questions the smart way · タリ |
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 10 Aug 2012 12:05:01 pm Post subject: |
|
|
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?
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10234
Location: A galaxy far far away......
|
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
| Posted: 10 Aug 2012 03:23:20 pm Post subject: |
|
|
| 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.
_________________
Ask questions the smart way · タリ |
|
| Back to top |
|
|
elfprince13
OVER NINE THOUSAND!
Joined: 23 May 2005
Posts: 10234
Location: A galaxy far far away......
|
|
| Back to top |
|
|
KermMartian
Site Admin
Joined: 14 Mar 2005
Posts: 55763
Location: Earth, Sol, Milky Way
|
| Posted: 10 Aug 2012 04:03:34 pm Post subject: |
|
|
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.
_________________
 
 
 |
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 10 Aug 2012 05:10:57 pm Post subject: |
|
|
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?
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
| Posted: 10 Aug 2012 05:45:08 pm Post subject: |
|
|
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.
_________________
Ask questions the smart way · タリ |
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 10 Aug 2012 05:50:23 pm Post subject: |
|
|
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).
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 11 Aug 2012 02:04:42 am Post subject: |
|
|
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.
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
| Posted: 12 Aug 2012 07:46:42 pm Post subject: |
|
|
| 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.
_________________
Ask questions the smart way · タリ |
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 13 Aug 2012 01:32:49 am Post subject: |
|
|
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.
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
Tari
Systems Integrator
Joined: 03 Jul 2006
Posts: 2113
Location: Always-winter, Michigan
|
| Posted: 13 Aug 2012 12:55:58 pm Post subject: |
|
|
| 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).
_________________
Ask questions the smart way · タリ |
|
| Back to top |
|
|
AHelper
LONG LIVE COMICTECH
Joined: 30 Jan 2011
Posts: 1661
Location: Aufhelperstan, Utopian Republic
|
| Posted: 13 Aug 2012 01:00:29 pm Post subject: |
|
|
(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)
_________________
°ᴥ° Get Lucky
<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol." |
|
| Back to top |
|
|
|
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
|
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
|
© Copyright 2000-2013 Cemetech & Kerm Martian :: Page Execution Time: 0.038561 seconds.
|
![[t]](/forum/templates/Cemetech6/images/twitter.png)
![[t]](/forum/templates/Cemetech6/images/fb.png)
![[RSS]](/forum/templates/Cemetech6/images/rss.png)
