I can answer some questions about assembler...
as conversion from Assembler -> C is what appears to be the case...
When it comes to the OS libcall mechanism thats fine you't have to know the calls and arguments only for the project internal functions...
re-compilation would be interesting but simplistic as long as everything is accounted for
I don't have any style tips for code-layout but suggest you break up the assembler and check what sections are "re-usable" reworking functions accordingly
--- Tony Wyatt wyattaw@optushome.com.au wrote:
Hi Thomas,
On 2/05/2005, you wrote:
Are there any projects up for grabs that I can
look into ?
What about some advice on coding habits? I'd ask privately, but the answer will be of general interest anyway, both in the project I am currently working on and those in the future like OO and Kaffe.
Much old 68k code is fast and efficient because it relies on parameters like library and structure pointers remaining persistent in allocated 68k registers, eg a2, a6 always point to particular structures. In a big module consisting of dozens if not hundreds of very small functions, only one or two registers are ever used for volatile data. Most parameters are passed in assumed registers, so loading of arguments is minimised.
So what is a good way to maintain this register shortcut in a C version of a big program originally written in assembler? Obviously I can specify parameters to be passed in 68k registers, but I am trying to write this thing in a portable fashion, machine-independent.
I have no experience with PPC code yet. Is there a way to ask gcc to use registers for certain parameters, in a platform-independent way? I want the C code to remain pure ANSI-compliant. It would be nice to leave the code unchanged from its present SAS/C environment to PPC and gcc.
cheers
Openoffice-os4 mailing list Openoffice-os4@samfundet.no
https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com
Hi Belxjander,
Maybe I didn't describe it very well. The project is to convert 68k assembler into C that can be compiled on the A1 to native PPC code. But there are some other implied requirements, for example, it must run like greased lightning and be portable code that can be easily recompiled for the next platform that AOS is ported to.
I have translated most of the 68k assembler into ANSI C, and I use SAS/C to compile it into 68k binary. That binary runs on my A4000 and on the A1 (emulated) exactly the same way as the original assembler version. When the translation and debugging of the C version is complete, I will use GCC to compile it for PPC on the A1.
The 68k code depends on a2, a3, a6 always pointing to particular structures. That makes it quick to call a function, because those registers do not have to be set up before the call. In C, though, I have to pass the pointers as function arguments each time. I *could* define a proto that uses 68k registers, but that would be useless when I recompile the C code for the PPC. Meantime I am stuck with having to load arguments onto the stack for the simplest function call, which in the 68k assembler case, might not have to load any registers at all. Bloody slow.
So the question is really: is there a platform-independent way to allocate some registers as permanent pointers, persistent over the whole program? Has this problem come up elsewhere in OS4? What have other developers done?
cheers
Hi,
Tony Wyatt wrote:
The 68k code depends on a2, a3, a6 always pointing to particular structures. That makes it quick to call a function, because those registers do not have to be set up before the call.
See my other mail.
So the question is really: is there a platform-independent way to allocate some registers as permanent pointers, persistent over the whole program? Has this problem come up elsewhere in OS4? What have other developers done?
Since registers are always tied to the platform: No. C doesn't even know about registers.
Regards,
On 2/05/05, Tony Wyatt wrote:
The 68k code depends on a2, a3, a6 always pointing to particular structures. That makes it quick to call a function, because those registers do not have to be set up before the call. In C, though, I have to pass the pointers as function arguments each time. I *could* define a proto that uses 68k registers, but that would be useless when I recompile the C code for the PPC. Meantime I am stuck with having to load arguments onto the stack for the simplest function call, which in the 68k assembler case, might not have to load any registers at all. Bloody slow.
Yeah, on 68k processors that's true- but it's not necessarily true on PPC, as they have Level2 memory caches, which the CPU has very fast access to (compared to main memory). Something like parameters stored in the stack, should be guaranteed to always stay in the L2 cache, during the function call, as it's a small amount of memory only stored for a very small amount of time.
-Ants
Right you lot. All these little snippets about coding, porting and generally Being Useful could quite easily be posted on http://developer.acggbg.org/ which has all the advantages and disadvantages of being a Wiki, and also has the immense advantage of already being set up and structured to a great extent.
On Mar 3 mai 2005 3:17, Anton Reinauer a écrit :
On 2/05/05, Tony Wyatt wrote:
The 68k code depends on a2, a3, a6 always pointing to particular structures. That makes it quick to call a function, because those registers do not have to be set up before the call. In C, though, I have to pass the pointers as function arguments each time. I *could* define a proto that uses 68k registers, but that would be useless when I recompile the C code for the PPC. Meantime I am stuck with having to load arguments onto the stack for the simplest function call, which in the 68k assembler case, might not have to load any registers at all. Bloody slow.
Yeah, on 68k processors that's true- but it's not necessarily true on PPC, as they have Level2 memory caches, which the CPU has very fast access to (compared to main memory). Something like parameters stored in the stack, should be guaranteed to always stay in the L2 cache, during the function call, as it's a small amount of memory only stored for a very small amount of time.
-Ants
-- Anton Reinauer amizilla@ants.name
http://www.ants.name
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Hi Rose,
Oww! Put that stick down!
cheers
-
Anton Reinauer -
Belxjander Serechai -
Rose Humphrey -
Thomas Frieden -
Tony Wyatt