search for: iword

Small nitpick: size_t is not guaranteed to be large enough to hold a pointer (only an array index, which can be less; though such platforms are pretty exotic now). [u]intptr_t are the types. Eugene On Mon, Aug 9, 2010 at 5:44 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote: > Hi, > > I'm generating some LLVM IR that has to mask out the lower bits two bits of > a

On Mon, Aug 9, 2010 at 4:08 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Mon, Aug 9, 2010 at 4:02 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote: >> >> >> On Mon, Aug 9, 2010 at 1:51 PM, Kenneth Uildriks <kennethuil at gmail.com> >> wrote: >>> >>> On Mon, Aug 9, 2010 at 2:43 PM, Joshua Warner <joshuawarner32 at

I looked through the "intp" thread. I don't really want to start that argument up again, but my immediate thought would be to create a new class of "picked-by-the-target" integer types (equivelents of size_t, intptr_t, etc...), and two new instructions, zcast and scast, which are only valid in the context of casting to / from integer types of unknown sizes. To begin with,

Hi, I'm generating some LLVM IR that has to mask out the lower bits two bits of a certain pointers. I expect this should be done like so (on a 32-bit architecture) ... %classPointer = ... %classPointer1 = ptrtoint i8** %classPointer to i32 %classPointer2 = and i32 -4, %classPointer1 %realClassPointer = inttoptr i32 %classPointer2 to i8** ... Ideally, I'd like to generate completely

...m; if(setsockopt(socket_handle, SOL_SOCKET, SO_BROADCAST, &byes, sizeof(byes)) >= 0) { if(bind(socket_handle, (struct sockaddr *) &broadcast_address, sizeof(broadcast_address)) < 0) { printf("bind error\n"); } memset(&nmp, 0, sizeof(nmp)); nmp.magic = IWord(NMP_MAGIC); nmp.code = IWord(NMP_LIST); sendto(socket_handle, &nmp, sizeof(nmp), 0, (struct sockaddr *) &broadcast_address, sizeof(broadcast_address)); printf("%-4s %-15s %-15s %-17s %6s\n", "Size", "IP Address", "Subnet", "MAC Address&qu...

On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: >>> 1) Is there a way to declare an integer type in the IR that >>> represents >>> "an int the same size as a pointer" without specifying exactly the >>> size >>> of a pointer? >> >> No. > > Chris: > >

On Tue, 2008-05-06 at 23:18 -0700, Chris Lattner wrote: > > 1) Is there a way to declare an integer type in the IR that represents > > "an int the same size as a pointer" without specifying exactly the > > size > > of a pointer? > > No. Chris: There are other languages that specify a "word" type along these lines. Would it be worth considering

On Wed, 7 May 2008, Gordon Henriksen wrote: >> What would this be used for? How is it defined? How does >> arithmetic work on it? > > Looking up the intptr type via TargetData is not a significant issue > for me, but I can see the appeal, and how its absence could constitute > a significant barrier to generating portable IR (provided, of course, > a portable language).

...13:24 -0700, Chris Lattner wrote: > Querying TargetData only works if you know the size of the pointer. :) Yes. For BitC purposes, querying TargetData would be sufficient as long as we don't care whether the emitted IR is neutral w.r.t. pointer size. Given this, I think that introducing an iWord type is not yet sufficiently well motivated from the BitC perspective. But it would sure be convenient if we could query TargetData at compile time to determine the target pointer size. Not essential, by any means, but it seems unnecessary to encode the knowledge redundantly (in both the IR layer...

That and the possibility of differently sized pointers made me hesitate to dive into implementing this. I guess nailing it down to be the platform equivalent of size_t would be sensible here. On Mon, Aug 9, 2010 at 1:37 PM, Eugene Toder <eltoder at gmail.com> wrote: > Small nitpick: size_t is not guaranteed to be large enough to hold a > pointer (only an array index, which can be

On 2008-05-07, at 03:05, Chris Lattner wrote: > On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote: > >> There are other languages that specify a "word" type along these >> lines. Would it be worth considering adding such a type to the IR, >> or is there a reason not to do so that I am failing to see? > > What would this be used for? How is it

...) > 0xFFFFFFFFU. Now imagine a target without a 64- bit divider. :) I guess each intermediate result could be cast back to a pointer and then back to an integer, but that seems unlovely. On 2008-05-07, at 08:25, Jonathan S. Shapiro wrote: > Meaning: on a machine having 32-bit registers, iWord is a type > treated by the IR as indistinguishable from i32. On a machine having > 64 bit registers, iWord is the a type treated by the IR as > indistinguishable from i64. Arithmetic works in the usual way. If > "iWord" is "i32" on your target, then it is acc...

...the fact that the index spans depend on the address > space size. I'm not clear whether it is a goal to have an IR that is > capable of being a neutral representation w.r.t. address space size. If > it *is* a goal, then I don't see how to do it without some form of > iIntPtr or iWord type, but I'm still very new to all this. i64 should be big enough for this. Just use i64. >> > �� Treated an ordinary integer for all operations except casts. >> >> Ok. What does this mean for add? This basically means that an intptr add >> cannot have usefull...

...ndex spans depend on the address > > space size. I'm not clear whether it is a goal to have an IR that is > > capable of being a neutral representation w.r.t. address space size. If > > it *is* a goal, then I don't see how to do it without some form of > > iIntPtr or iWord type, but I'm still very new to all this. > > i64 should be big enough for this. Just use i64. On a 32-bit platform, doesn't one want to use i32? That was the point that I was trying to make -- on a 32-bit platform one wants to use i32, while on a 64-bit platform one wants to use...

On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: >> On Wed, 7 May 2008, Jonathan S. Shapiro wrote: >>>> >>>> i64 should be big enough for this. Just use i64. >>> >>> On a 32-bit platform, doesn't one want to use i32? >> >> Why? What is wrong with i64? > > On its face,

On Wed, 2008-05-07 at 16:09 -0700, Chris Lattner wrote: > On Wed, 7 May 2008, Jonathan S. Shapiro wrote: > >> > >> i64 should be big enough for this. Just use i64. > > > > On a 32-bit platform, doesn't one want to use i32? > > Why? What is wrong with i64? On its face, the problem is that it doesn't fit in a native register... or is there something