[LLVMdev] Re: LLVMdev Digest, Vol 2, Issue 30

[Robert Mykland]

Comments re your comments...

At 05:26 PM 8/17/2004, you wrote:
>>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* release :)
>>This 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