We had a discussion with dml and he came up with the following design. Basically it's EQUR with automated register assignment. --------------------------------------- super mini example of open naming and reallocation via input constraints: rin a0,fred rin a1,bob rin d0,jam add.l (fred)+,jam ; don't even bother trying to make sense of this code move.l jam,banana ; jam is d0 here for sure, because add.l has a dest with an input move.l jam,orange lsl.l #2,orange move.l (fred)+,jam ; jam might not be d0 here! or.l jam,banana add.l orange,banana move.l (fred)+,jam ; jam's life gets reset again by a move op (a dest supporting no inputs) - gets a chance to become d0 again rout jam,d0 ; note: only d0 is mapped both in and out rout banana,d7 notes: - actual syntax isn't that important for the most part, so long as its robust - register 'types' are implied here, but may be better to specify via some prefix - user vs design hassle trade! - each opcode needs some internal info to say whether the operands are inputs or outputs or both, to analyse token lifespans - assigning to a token as output-only means 'internal rename opportunity' - can be given a new register immediately. - any dest operand which doubles as an input (add, or, and, bset ...etc) is not a rename opportunity. - i usually do this by following outputs backwards through the program and making a little graph. - err. that's all. GCC inline assembly nearly does this. it could have done this. they had everything they needed... ..but those beards prefer awesome levels of self-induced pain to common sense. what they did is an abomination. FYI, 6888fu uses a simplified version of this scheme for constraining and allocating, but doesn't allow arbitrary tokens for regs - just fp0-fp7. internally it will rename them in a much larger range of digits (each new assignment increments the 'name counter') until it optimizes the lifespans back down to fp0-7 in the final pass. its also at this point where it will whine if the program needs more registers than can possibly be handed out given the inout constraints. what is it useful for? writing, modifying, optimizing, refactoring big asm programs without burning 90% of your effort worrying about which registers just got trashed or might become free after the change. one last bonus is that it may accept normal register names d0-7/a0-7 and leave it up to the user whether they want zero, partial or full reallocation from those original names - and with or without feedback in each scenario. all very handy for R&D! -------------------------------
Necrotic 2P Hope you don't mind another thought in this? Sounds like a cool idea, and would probably be really handy for the RISC side of things too. What I think may also be useful/required is the ability to specify registers that cannot be used for this reallocation. My thoughts: You have a function like the one specified in the example, but the calling code makes use of d2. On the line: move.l (fred)+,jam If I am understanding you correctly at this point jam might be allocated to a different register? If that is correct then would need to protect other registers outside of their nominated block. Or possibly indicate registers that are free for dynamic usage between the rin and rout. Hope that makes sense (and I understand what you are saying too :) )