[WIP] Move sfr_data to pdata or sram. #51
Conversation
vDorst
force-pushed
the
feat_sfr_to_sram
branch
from
7fc9e26 to
d385e1b
Compare
|
This is a great idea! It could optimize both memory use and speed! I was wondering: we seem to be using 143-128 = 15 bytes of SRAM more, but I assume this may be (more than?) compensated by using less memory on the stack. How does this compare? Do we know whether it is possible to access PDATA in different pages? I am referring to https://www.keil.com/support/docs/1848.htm Do you think one of them could be a page register for pdata access? My understanding is that the usual register P2= SFR_a0 is used for something else on the SoCs. |
|
From the So it looks like MPAGE register |
|
I had also looked into the DW8051 documentation but made the mistake of grepping only for XPAGE. Great that you found this! It appears, sdcc does have some support for such a register for code generation: https://k1.spdns.de/Develop/Hardware/AVR/mixed%20docs.../doc/sdccman.html/node104.html |
|
Looking for the MPAGE register. |
diff --git a/rtl837x_sfr.h b/rtl837x_sfr.h
index 9a99ac7..5db408a 100644
--- a/rtl837x_sfr.h
+++ b/rtl837x_sfr.h
@@ -56,6 +56,11 @@ __sfr __at(0x97) SFR_97; // HADDR?
__sfr __at(0xb9) SFR_b9;
__sfr __at(0xba) SFR_ba;
+
+// SFR to control the XDATA PAGED high value
+// Used for instruction `movx @Ri,a` and `movx a,@Ri`
+__sfr __at(0x92) SFR_MPAGE;
+
// Clause 22 PHY access ???
__sfr __at(0x93) SFR_93;
__sfr __at(0x94) SFR_94;
diff --git a/rtlplayground.c b/rtlplayground.c
index 7beb6b3..114295a 100644
--- a/rtlplayground.c
+++ b/rtlplayground.c
@@ -19,6 +19,7 @@
#include "machine.h"
extern __code const struct machine machine;
+__pdata uint8_t PAGEDATA[16];
extern __xdata uint16_t crc_value;
__xdata uint8_t crc_testbytes[10];
@@ -1707,6 +1708,39 @@ void bootloader(void)
setup_external_irqs();
EA = 1; // Enable all IRQs
+ SFR_MPAGE = 0x00;
+ // Write pdata page 0
+ for (uint8_t idx = 0; idx < 16; idx++) {
+ PAGEDATA[idx] = 'a';
+ }
+
+ SFR_MPAGE = 0x01;
+
+ // Write pdata page 1
+ for (uint8_t idx = 0; idx < 16; idx++) {
+ PAGEDATA[idx] = 'b';
+ }
+
+ SFR_MPAGE = 0x00;
+
+ // read pdata page 0
+ print_string("\nPAGE 0 READ\n");
+ for (uint8_t idx = 0; idx < 16; idx++) {
+ write_char(PAGEDATA[idx]);
+ }
+
+ SFR_MPAGE = 0x01;
+
+ // read pdata page 1
+ print_string("\nPAGE 1 READ\n");
+ for (uint8_t idx = 0; idx < 16; idx++) {
+ write_char(PAGEDATA[idx]);
+ }
+
+ SFR_MPAGE = 0x00;
+
+ write_char('\n');
+It is working One location is a |
|
An other test. See commit vDorst@b9531ca |
|
Maybe the page and xdata are not completely aligned? Could you read a wider range of XMEM? BTW: There is also SRAM in the ASIC for TX and RX of packets, the datasheet says there are 8MBit, but I believe only 512kByte can be addressed (see |
|
Oh, and if one wanted to send a really large bit of IP-data, say larger than the buffer in XMEM, one could assemble it piece by piece in the ASIC memory and then transfer in a single go. |
|
But alignment is may the issue. __pdata seems located at 0x01. Moving Again corruption but around the same area. Moving Now it prints the address of PAGEDATA and starts at 0x01. I was hoping that init of the pdata also worked by adding This now prints |
|
PAGEDATA is initialized by the code. Or at lease in the |
I did ran some tests, and while SFR_96 is the "code bank", SFR_97 is the "data bank". So SFR_97 lets you access the flash from XRAM space using MOVX instead of having to go through MOVC. SFR_b9, SFR_ba and SFR_bb together are a "stack in XRAM" peripheral Reading from SFR_bb pops from the stack |
That is an amazing analysis, and incredibly useful! I always wondered how the code when doing the paged calls could actually work if SFR_ba was always overwritten. But now I understand. Kudos! |
|
Also I just tried to see if the code ram can be written using WRS bit in SPC_FNC of the DW8051 core, but that doesn't seem to be hooked up. AFAIU in RTL8367 the code ram can also be written using SMI register access (range 0xe000...) |
3 participants
I am working on SIPHASH were I need a large memory block of 32 bytes.
But I want to access it easily.
I know you can access lower part XDATA via a single register using the instruction
MOVX @Ri, A.This is called Paged Memory??. Just use
__pdatato define a variable.Not sure if paging is controllable.
Because we are using
sfr_dataa lot, it make sense to make it faster to access.I made a quick test to move
sfr_datatopdata.Because of some function I also needed to move
linkbits_last.See first commit.
As a result it reduced the code size with 350 bytes.
Most of these bytes, I assume, are used to load in the DPTR of calculate it.
Second commit is move
sfr_dataandlinkbits_lastto sram.I think it make sense to use some extra sram to access sfr_data faster.
As a result it reduced the code size with 650 bytes from the original xdata code.
diff between the two
.mem-files.So I think we can optimize more things by moving them into
__pdata.And/Or define a large scrats-memory block in pdata, which I may need for my SIPHASH.
Which can also be used by other code.