search for: sbytetyid

...ently working on, I do the following to cast a function pointer from one type to another. Hopefully the line wrapping won't totally destroy this. std::vector<const Type*> paramTypes; // First parameter: a void pointer paramTypes.push_back( PointerType::get( Type::getPrimitiveType( Type::SByteTyID ) ) ); FunctionType* pthreadFunctionType = FunctionType::get( PointerType::get( Type::getPrimitiveType( Type::SByteTyID ) ), paramTypes, false ); assert( pthreadFunctionType != NULL ); // Cast the function to the pthread function type Value* castedFunction = new CastInst( function, Pointe...

I recently ran into the following problem. I'm prototyping a compiler for a dynamically typed language in which functions are first class objects. Assuming I have something like this: if(rand() > 5) i = define(x, y, z) { return x + y + z; } else i = define(x, y) { return x + y; } At this point I cannot know the type of 'i' at compile time. At runtime 'i' is a

...> > 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....

...e 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. Talk to Chris a...

...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. Eww .. you jus...

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

...tand 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 > > the pointer types...

...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 distinction between signed...

...g to cast a > function pointer from one type to another. Hopefully the line wrapping > won't totally destroy this. > > std::vector<const Type*> paramTypes; > > // First parameter: a void pointer > paramTypes.push_back( PointerType::get( Type::getPrimitiveType( Type::SByteTyID ) ) ); > > FunctionType* pthreadFunctionType = FunctionType::get( > PointerType::get( Type::getPrimitiveType( Type::SByteTyID ) ), > paramTypes, false ); > assert( pthreadFunctionType != NULL ); > > // Cast the function to the pthread function type > Value*...

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

...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 and so on. That's exac...

...ri, 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" takes up another so signed...

...;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 (just subtrac...

...he 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 a...