Hi Scott, > So, if you wish to minimize the encumbrance, start from scratch. > But as > an experienced developer I view encumbrance due to other's design > decisions as just another way others think about a problem. Once I > immerse myself into their way, I then decide if their decisions hold > value or not.
I tend to agree, but it can be very frustrating. I have my own way of doing things, and of course that doesn't really match anyone else's. Over the years I've managed to mostly suppress the urge to roll-your- own. > > When I started the PIC port, I copied the 8051 port and changed > everything that looked like an 8051 into a PIC. It was arduous. The > pic16 port began the same way but started with the pic (i.e. pic 14) > port. This I presume was less arduous to get the initial stuff > working, but it still required a significant amount of work. Some of > that work was due to the design decisions I made on the pic14 port and > some due to the fundamental differences between the architectures. Yeah, what I started to do was take the 8051 ralloc code, try to map it out, and start changing it to PIC code. In doing that, I did gain an insight into how the ralloc code works, but other things remain inexplicable. For example, in regTypeNum, which goes through all the symbols in a block to see how many registers each has to be allocated, there's a line that says if a symbol is a "true symbol", use no registers. I guessed that maybe a "true symbol" was a port or a special function register. But then, later on in the code, in serialRegAssign, which goes through every instruction in every block, there's a line that says if a result operand is present, and the iCode isn't an IFX, and the result operand is a "true symbol", then increment the allocreg for the symbol. Which seems to imply the exact opposite of what regTypeNum said. As another example, again, in serialRegAssign, if a block has "no path", and the block's entry label is neither "the entry label" nor "the return label", then skip assignment for this block. Without a lot of digging around, I have no idea why this should be, but I was willing to leave it alone. So anyway, I now have a sort-of vague kind of understanding of ralloc. One of the decisions I made, at least at first, was that the PIC12 would not do any spilling. Since there isn't any memory to spill to, everything has to be in a register (and there are 38 of them). Alternatively, I suppose you could also consider some of those locations to be registers, and some to be memory, but then you'd have spills and lots of moving around. So that seemed to me to simplify the whole ralloc scheme. Now, it looked to me as if you might have made the same decision in PIC14 -- you've got 128 registers in there. But all the spill code is also in there. So what's the story? > > If I were to initiate a 12-bit port, I'd begin with the closest > port. I'd start with the pic 14 port and change every that doesn't > apply > to the 12-bit core. Since the architectures are so similar, I'd also > endeavor to overlap major portions of gen.c. I'd begin looking at > gen.c > to see exactly how much dependency there is on the 14-bit core. I > suspect there's quite a bit. If there are too many differences, > then it > may make sense to copy the 14-bit directory into a 12-bit one and > customizing it to the 12-bit core. If you take this route, begin with > gen*.c. I'd save ralloc.c for last. The pCode stuff can be initially > modified by just removing support for the arithmetic immediate > instructions (like ADDLW). I suppose I could take a shot at doing that... Thanks, --Rob ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
