Comments re your comments...
A value of zero now means zero literal for everything except labels, right?
Hmm. Not quite sure what you mean here. Zero values are used in quite a few places for various purposes. For example, the zlist will write a zero byte to terminate the list. In general a zero byte is only used to terminate some value. Zero corresponds to the "Null" type plane which we never emit nor any values of type "Null" so you won't see this as the type index for any value.
In C, null usually refers just to pointers with a value of zero. Using the word "null" to refer to integer types would confuse most C programmers I would expect. But I think we're on the same page here. To use my previous nomenclature I was asking whether a value index of zero implies literal zero for all types. It sounds like from your other comments that it does mean this.
There is kind of a vague reference to this in the 1.0 -> 1.1 section I believe.
THe Version 1.0 and 1.1 bytecode formats were identical (bytecode format 1). You are probably referring to the differences between 1.1 and 1.2 in the "Explicit Primitive Zeros" section. This section refers only to the encoding of constant zero or null values for only the primitive types. The IR changes in 1.2 to have constant "null" values for each primitive type, and pointer type. Consequently, there was no need to write these to the bytecode file any more. In some cases, this saved huge amounts of bytecode because zero initializers for large arrays of primitive type initialized to zero caused emitting a zero intiializer for every element of the array. THis is no longer done.
You might want to make this clearer when talking about values in the body of the document.
Could you suggest how? I'm a little fuzzy on what you're getting at here.
It could be mentioned in the values section.
--> A comment on this: if a value of zero were never used for labels, that would make me happy, because then my code could replace references to zero with literal zero always and always subtract 1 from the value if not zero to index into my type/value table.
I'm not sure what you mean by "if a value of zero were never used for labels". Are you referring to the type id (value=12), the slot number for the label (should only be one label with that slot number per function), or something else? Note that label values are not, per se, written to the bytecode. Instead we just give the labels name to the corresponding instruction in the symbol table.
Right. Understood. I was referring to the fact that labels have a value index starting from zero and all other types have a value index starting at 1 (zero being reserved for literal zero). It would be easier in my code if non-implicit values all started at 1.
After reading through the upgrade sections, it seemed to me that there are several things mentioned there that ought to also be mentioned in the body of the bytecode document. I admit I'm lazy, so I usually only read upgrade sections of a doc when I'm busy upgrading to the next version. Here's a vote for making the docs more friendly to lazy skimmers like myself.
Could you provide a list of the "several things mentioned there that ought to be mentioned in the body of the bytecode document"? I'm unclear on the specifics you're referring to. I'm happy to make this "skimmer friendly" but just not sure what you're getting at.
I will read through these sections and provide you with a list by seperate email within the week.
snip
> (3) In Reid's documentation, his "opcode" link is bad. His doc does
> not yet contain an opcode section. Presumably this would contain the info
> from the include file Instruction.def.This is also a doc bug. Its fixed by just referencing the
Instruction.def file on the cvsweb which will always contain the correct
list of instruction opcode values for the latest release. Note that that
might not be correct for *your* releaseThis is not a good fix for people like me who may be a few versions back from the latest release from time to time. This info should really be duplicated in the body of the doc.
Okay, I see your point. If you'd care to submit a patch, I'll add it in.
Otherwise, this will have to wait a bit until I can spend some time at it (I have to figure out which instructions go with which versions).
I'll consider it.
snip
> (5) Labels used to have their own type. If this is still the case, its
> not discussed in Reid's document. It looks like the new type slot for
> label is 12, the same as raw function. Presumably this would be the > secret type slot between the last primitive type (11) and the new start
> of the defined types table (13).This is probably a result of the "Type != Value" change that happened in
1.3. In 1.2, we had (in Type.h):Yes. This was one of those items that was buried back in the upgrade section. Lazy skimmers like myself will get confused and ask about this.
Should I move the differences section to the front of the document? Would that help?
Nope. Lazy skimmers would skip over it. The basic point is that lazy skimmers go straight to the "values" section to learn about values. They expect that the release concurrent with the doc actually works as described in there without checking the upgrades section for elaborations.
snip
Also, over time it will become immune to checking some problems (for example, it now always rounds block sizes to the next nearest 32-bit boundary to cover the size of padding in all cases).
Careful! In version 4 of the bytecode (to be released with LLVM 1.4), the blocks are no longer aligned. You're fine for version 3, but please make a note of this change for version 4 bytecode files.
Well never say never I guess.
Thanks for everything,
-- Robert.
Robert Mykland Voice: (831) 462-6725
Founder/CTO Ascenium Corporation