On Tue, Jun 14, 2005 at 11:48:06AM +0200, Leopold Toetsch wrote: > Bob Rogers wrote: > > So, IMHO, it seems more versatile to have these opcodes operate on > >one arg/return at a time, instead of monolithically on the whole list: > > > > set_arg <index>, <flags>, <val> > > If somehow possible, I'd really like to avoid indirect register > addressing.
I think Bob's proposal is actually harmless WRT aliasing. It's indirect indexing, but only of the explicitly enumerated _arguments_ or _return_value_ registers that appeared in the source code and are thus visible to the allocator. Which is not to say I think it's a good idea. When performance matters, batching is good and unbatching is bad. And in parameter and return value processing, performance *matters*, a lot. Unbatching would also raise issues WRT the lifetimes of returning functions' register frames ... the number of opcodes that would process the return value would potentially be unbounded, so the returning function's parameters would have to be stored somewhere (expensive) or the dead invocation's register frame would have to be kept around (also expensive). So I think the one-opcode-per-parameter idea is pretty much a non-starter. > > foldup_return <index>, <flags>, <Preg> > > .set_returns "(0x10,0x10,0x10)", $P5, $P6, $P7 > # mark 3 pmcs as being returned as array Unless I've misunderstood its purpose, I don't think that "foldup" is a good feature here. There's no reason a subroutine shouldn't be expected create an Array (or other aggregate of its choice -- note that the specific type may be important) and return it. > The proposal has argcI, argcP, ... "The proposal"? (Register-)color me confused. > I expect that we end up with some context error/warning flags that > cover various mismatches of argument passing. Core language exceptions that the upper language can translate, or perhaps HLL-specific hooks. Or maybe even an additional parameter to the opcode for a label that's taken when something goes wrong...? -- Chip Salzenberg <[EMAIL PROTECTED]>
