search for: ascenium

...t have to do much of >this. I know my reader does this. I'm not really sure how much time it spends doing it. My little code generator spends a lot of time going back and forth between pointers and literal values when turning certain kinds of memory operations into data movement in the Ascenium array. > > > 3) Have the value index for labels start at 1, just like nonzero values > > > of everything else does. This just makes the encode/decode algorithm > > > simpler and I doubt it would cost anything in file size. I made this > > > suggestion a few em...

...this. > > I know my reader does this. I'm not really sure how much time it spends > doing it. My little code generator spends a lot of time going back and > forth between pointers and literal values when turning certain kinds of > memory operations into data movement in the Ascenium array. I will probably make this change in 1.4 to eek out a few more bytes of savings from the file and since it will help Robert. > > > > 4) Can files have multiple 0x01 headers? I've never seen more than > > > > one. If not, ditch this four bytes of unnecessary spa...

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

Hi Robert, Please make sure that you: 1. Completely rebuild LLVM (make clean; make reconfigure; make tools-only) 2. Completely rebuild llvm-gcc (wipe out the build dir with rm -rf, configure llvm-gcc and rebuild it) If you've done that, then please enter the debugger and get a stack trace for us. You will need to: 1. Capture the xgcc compile command that failed 2. Run that command

.....print|<br> 000000a0 66 01 0f 01 04 6d 61 69 6e 01 0d 01 03 73 74 72 |f....main....str|<br> 000000b0<br> <br> </font> <pre class="moz-signature" cols="72">-- Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation "A new world of computing fulfilling people's lives"</pre> </body> </html>

....a] Error 2<br> make[1]: Leaving directory `/home/mykland/llvm-gcc/obj/gcc'<br> make: *** [all-gcc] Error 2<br> <br> <b>Afterwards, when I run it on the command line after the make has failed the error messages look like this:</b><br> <br> mykland@ascenium:~/llvm-gcc/obj> /home/mykland/llvm-gcc/obj/gcc/xgcc -B/home/mykland/llvm-gcc/obj/gcc/ -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/bin/ -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/lib/ -isystem /home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/include -isystem...

I was having video problems, so upgraded my Linux box from SUSE 9.3, where LLVM frontend 4 source built fine, to SUSE 10.1, where I got the error message: ../../llvm-gcc4-1.8-source/gcc/libgcc2.c:541: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs> for instructions. This version of SUSE

...ces. Seperate modules would make it simple. But as I said before, you could still dump the 0x01 and have multiple modules per file so that each module in a debug library could have its own name space. -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

On Mon, 23 Aug 2004, Reid Spencer wrote: > > If all pointer types are implied, not a problem to create them. However, > > in larger files it may cost a little due to slightly larger type > > numbers. I'm not sure about the tradeoff here, but I expect that implied > > pointers would still save more just because of pointers to function types. > > Pointers are used

...pure data dependency simulator where we can evaluate the circuit in a random order and we get the correct answer every time. We are pretty pleased. This is running on version 1.8 of LLVM. Cheers, -- Robert. -- Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation "A new world of computing fulfilling people's lives"

...0x04 and size = 0x1a > 44 03 00 00 00 01 11 01 06 70 72 69 6e 74 |mpD........print| > 000000a0 66 01 0f 01 04 6d 61 69 6e 01 0d 01 03 73 74 72 | > f....main....str| > 000000b0 > > -- > Robert Mykland Voice: (831) 462-6725 > Founder/CTO Ascenium Corporation > "A new world of computing fulfilling people's lives" > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

.... In my experience this is the only way to get physical protocols like this right. Hope this helps! Thanks again to Reid for the great docs and to Chris and crew for the whole LLVM shebang. Regards, -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

...pen a bug report and attach a test case to it? This is >a serious problem that I need to fix but in order to do that I need a >reliable test case for repeatability. > >Thanks Robert. Will do. -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

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

...st a little due to slightly larger type numbers. I'm not sure about the tradeoff here, but I expect that implied pointers would still save more just because of pointers to function types. Regards, -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

...cc/obj/gcc' > make[1]: *** [libgcc.a] Error 2 > make[1]: Leaving directory `/home/mykland/llvm-gcc/obj/gcc' > make: *** [all-gcc] Error 2 > > Afterwards, when I run it on the command line after the make has > failed the error messages look like this: > > mykland at ascenium:~/llvm-gcc/obj> /home/mykland/llvm-gcc/obj/gcc/xgcc > -B/home/mykland/llvm-gcc/obj/gcc/ > -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/bin/ > -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/lib/ > -isystem /home/mykland/llvm-gcc/obj/../install//i686-pc-linux-...

...space wise. The >compaction table's *sole* purpose is to save bytecode space and its BAD if >it gets used incorrectly. It happens all the time! I guess this is a bug. Thanks for everything! -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

...2]: Leaving directory `/home/mykland/llvm-gcc/obj/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/home/mykland/llvm-gcc/obj/gcc' make: *** [all-gcc] Error 2 Afterwards, when I run it on the command line after the make has failed the error messages look like this: mykland@ascenium:~/llvm-gcc/obj> /home/mykland/llvm-gcc/obj/gcc/xgcc -B/home/mykland/llvm-gcc/obj/gcc/ -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/bin/ -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/lib/ -isystem /home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/include -isystem...

...1.4), the >blocks are no longer aligned. You're fine for version 3, but please make a >note of this change for version 4 bytecode files. Well never say never I guess. Thanks for everything, -- Robert. Robert Mykland Voice: (831) 462-6725 Founder/CTO Ascenium Corporation

...ke[1]: Leaving directory `/home/mykland/llvm-gcc/obj/gcc' > > > make: *** [all-gcc] Error 2 > > > > > > Afterwards, when I run it on the command line after the make has > > > failed the error messages look like this: > > > > > > mykland at ascenium:~/llvm-gcc/obj> /home/mykland/llvm-gcc/obj/gcc/xgcc > > > -B/home/mykland/llvm-gcc/obj/gcc/ > > > -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/bin/ > > > -B/home/mykland/llvm-gcc/obj/../install//i686-pc-linux-gnu/lib/ > > > -isystem /home/mykland...