From: Dai Y. <yu...@mi...> - 2001-02-12 04:01:52
|
Hi, Scott I personally have interest in the DSEG overflow and analysis of call tree. But I have a little question. >But the good news is ... >I'm in the process of writing a backend optimizer for the PIC port. I call it >"pCode" to differentiate from the iCode that SDCC currently produces. iCode is >"intermediate" code while pCode is post code. The iCode passes through the PORT >specific calls to generate the pCode then the pCode is optimized in a way >analogous to the peep hole optimizer. I've currently got the PIC PORT generating >pCode and am in the process of creating the Call tree. The next step will be to >apply the optimizations to the pCode. What if the caller and callee functions are in different C source files? It seems that you have to create the call tree during the link process? Best regards, Dai Yuwen |
From: Daniel D. <dr...@ma...> - 2001-02-12 07:55:18
|
On Mon, 12 Feb 2001, Dai Yuwen wrote: > What if the caller and callee functions are in different C source files? It > seems that you have to create the call tree during the link process? Must commercial products work this way. This is linker's job, the C compiler just have to pass some extra information about the functions to the linkage phase (eg. space needed by paramateres and local vars, etc). Maybe debug info can hold this. Daniel |
From: Scott D. <sc...@da...> - 2001-02-12 14:57:36
|
On Mon, 12 Feb 2001, Dai Yuwen wrote: > Hi, Scott > > I personally have interest in the DSEG overflow and analysis of call tree. > But I have a little question. <snip> > > What if the caller and callee functions are in different C source files? It > seems that you have to create the call tree during the link process? Ahh, very observant! As things stand, there is no way to cross the C source boundary. SDCC takes a C-file as input and produces a .asm file as output. The assembler is responsible generating object code and of course the linker produces the final executable/hex file. For the pCode infrastructure I described to work across C-file boundaries, it will be necessary for SDCC to produce additional information beyond the .asm file OR to enhance the assembler to analyze program flow. The former is much more manageable from an SDCC developer's point of view since the flow information is already available in the pCode format. OTOH, the latter has appeal to the SDCC user who is interested in optimizing hand written assembly (e.g. not to become more clever than the author [though that will be easy in many cases] but to provide register optimization, function in-lining, etc.). In either case, the assembler and linker will need to enhanced. For the time being I'm ignoring the C-boundary problem. There's just too much infrastructure that has to be created at the moment. But what I propose is that in addition to producing a .asm file, SDCC will optionally produce either a .p (pcode file) or perhaps a .obj file. If .p files are produced then we would need to modify the PORTs' assemblers. If .obj files are produced, we can bypass the assembler altogether. Any suggestions? Scott |