search for: zerofil

Hi, I need some help improving this ugly code I wrote. I would like to shift forward a zoo object, matrix, ts, or list by "shift" items (default 1) and fill the holes with 0's. The code below works, but it looks ugly. I could write a function lag.zerofill() which calls the two functions below depending on the class() of the item passed in, but that feels very unlike R. What is the proper way to write this code so that it works for all input types? Is a switch depending on the input type really necessary? I am hoping the answer is "no&quot...

Hi there- What''s the easiest/most efficient way to perform a zerofill in Ruby? i.e. Given the value ''val'', I would like to do something like: val = 43 puts val.zerofill(8) ---> "00000043" gsub? sprintf of some sort? Jake -- Posted via http://www.ruby-forum.com/.

...get a storage optimization. > > > I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: $ llc t.ll -o - -mtriple=i386-apple-darwin10 .section __TEXT,__text,regular,pure_instructions .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 .section __DATA,__data _tst2:...

...on. >> >> > I don't know, I see common and it makes me think that things are getting > merged together, but as you say it is local so the fact that its also common > becomes irrelevant. In MachO do you just put these into the .bss section? > > > Macho has a special zerofill directive (targeted at the BSS section) for > this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__dat...

.... >> >> >> I don't know, I see common and it makes me think that things are getting merged together, but as you say it is local so the fact that its also common becomes irrelevant. In MachO do you just put these into the .bss section? >> > > Macho has a special zerofill directive (targeted at the BSS section) for this. You can see this by running your example like this: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 > .section __TEXT,__text,regular,pure_instructions > .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 > .section __DATA,__data &...

...============================================================ --- lib/Target/ARM/ARMTargetAsmInfo.cpp (revision 48700) +++ lib/Target/ARM/ARMTargetAsmInfo.cpp (working copy) @@ -49,7 +49,7 @@ PrivateGlobalPrefix = "L"; BSSSection = 0; // no BSS section. ZeroFillDirective = "\t.zerofill\t"; // Uses .zerofill - SetDirective = "\t.set"; + SetDirective = "\t.set\t"; WeakRefDirective = "\t.weak_reference\t"; HiddenDirective = "\t.private_extern\t"; ProtectedDirective = NULL; I unfortunate...

...t;> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >&g...

...ELF specific ".type" - bool ParseDirectiveDarwinSymbolDesc(); // Darwin specific ".desc" - bool ParseDirectiveDarwinLsym(); // Darwin specific ".lsym" - - bool ParseDirectiveComm(bool IsLocal); // ".comm" and ".lcomm" - bool ParseDirectiveDarwinZerofill(); // Darwin specific ".zerofill" - bool ParseDirectiveDarwinTBSS(); // Darwin specific ".tbss" - - // Darwin specific ".subsections_via_symbols" - bool ParseDirectiveDarwinSubsectionsViaSymbols(); - // Darwin specific .dump and .load - bool ParseDirectiveDarwinD...

...t;> I don't know, I see common and it makes me think that things are getting >> merged together, but as you say it is local so the fact that its also common >> becomes irrelevant. In MachO do you just put these into the .bss section? >> >> >> Macho has a special zerofill directive (targeted at the BSS section) for >> this. You can see this by running your example like this: >> >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >&g...

On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote: >> $ llc t.ll -o - -mtriple=i386-apple-darwin10 >> .section __TEXT,__text,regular,pure_instructions >> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >> .section __DATA,__data >> _tst2: ## @tst2 >> .ascii "\000\001\002\003" >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' OutStream methods, the la...

On Fri, May 7, 2010 at 9:01 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: >> >> > I compile these two lines in llc >> > >> >

On May 7, 2010, at 12:39 AM, Nathan Jeffords wrote: > On Fri, May 7, 2010 at 12:03 AM, Chris Lattner <clattner at apple.com> wrote: > > On May 6, 2010, at 10:01 PM, Nathan Jeffords wrote: > > > I compile these two lines in llc > > > > @tst1 = internal global [4 x i8] zeroinitializer; > > @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; >

> > > > We may need some additional info. What kind of additional info? > I haven't put a ton of thought into > this, but I'm hoping we can either (a) use debug info as is or add some > extra (valid) debug info to support this, or (b) add an extra > debug-info-like section to instrumented binaries with the information we > need. > I'd try this data

On Fri, May 7, 2010 at 12:58 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 7, 2010, at 11:42 AM, Nathan Jeffords wrote: > > $ llc t.ll -o - -mtriple=i386-apple-darwin10 >>> .section __TEXT,__text,regular,pure_instructions >>> .zerofill __DATA,__bss,_tst1,4,0 ## @tst1 >>> .section __DATA,__data >>> _tst2: ## @tst2 >>> .ascii "\000\001\002\003" >>> >> >> I think we should have an 'EmitZeroFill()' and 'EmitASCII()' Out...

...nerate code quickly instead of optimizing the generated code. * Many compile-time speedups in the code generator. * The target-independent AsmPrinter module has many new features, such as support for emitting ".asciz" instead of ".ascii" when possible, support for .zerofill, support for targets that accept quoted labels, etc, and it reduces the amount of target-specific code that needs to be written. * Nate added support for byte-swap and bit rotate nodes. * The legalizer pass is now non-iterative (==faster), more simple, and several nasty libcall inser...

...> instead of optimizing the generated code. > * Many compile-time speedups in the code generator. > * The target-independent AsmPrinter module has many new features, such as > support for emitting ".asciz" instead of ".ascii" when possible, > support for .zerofill, support for targets that accept quoted labels, > etc, and it reduces the amount of target-specific code that needs to > be written. > * Nate added support for byte-swap and bit rotate nodes. > * The legalizer pass is now non-iterative (==faster), more simple, and > several...

...ckly instead of optimizing the generated code. 34. There are many compile-time speedups in the code generator. 35. The target-independent AsmPrinter module has many new features, such as support for emitting ".asciz" instead of ".ascii" when possible, support for .zerofill, support for targets that accept quoted labels, etc, and it reduces the amount of target-specific code that needs to be written. 36. Nate added support for byte-swap and bit rotate nodes. 37. The legalizer pass is now non-iterative (==faster), simpler, and several nasty libcall inse...