On Wed, Jul 2, 2008 at 4:03 AM, James Keenan via RT <[EMAIL PROTECTED]> wrote: >> Second, two notes about the branch: >> >> In a fresh checkout, if I 'make renumberops' with no local >> modifications, src/ops/ops.num changes. >> If I rename the op store_lex to barf_lex, and run 'make renumberops', >> the opcode barf_lex doesn't show up in src/ops/ops.num. (But, >> store_lex vanishes) >> > > I have found the code which causes (at least the) 2nd problem Coke > describes and know how to fix it. See the opsrenum branch. > > But whether my fix is correct or not depends on two questions: > > (1) Is the following passage from the inline comments in src/ops/ops.num > still valid? > > # once an opcode is added to this file it should never be > # removed. Opcodes that are in here but that have no corresponding > # function backing them (because, for example, they've been deleted, > # which shouldn't ever happen once we hit production) should be mapped > # by the ops processing programs to an exception op > > If it *is* valid, then any renaming of an opcode should leave that op's > *current* name and number in number.ops unchanged. The *new* name for > the opcode should presumably be pushed on to the end of the list. > > But this runs counter to the generally programming principle that we > should get rid of old, unused code. Why is this case different? > > Which leads to the next question: > > (2) Why do we maintain number.ops as a *static file of source code at > all*? Why is it in the repository? If a given Parrot developer, for a > given instance of Parrot configuration and build, renumbers the opcodes > (either because the list of opcodes has changed or just for the hell of > it), why must that renumbering be inflicted on all other Parrot > developers -- which it would be as the result of 'svn ci'? > > Thank you very much. > kid51 > opcodes are the very heart of bytecode. if the opcodes change, then the bytecode is invalid. if opcode #1 (noop) was changed to something like (delete_harddisk), and parrot is rebuilt, than any existing bytecode (.pbc file) that contains a noop instruction will instead perform delete_harddisk. that's *never* the right thing to do--it means bytecode can never be shared reliably across parrot builds. portable bytecode is one of the main goals of parrot.
therefore, in an attempt to keep bytecode compatible across versions of parrot, opcodes can never be deleted. instead, if opcodes are deprecated, their function bodies should throw an exception explaining that the opcode is no longer supported. like the comment says, this will be strictly enforced after parrot 1.0, but is a good rule to follow now as well. the design team reserves the right to make architectural changes that impact the opcode numbers, of course, until we have a production-ready product. ~jerry
