search for: binrary

On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: > I'm not related to the topic starter, but I see at least one huge > disadvantage of the dependency on link.exe. > W/o such a dependency it would be possible reliably generate Windows > executables on Linux or Mac, which has its own benefits (e.g. > distributed compilation) GRUB, the Grand Unified

On Sat, Oct 15, 2011 at 12:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sat, Oct 15, 2011 at 7:38 AM, Thomson <lilotom at gmail.com> wrote: >> I just found that some samples used link.exe from Visual Studio to generate >> the final image, does LLVM has a replacement for link.exe to generate the >> final binary? I'm not related to the topic

...taking the right approach with this. You can either have portability or you can play games with the calling convention assumed by the back end, or you can modify the compiler to suit your desired calling convention, but you probably can't get all three. I'm the guy behind HDTrans (dynamic binrary translation for x86), and we used direct x86 instruction emission as well, and we cheated like crazy on calling conventions, stacks, you name it. So I understand where you are coming from. I've also done some bytecode VM work. You just aren't going to get a portable result that way, and as...

For those who are new or forget - I have a RHEL 5 Server and a few dualboot XP w/SP2 and CentOS 5 systems. The Linux machines were installed straight of CD/DVD, no patches. I was initially going to try a single sign-on to the RH 5 box via LDAP, but RH says it simply isn't possible and I don't know my way around LDAP other than it is a database and exists. So, option 2 is to simply

Don Quixote de la Mancha <quixote at dulcineatech.com> writes: > On Sat, Oct 15, 2011 at 7:35 PM, Ivan Krasin <krasin at google.com> wrote: >> I'm not related to the topic starter, but I see at least one huge >> disadvantage of the dependency on link.exe. >> W/o such a dependency it would be possible reliably generate Windows >> executables on Linux or

Hello. >> It is stack VM, and one designed to utilize all the advantages of the assembly language implementation. > This sounds very, very familiar. Are you willing to share which > VM/language you're working on? I would like to because I think the additional context would be helpful...let me ask for permission first. >> doing this using using C (by C function calls, CPS)