Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] More Encoding Ideas"
2004 Aug 20
0
[LLVMdev] More Encoding Ideas
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 to unsigned char
> several things would be
2004 Aug 21
2
[LLVMdev] More Encoding Ideas
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
2004 Aug 21
4
[LLVMdev] More Encoding Ideas
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
2004 Aug 21
3
[LLVMdev] More Encoding Ideas
On Fri, 20 Aug 2004, Reid Spencer wrote:
> > defined would be almost always 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
2004 Aug 21
2
[LLVMdev] More Encoding Ideas
On Fri, 20 Aug 2004, Reid Spencer wrote:
> On Fri, 2004-08-20 at 18:43, Chris Lattner wrote:
>
> > I don't understand what you're getting at here. You can change char to
> > default to unsigned right now with llvm-gcc -funsigned-char. I don't
> > understand how that would change anything to be more useful though.
>
> The only thing it would change is
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 18:43, Chris Lattner wrote:
> I don't understand what you're getting at here. You can change char to
> default to unsigned right now with llvm-gcc -funsigned-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
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
At 05:09 PM 8/20/2004, you wrote:
>On Fri, 20 Aug 2004, Reid Spencer wrote:
> > > defined would be almost always 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
>
2004 Aug 24
4
[LLVMdev] More Encoding Ideas
On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> At 06:43 PM 8/20/2004, Chris Lattner wrote:
> >I don't understand what you're getting at here. You can change char to
> >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> >understand how that would change anything to be more useful though.
>
> Well, in the old days, char strings were
2004 Aug 26
0
[LLVMdev] More Encoding Ideas
At 09:37 PM 8/23/2004, you wrote:
>On Mon, 2004-08-23 at 19:46, Robert Mykland wrote:
> > At 06:43 PM 8/20/2004, Chris Lattner wrote:
> > >I don't understand what you're getting at here. You can change char to
> > >default to unsigned right now with llvm-gcc -funsigned-char. I don't
> > >understand how that would change anything to be more useful
2004 Nov 30
4
[LLVMdev] Trouble using llvm tools
On Tue, 30 Nov 2004, Tanu Sharma wrote:
> I have trouble using the llvm tools.Some of the errors are :
>
> $ llvm-dis prog.bc
> $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12)
Can you explain how you generated this bytecode file? It looks corrupted
or something. Also, can you send the actual bytecode file itself?
Thanks!
-Chris
>
2006 Oct 25
2
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I generated LLVM bytecode for a "hello world!" program just to get the
basic bytecode structure. I have
2006 Oct 26
0
[LLVMdev] Some basic questions about LLVM version 1.8 bytecode format
Hi Robert,
On Wed, 2006-10-25 at 16:00 -0600, Robert Mykland wrote:
> I generated LLVM bytecode for a "hello world!" program just to get the
> basic bytecode structure. I have a few questions about the global
> info module and the global constants module where there have
> apparently been changes since 1.4.
Okay.
> I would be happy to collect these differences and do
2004 Nov 30
0
[LLVMdev] Trouble using llvm tools
On Tue, 2004-11-30 at 08:58, Chris Lattner wrote:
> On Tue, 30 Nov 2004, Tanu Sharma wrote:
>
> > I have trouble using the llvm tools.Some of the errors are :
> >
> > $ llvm-dis prog.bc
> > $ llvm-dis: Invalid Top Level Block Length! Type:1, Size:456 (Vers=0, Pos=12)
>
> Can you explain how you generated this bytecode file? It looks corrupted
> or
2003 Aug 26
1
[LLVMdev] Question: Bytecode Representation of Type Definitions Table
Distinguished LLVM Creators,
I've been looking through the bytecode representation of the type
definition table and had a few questions about it. There's an enum in
Types.h that defines all bytecodes that represent the primitive types and a
few other necessary things:
0 = 0x00 = Void
1 = 0x01 = Bool
2 = 0x02 = UByte
3 = 0x03 = SByte
4 = 0x04 = UShort (16 bits)
5 = 0x05 =
2004 Aug 24
0
[LLVMdev] More Encoding Ideas
At 06:43 PM 8/20/2004, Chris Lattner wrote:
>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
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 19:10, Chris 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
2004 Aug 16
2
[LLVMdev] Bytecode file bugs / doc bugs
Dear Reid and Chris,
I thought I should send this to the list in case anyone else is struggling
to interpret bytecode files with the new docs.
(1) First a bug I already mentioned to Reid. Unlike the other new
module headers module 0x01 still uses the old 32-bit and 32-bit format
instead of the new 5-bit and 27-bit format. Thus the first module in the
file will be 0x00000001 followed by
2004 Aug 21
0
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 17:39, Robert Mykland wrote:
> No, you're not getting the point. The bytecode is bloated by pointers to
> all types. Every time a type is defined pretty much a pointer is defined
> with it already, and since the pointer type is not implied by the
> definition of the literal, we waste two or more bytes whenever we define a
> type. I'm advocating
2003 Aug 26
3
[LLVMdev] Seemingly ambiguous parameter lists
LLVMers,
And while we're on the subject to the type definitions table, what's the
difference between
0e 07 01 00
function returning Int ( Void )? Function returning Int ( ... )?
and
0e 07 00
Function returning Int ()
I'm guessing the former really is a function returning Int ( ... ), but how
is the callee supposed to decode the parameter list? I'm an old callee and
I
2004 Aug 21
2
[LLVMdev] More Encoding Ideas
On Fri, 2004-08-20 at 17:55, Robert Mykland wrote:
> At 05:09 PM 8/20/2004, Chris Lattner wrote:
> >
> >If you're interested in the plans, they are described in some detail here:
> >http://nondot.org/sabre/LLVMNotes/TypeSystemChanges.txt
> >
> >Note that there is no concrete timeline for this to happen, it basically
> >depends on when someone is ambitious