search for: vbr_uint

...really good point. I was planning on doubling the referent type's slot number to get the pointer type. But, if all the pointer types are not used in the program then this just serves to increase the numerical values of the slot numbers and it will actually bloat the size of the file because the vbr_uint written slot numbers could take more bytes to write. Contrary to previous assertions, I'm not going to implement this unless we can prove that its beneficial. > I think that debug libraries should be handled in other ways. The > original idea was to have .bc files hold lots of other...

On Fri, 20 Aug 2004, Robert Mykland wrote: > >In any case, both signed and unsigned 8-bit constants can be written out > >in a single byte. Again, do you think it's worth special casing this > >though? Considering that we handle 8-bit strings specially already, there > >are not a ton of 8-bit constants with value >= 128. > > I'd rather that they not be

...uot; // value. In version 5, we made this consistent. hasInconsistentBBSlotNums = true; // In version 4, the types SByte and UByte were encoded as vbr_uint so that // signed values > 63 and unsigned values >127 would be encoded as two // bytes. In version 5, they are encoded directly in a single byte. hasVBRByteTypes = true;...

...was planning on doubling > the referent type's slot number to get the pointer type. But, if all the > pointer types are not used in the program then this just serves to > increase the numerical values of the slot numbers and it will actually > bloat the size of the file because the vbr_uint written slot numbers > could take more bytes to write. Yes. > Contrary to previous assertions, I'm not going to implement this unless > we can prove that its beneficial. ok. > > I think that debug libraries should be handled in other ways. The > > original idea was to...

...o and his answer was that they just disappear into the names of things (via mangling). However, I still think that it would save some bytecode file size if we could eliminate the redundant (namespace) parts of each symbol. Essentially, we'd be replacing the portion of a symbol's name with a vbr_uint to the namespace object. Anyway, this is a larger design question that needs a larger audience. I'd want to hear from mnost of the other developers on this topic. > > Gosh, but at the very least, since it's a special case anyway, we could > shrink this field down to a byte. It...

At 02:05 PM 8/20/2004, you wrote: >Robert Mykland wrote: >>Dear Chris and Reid: > >Hi Robert. > >>Some other random ideas I've had as I've been sifting through the new >>bytecode format. Please let me know what you think. >>1) ANSI C allows for char to default to unsigned char. This is I guess >>not how it normally is in GCC. If char defaulted