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
