Register

TLB operation safety

Discuss anything related to calculators. For specific help on certain games/programs check the Released Projects subforum.
Senior Member
User avatar
Posts: 594
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750 G II, Casio fx-9750 G II (SH4), Casio fx-9860G, Casio fx-9860 G SD, Casio fx-9860G Slim, Casio fx-9860 GII SD, Casio fx-9860 GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG 20, Casio Classpad fx-cp400, Casio fx-CG 50

Re: TLB operation safety

Postby SimonLothar » Fri Jul 22, 2016 8:59 pm

lephe wrote:...which means it's an instruction access rather than a data access : possibly it may matter ?).
Though it is possible to read data from virtualized ROM, I did not manage to run code in virtualized RAM.

// Running code in physical RAM works:
*(unsigned int*)0x88040000 = 0x000BE056; // RTS MOV #h'56, r0
result = (*(int(*)(void))0x88040000)();

// Running code in virtualized RAM fails:
*(unsigned int*)0x08100218 = 0x000BE067; // RTS MOV #h'67, r0
result = (*(int(*)(void))0x08100218)(); // This leads to a system error
I'll be back!

Member
User avatar
Posts: 22
Joined: Fri Aug 21, 2015 11:54 am
Calculators: Casio fx-9860G, Casio fx-9860 GII, Casio fx-CG 50

Re: TLB operation safety

Postby lephe » Fri Jul 22, 2016 9:51 pm

I think I experimented this RAM-execution problem in early stages of development. I believe this was also in Kristaba's work (some of it being my starting point long ago). It is implicitly solved by the documentation demanding the vbr to reside in P1 or P2 space. Regarding my current errors, it should definitely be data access.

The MENU-key functionality is implicitly disabled the use of my own keyboard driver instead of GetKey() and related (for some reason the add-in aims at being free-standing). The system has virtually no opportunity to do any task-switching.

I'll try to workaround this issue by having the system load the entire TLB contents before setting up my interrupt handler. Reading the instruction data seems to work fine, I'll just hope the system will fill the three ways before overwriting existing entries, thus allowing virtualization of large add-ins (at least until 384k because the 8k static RAM messes up the thing).

Having this issue appearing when overwriting the system's vbr value leads me to think that the system actually handles TLB misses, at least some of the time. On the other hand, the 512k-limit for add-ins corresponds to the amount of memory, which can be mapped by the TLB at a given time. I know Kristaba did some interrupt handler disassembling, I'll ask for the TLB miss handler if I ever run into him.

Thanks for your help ! :D

Senior Member
User avatar
Posts: 594
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750 G II, Casio fx-9750 G II (SH4), Casio fx-9860G, Casio fx-9860 G SD, Casio fx-9860G Slim, Casio fx-9860 GII SD, Casio fx-9860 GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG 20, Casio Classpad fx-cp400, Casio fx-CG 50

Re: TLB operation safety

Postby SimonLothar » Sat Jul 23, 2016 12:47 pm

You raised my interest in TLB-things.
I tried Hmem_SetMMU (0x03FA) ... and failed.
Then I tried a syscall for reading the TLB-table (0x3F8; TLB_address_read) ... and failed, too.
It turned out, that certain TLB-syscalls (f. i. Hmem_SetMMU) are not properly implemented with fx9860-(SH-4)-calculators/OSes any more.

A bit concerned by this, I had a closer look:
At least the following syscalls are no longer supported with SH-4-based fx9xx0 calculators: Show
0x0017, 0x0019, 0x0037, 0x0038, 0x03F5, 0x03F6, 0x03F8, 0x03F9, 0x03FA, 0x03FC, 0x03FD.

At least the following syscalls are no longer supported since OS 2.00 with fx9xx0 calculators: Show
0x003d
0x003e
0x003f
0x004a
0x0285
0x0286
0x0287
0x0288
0x0289
0x028a
0x028b
0x028c
0x0360
0x051f
0x0520
0x0521
0x0522
0x0523
0x0526
0x0530
0x053e
0x0548
0x0552
0x0553
0x059f
0x05a0
0x05a1
0x05a2
0x05a3
0x05a9
0x05af
0x05b0
0x05b1
0x05b5
0x05b7
0x05b8
0x05c1
0x05c2
0x05c5
0x0612
0x0613
0x0614
0x0615
0x0616
0x0617
0x063b
0x063e
0x0643
0x0644
0x075a
0x07f9
0x087d
0x0880
0x0882
0x0883
0x088f
0x0890
0x0897
0x08a3
0x08a4
0x08a7
0x08a8
0x08a9
0x08aa
0x08ab
0x08ac
0x08ad
0x08b4
0x08be
0x08c0
0x08c6
0x08c7
0x08c8
0x08c9
0x08ca
0x08cb
0x08cc
0x08d3
0x090a
0x0945
0x0946
0x0950
0x0997
0x09c8
0x09fd
0x09fe
0x0a46
0x0b43
0x0be0
0x0c8a
0x0d3d
0x0d40
0x0d41
0x0d42
0x0d43
0x0d44
0x0d45
0x0d46
0x0d47
0x0d48
0x0d49
0x0d4a
0x0d4b
0x0da1
0x0da5
0x0e2f
0x0e30
0x0e60
0x0e61
0x0e62
0x0e63
0x0e65
0x0e66
0x0e75
0x0e78
0x0f55
0x0f67
0x101e
0x101f
0x1020
0x1021
0x1023
0x1024
0x1025
0x1026
0x1027
0x1029
0x102a
0x102d
0x102e
I'll be back!

Member
User avatar
Posts: 22
Joined: Fri Aug 21, 2015 11:54 am
Calculators: Casio fx-9860G, Casio fx-9860 GII, Casio fx-CG 50

Re: TLB operation safety

Postby lephe » Sun Jul 24, 2016 9:03 am

That's quite bad news you've got there. I had seen already that the call to Hmem_SetMMU() invoked at add-in initialization had no actual effect, or was overridden by then system on SH3-based machines (in other words, there was no TLB entry matching the parameters given to the syscall), but I wouldn't expect it to be left non-implemented on SH7305.

I had a quick look and it's right that many of them are just "rts; nop". That's not the case for TLB_address_read() (0x3f8) Hmem_SetMMU() (0x3fa). Did you find any reason why they wouldn't work ?

Btw, I've got a local fork of your documentation from media.taricorp.net, but many of the syscalls you named are not listed there. Where can I find an up-to-date version of your work ?

Senior Member
User avatar
Posts: 594
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750 G II, Casio fx-9750 G II (SH4), Casio fx-9860G, Casio fx-9860 G SD, Casio fx-9860G Slim, Casio fx-9860 GII SD, Casio fx-9860 GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG 20, Casio Classpad fx-cp400, Casio fx-CG 50

Re: TLB operation safety

Postby SimonLothar » Sun Jul 24, 2016 11:24 am

lephe wrote:I had a quick look and it's right that many of them are just "rts; nop". That's not the case for TLB_address_read() (0x3f8) Hmem_SetMMU() (0x3fa). Did you find any reason why they wouldn't work ?
They push some registers (r8-r14,macl,mach) onto the stack and immediately pop them back. They do not use any argument. They do not pass any return value. In other words they act like a simple rts/nop except that they consume some more time (concerns syscalls 0x03f8, 0x03f9, 0x03fa, 0x03fc, 0x03fd). These calls are not only useless, they consequently are not used throughout their OSes.
I'll be back!

Senior Member
User avatar
Posts: 594
Joined: Sat Sep 15, 2012 6:59 am
Location: Krautland ****
Calculators: Casio fx-7400GII, Casio fx-7400GII (SH4), Casio fx-9750 G II, Casio fx-9750 G II (SH4), Casio fx-9860G, Casio fx-9860 G SD, Casio fx-9860G Slim, Casio fx-9860 GII SD, Casio fx-9860 GII SD Power Graphic 2, Casio Classpad 330 plus, Casio fx-CG 20, Casio Classpad fx-cp400, Casio fx-CG 50

Re: TLB operation safety

Postby SimonLothar » Sun Jul 24, 2016 11:35 am

lephe wrote:Btw, I've got a local fork of your documentation from media.taricorp.net, but many of the syscalls you named are not listed there. Where can I find an up-to-date version of your work ?
Most of the syscalls I listed to be not supported any more are still not considered in my documentation (and they won't, because they are not consistent). I automatically analyzed the new OSes with a small program to detect the newly indifferent syscalls, just in case someone should use one of these.
I'll be back!

Senior Member
Posts: 107
Joined: Mon Mar 02, 2015 10:53 am
Calculators: Casio fx-CG 20

Re: TLB operation safety

Postby AmazoNKA » Sun Jul 24, 2016 2:11 pm

Here is a more up to date version of the documentation by Simon fx_calculators_SuperH_based.chm (20)

Member
User avatar
Posts: 22
Joined: Fri Aug 21, 2015 11:54 am
Calculators: Casio fx-9860G, Casio fx-9860 GII, Casio fx-CG 50

Re: TLB operation safety

Postby lephe » Sun Apr 15, 2018 7:12 pm

Sorry for bringing up such an old topic; I happen to have new information regarding the original problem - whether, as I believed, the system dynamically mapped the add-in, or, as you explained, it fully virtualized it from the start.

I've been investigating the system mappings on a recent SH4 machine (a Graph 75+E, which is really just an fx9860G II). It is now clear to me that the system only maps pages "on demand".

For my tests, I used a C routine to inspect the contents of the Unified TLB (UTLB) using the memory-mapped interface to the TLB provided by the MMU. I did not inspect the ITLB (there's a word about that at the end) and did not overwrite the system's interrupt handler as I usually do. This was a standard add-in.

The default add-in mappings only included :
  • One 4k-page at address 00300000
  • 32k memory at address 08100000 (static RAM)
  • A single page mapped at 00000000 (!)

I included a large data array in my text segment and inspected the UTLB. Only the first page was mapped by default, regardless of the size of the array. Please note that the UTLB inspection code was fully contained in the first 4k page.

The most significant test consisted in accessing all the 4k-chunks of my big array in a random order and traversing the UTLB between each access. At each step, the system would map the accessed page, but no more.

As I thought, the system uses TLB miss exceptions to replace mappings if the UTLB is full. When I tried to access all the sections of an array larger than 4k (the only page size used by the system) * 64 (number of entries in the UTLB), it worked but the system had to replace some mappings. (At the end of execution, some of the array pages were not mapped anymore). Obviously the add-in was never fully virtualized because it did not fit in the UTLB.

Now, as you know, I was originally asking this question because I want to override interrupts (preventing the system from answering the TLB misses) without touching the MMU. In this setting, I would be limited to fully virtualized add-ins. Given that 9 UTLB entries are used by default, this leaves 4k * 55 entries = 220 kB for the add-in, which I experimentally confirmed to be the limit.

As I mentioned, I did not inspect the ITLB at all (although it looks reasonable for code) because when the ITLB misses, the requested address is looked up for in the UTLB and, if I'm not mistaken, if the UTLB hits the entry is copied to the ITLB. This means that the ITLB cannot be used to extend the amount of mapped code.

I think this provides enough evidence for my original hypothesis. If you have information regarding the mapping of virtual address 00000000 to physical address 00000000 (with user+kernel read+write protection bits), I'd appreciate any insight.

Previous

Return to General

Who is online

Users browsing this forum: No registered users and 1 guest