From: Maarten B. <sou...@ds...> - 2004-08-26 16:24:17
|
Hi all, I've been working on the printf functions to make them generally usable, no more inline assembly. Then I tried to test it on the hc08 port and I found out that in the regression tests spec.mk REENTRANT=<empty> instead of REENTRANT=reentrant. But I did get an error telling me I need reentrant. So now my question is: Does the HC08 port need "reentrant" where appropriate or does it always generate reentrant code? Greets, Maarten |
From: Erik P. <epe...@iv...> - 2004-08-27 13:49:35
|
On Thu, 26 Aug 2004, Maarten Brock wrote: > I've been working on the printf functions to make them generally > usable, no more inline assembly. Then I tried to test it on the hc08 port > and I found out that in the regression tests spec.mk > REENTRANT=<empty> instead of REENTRANT=reentrant. But I did > get an error telling me I need reentrant. So now my question is: > > Does the HC08 port need "reentrant" where appropriate or does it > always generate reentrant code? It needs either "reentrant" or --stack-auto to guarantee reentrant functions. This is largely because it is distantly based on the mcs51 port, which also had reentrant/non-reentant options. I have thought about forcing reentrant (like the z80 port), but the inefficiency of loading (and storing) pointers on the stack also gives me pause: lda sloc_offset,s ; 3 4 psha ; 1 2 pulh ; 1 2 ldx sloc_offset+1,s ; 3 4 ; 6 bytes, 12 cycles total versus ldhx *sloc_direct ; 2 bytes, 4 cycles Erik |
From: Maarten B. <sou...@ds...> - 2004-08-30 18:20:38
|
Erik Petrich, Just saw the latest changes to the regression tests. I observed you defined idata empty for the hc08 port in zeropad.c. I expected it to be defined as data (that's what I did for my local copy and that failed the test yesterday). And does the port understand "code" and "near" or "far"? They are not documented. B.t.w. with my version of vprintf even bug-927659.c passes the tests. A little more optimizing and testing and I will submit it. |
From: Erik P. <epe...@iv...> - 2004-08-31 02:16:03
|
On Mon, 30 Aug 2004, Maarten Brock wrote: > Just saw the latest changes to the regression tests. I observed you > defined idata empty for the hc08 port in zeropad.c. I expected it to be > defined as data (that's what I did for my local copy and that failed the > test yesterday). Ah I see. Yes, that would have been better; I had assumed "data" was already in the storage list. I've just re-run the test with "idata" defined as "data" and it still passes. > And does the port understand "code" and "near" or "far"? They are not > documented. Yes, they are understood. Like the mcs51 port, "near" is synonymous with "data", "far" with "xdata", and objects declared as "code" will be allocated in the CSEG area. Unlike the mcs51 port, the pointers "* near", "* data", "* far", "* xdata", "* code", and "*" are all treated identically by the back end code generator (although the front end may still have some residual pickiness from the mcs51 influence) since the hc08 has a single memory addressing space. > B.t.w. with my version of vprintf even bug-927659.c passes the tests. A > little more optimizing and testing and I will submit it. Great! Erik |
From: Maarten B. <sou...@ds...> - 2004-08-31 09:39:18
|
> > On Mon, 30 Aug 2004, Maarten Brock wrote: > > > Just saw the latest changes to the regression tests. I observed you > > defined idata empty for the hc08 port in zeropad.c. I expected it to be > > defined as data (that's what I did for my local copy and that failed the > > test yesterday). > > Ah I see. Yes, that would have been better; I had assumed "data" was > already in the storage list. I've just re-run the test with "idata" > defined as "data" and it still passes. It passes here too. I think "data" was not in the list because there is an empty entry in the list. But the hc08 port doesn't default to "data" but to "xdata". Why is that b.t.w. ? You don't want to travel into large and small memory models? > > > And does the port understand "code" and "near" or "far"? They are not > > documented. > > Yes, they are understood. Like the mcs51 port, "near" is synonymous with > "data", "far" with "xdata", and objects declared as "code" will be > allocated in the CSEG area. Unlike the mcs51 port, the pointers "* near", > "* data", "* far", "* xdata", "* code", and "*" are all treated > identically by the back end code generator (although the front end may > still have some residual pickiness from the mcs51 influence) since the > hc08 has a single memory addressing space. > > > B.t.w. with my version of vprintf even bug-927659.c passes the tests. A > > little more optimizing and testing and I will submit it. > > Great! > > Erik There was a little discussion about the regression test makefile about two weeks ago and we have had it also in the past. It makes me wonder what makefile is used on the CF. I feel uncertain to change this makefile in cvs, but I would very much like to do that, so that anyone can run the regression tests with the default makefile. And with your latest commit you introduced _FLOAT_FUNC_REENTRANT. When looking at it some more I think it's very odd this ever worked. Most functions were declared without reentrant in math.h but with it in the implementation. I have no idea how the compiler could handle this. Is it all taken care of by the --float- reent option? And have you now made all those functions reentrant permanently? If so, the --float-reent option is no longer necessary(?) And finally some functions are left without reentrant keyword. As you can see, I'm totally confused here. |
From: Bernhard H. <ber...@be...> - 2004-08-31 14:45:04
|
> There was a little discussion about the regression test makefile about > two weeks ago and we have had it also in the past. It makes me > wonder what makefile is used on the CF. I feel uncertain to change this > makefile in cvs, but I would very much like to do that, so that anyone > can run the regression tests with the default makefile. In the beginnig I didn't touch ALL_PORTS, because the regression test suite was Michael's playground. Later on I didn't care about this setting, because I didn't need it. Of course I understand, that it's difficult for newbies to understand what's going on. Therefore we really should update ALL_PORTS to something usefull. The nightly build indeed uses this Makefile, but it doesn't use ALL_PORTS. Feel free to change it. After reading about the great news I added the hc08 to the nightly regression test already yesterday: http://cvs.sourceforge.net/viewcvs.py/sdcc/sdcc-build/components/sdcc.mk?rev=1.57&view=log Today you'll find a little warning on all hosts from this :-) Erik: you've done an excellent job! Bernhard |
From: Erik P. <epe...@iv...> - 2004-09-01 05:38:01
|
On Tue, 31 Aug 2004, Maarten Brock wrote: > > Ah I see. Yes, that would have been better; I had assumed "data" was > > already in the storage list. I've just re-run the test with "idata" > > defined as "data" and it still passes. > It passes here too. I think "data" was not in the list because there is an > empty entry in the list. But the hc08 port doesn't default to "data" but to > "xdata". Why is that b.t.w. ? You don't want to travel into large and > small memory models? I don't really remember why, but over a year ago I changed the hc08 port default to --model-large to fix some problem. Now that the overt bugs have been fixed, I should see if --model-small is still broken or not. > And with your latest commit you introduced > _FLOAT_FUNC_REENTRANT. When looking at it some more I think > it's very odd this ever worked. Most functions were declared without > reentrant in math.h but with it in the implementation. I have no idea > how the compiler could handle this. Is it all taken care of by the --float- > reent option? And have you now made all those functions reentrant > permanently? If so, the --float-reent option is no longer necessary(?) > And finally some functions are left without reentrant keyword. As you > can see, I'm totally confused here. I was also rather confused by this when I first discovered the situation. It works for mcs51/ds390 since the first parameter is passed in registers, regardless of the reentrant setting (unless the function has varargs, but none of these do). If there are two or more parameters, the function prototype must match its implementation with regards to the reentrant keyword, otherwise one or more parameters will not be passed in the manner expected. However, the hc08 port always needs this to be explicit, since it never passes a float via registers (ignoring the bug you noted last week). The --float-reent option only controls the intrinsic functions (add, subtract, multiply, divide, cast to/from int), not the functions that the C standard requires prototypes of in math.h. Assuming I have not made a mistake, the functions that are being compiled as reentrant now are only those that were being compiled as reentrant before; the prototype is no longer abusing the passed-in-registers loophole. Furthermore, if you do not want these functions to be reentrant, you now need only edit the definition of _FLOAT_FUNC_REENTRANT in math.h and recompile the library. As to the question of why these particular functions are always reentrant, perhaps Jesus Calvino-Fraga (their contributor) can offer a comment. Erik |