search for: ubytetyid

...ad of the present > > usual two. > > So, if I get you correctly, you're advocating the creation of a Type::CharTyID > in the TypeID enumeration that is always written as a single byte? Note that > right now all ASCII values ( <128 ) will be written as a single byte for > UByteTyID but for SByteTyID (often the default from FE compilers like GCC), > you're right, they'll take two bytes if the value > 63. Or are you saying that > we should always write UByteTyID and SByteTyID as a single byte? > > Long term, LLVM's distinction between signed and unsi...

...stored in one byte instead of the present > usual two. So, if I get you correctly, you're advocating the creation of a Type::CharTyID in the TypeID enumeration that is always written as a single byte? Note that right now all ASCII values ( <128 ) will be written as a single byte for UByteTyID but for SByteTyID (often the default from FE compilers like GCC), you're right, they'll take two bytes if the value > 63. Or are you saying that we should always write UByteTyID and SByteTyID as a single byte? Long term, LLVM's distinction between signed and unsigned will go away...

...nsigned-char. I don't > understand how that would change anything to be more useful though. The only thing it would change is that character constants with values > 63 would get encoded in 1 byte instead of 2 (with current implementation). I'm making a change that will ALWAYS encode UByteTyID and SByteTyID constants in 1 byte which would then render -funsigned-char useless (as far as bytecode goes). > Okay, that's fine. When implementing that, we should take care to create > the pointer types lazily instead of eagerly to avoid creating pointer > types that are not used....

Dear Chris and Reid: 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 to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

...;t > > understand how that would change anything to be more useful though. > > The only thing it would change is that character constants with values > > 63 would get encoded in 1 byte instead of 2 (with current > implementation). I'm making a change that will ALWAYS encode UByteTyID > and SByteTyID constants in 1 byte which would then render > -funsigned-char useless (as far as bytecode goes). It's 127 right, not 63? Also, what does this have to do with sbyte vs ubyte? > > Okay, that's fine. When implementing that, we should take care to create > &gt...

.... > > > > So, if I get you correctly, you're advocating the creation of a > Type::CharTyID > > in the TypeID enumeration that is always written as a single byte? Note > that > > right now all ASCII values ( <128 ) will be written as a single byte for > > UByteTyID but for SByteTyID (often the default from FE compilers like GCC), > > you're right, they'll take two bytes if the value > 63. Or are you > saying that > > we should always write UByteTyID and SByteTyID as a single byte? > > > > Long term, LLVM's distincti...

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

...ackend, I tries this code stolen from X86 backend: const TargetData& TD = m_tm.getTargetData(); unsigned size = TD.getTypeSize(initializer->getType()); However, the getTypeInfo function in TargetData.cpp contains this: case Type::VoidTyID: case Type::BoolTyID: case Type::UByteTyID: case Type::SByteTyID: Size = 1; Alignment = TD->getByteAlignment(); return; The problem is that my target can't address bytes -- the memory interface itself specifies word addresses. For that reason, I'd like to allocate 4-byte (word) blocks even for bools/chars/ubytes a...

...Lattner wrote: > On Fri, 20 Aug 2004, Reid Spencer wrote: > > > > The only thing it would change is that character constants with values > > > 63 would get encoded in 1 byte instead of 2 (with current > > implementation). I'm making a change that will ALWAYS encode UByteTyID > > and SByteTyID constants in 1 byte which would then render > > -funsigned-char useless (as far as bytecode goes). > > It's 127 right, not 63? Also, what does this have to do with sbyte vs > ubyte? No, its 63. Signed bit takes up one bit and "continue bit" ta...

...t; > I'd rather that they not be treated specially. If char defaulted to > unsigned char, there would be little reason to create this special case. Actually, this isn't a very big deal. Its just handled in a switch() statement now so I just make a couple more cases that handle the UByteTyID and SByteTyID separately. I'll probably include this in 1.4 > > > > This approach would have the added advantage of being able to check to > > > > see whether anything is a pointer type by checking bit 0 (1 = yes) and > > > > deriving its dereferenced type...

...byte instead of the present usual two. > >So, if I get you correctly, you're advocating the creation of a >Type::CharTyID in the TypeID enumeration that is always written as a >single byte? Note that right now all ASCII values ( <128 ) will be written >as a single byte for UByteTyID but for SByteTyID (often the default from >FE compilers like GCC), you're right, they'll take two bytes if the >value > 63. Or are you saying that we should always write UByteTyID and >SByteTyID as a single byte? > >Long term, LLVM's distinction between signed and...