Menu
▾
▴
Re: [sdcc-devel]Re: To use or not to use mcs51reg.h
|
From: Karl B. <ka...@tu...> - 2001-03-18 06:07:44
|
Hi Johan and others,
Let me mention that if you compare the ds390 code and
the mcs51 code generator, a lot of the code is redundant,
so I don't think the choice to split it off was that obvious.
Note a lot of the changes are to add dual dptr support, which
could come in handy in the main line MCS51 compiler for a lot
of non-ds390 processors.
I compared the code a while back to see what kinda magic
Kevin performed to get rid of the dreaded large model
"overflow/spillage" problem, which generally renders the SDCC
compiler broken for larger MCS51 C coding projects.
I couldn't figure out where the problem was, so I asked
Kevin and he pointed me at a bit of code which I tried tweaking.
Heres my plea for help, and notes from Kevin:
On 02-Dec-2000 Karl Bongers wrote:
> Alright Kevin, Where are your changes which make
> your ds390 port NOT spill and NOT use DSEG for local vars?
One biggie is ralloc.c/createStackSpil: the line:
SPEC_SCLS(sloc->etype) = options.model ? S_XDATA : S_DATA;
forces all spills into the XDATA space instead of DATA (for model != 0;
this test should probably come out since --model-small ain't gonna work in
the ds390 port as it stands anyway, and we should always use XDATA...)
The only other biggie I recall at this late hour is in
SDCCsymt.c:checkSClass; the last line:
SPEC_SCLS(sym->etype) = (options.model ?
S_XDATA : S_DATA ) ;
is important (puts locals in XDATA), but since it's common code, you
should get it for free.
I should warn you, though, that you will probably find the code generator
will break to hell and back, and it's not a joy figuring out why... there
are an incredible number of hidden assumptions about when data won't be
in XDATA.
Peace,
Kevin
--------------------
Heres some maps to compare of a large model compilation and a ds390
compilation. The large model compilation spills stuff until
it overflows the DSEG.
heres the DSEG when compiled with DS390 model:
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
DSEG 0030 000D = 13. bytes (REL,CON)
Value Global
-------- --------------------------------
0030 G$g_dwi$0$0
0030 _g_dwi
0032 G$g_di$0$0
0032 _g_di
0033 G$g_dc$0$0
0033 _g_dc
0034 G$bank_num$0$0
0034 _bank_num
0035 G$temp$0$0
0035 _temp
0037 G$csum$0$0
0037 _csum
003B G$wcsum$0$0
003B _wcsum
Hexadecimal
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
OSEG 003D 0000 = 0. bytes (REL,OVR)
heres the DSEG when compiled with LARGE model:
Value Global
-------- --------------------------------
0030 G$g_dwi$0$0
0030 _g_dwi
0032 G$g_di$0$0
0032 _g_di
0033 G$g_dc$0$0
0033 _g_dc
0034 G$bank_num$0$0
0034 _bank_num
0035 _do_console_linebuf_1_1
0037 G$temp$0$0
0037 _temp
0039 G$csum$0$0
0039 _csum
003D G$wcsum$0$0
003D _wcsum
003F _stack_rec_our_bptr_1_1
0041 _tcb_lookup_tcp_1_1
0043 _rx_conn_tcp_tcb_1_1
0045 _rx_conn_tcp_sloc0_1_0
0047 _rx_conn_tcp_sloc1_1_0
004B _rx_conn_tcp_sloc2_1_0
004D _rx_conn_tcp_sloc3_1_0
004E _sync_tcp_tcb_1_1
0050 _sync_tcp_sloc0_1_0
0052 _sync_tcp_sloc1_1_0
0054 _sync_tcp_sloc2_1_0
0056 _tx_tcp_tcb_1_1
0058 _tx_tcp_sloc0_1_0
005A _tx_tcp_sloc1_1_0
005C _tx_tcp_sloc2_1_0
005E _tx_tcp_sloc3_1_0
0062 _rx_icmp_ip_1_1
0064 _rx_icmp_icmp_1_1
0066 _rx_arp_bptr_1_1
0068 _rx_arp_sloc0_1_0
006A _rx_arp_sloc1_1_0
006C _rx_arp_sloc2_1_0
006E _do_http_sloc0_1_0
0070 _do_http_sloc1_1_0
0073 _eth_poll_tcp_sloc0_1_0
0077 _getnumbers_str_1_1
007A _getnumbers_sloc0_1_0
007B _getnumbers_sloc1_1_0
0084 _dump_mem_sloc0_1_0
0086 _dump_mem_sloc1_1_0
0087 _dump_mem_sloc5_1_0
Hexadecimal
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
OSEG 0088 000C = 12. bytes (REL,OVR)
Value Global
-------- --------------------------------
0088 __muluint_a_1_1
0088 _memcpy_dst_1_1
0088 _memset_buf_1_1
0088 _strcpy_sloc0_1_0
008A __muluint_t_1_1
008B _memcpy_ret_1_1
008E _memcpy_d_1_1
0091 _memcpy_s_1_1
Most of these sloc variables that blow up the DSEG are from
either having more than 1 parameter passed in a function or
just the compiler overflowing on some complex logic and running
out of register space.
In either case, it overflows into the DSEG. Preferably, it would
be able to overflow and put additional function parameters
into the XDATA segment.
I did try Kevins changes, and as he mentioned it blows up the code
generator pretty good(it starts generating bogus code).
My general impression is that the code generator runs out of
registers to deal with the problem. I think Kevin managed some
fancy foot work with the dual dptr to work around it on ds390.
Unfortunately, we can't rely on a dual dptr in the main MCS51 codebase
to solve this.
Anyone want to comment or make suggestions?
Karl.
>Although Kevin's seperation of the ds390 code generator was a good choice
>for obvious reasons (for those who are involved) I won't vote for seperating
>small-mcs51 and large-mcs51. Now that I am using the "poor old man's" ?-) 51
>core again, I don't see a reason why. It will only introduce more
>redundancies, whereas the code-generator is quite stable as it is, although
>there may be some flaws left which we can solve when we notice them.
|