Search results

You'll understand I can't comment too much on all that :) I don't intend on doing any instruction scheduling except where it's easy, where easy means: doesn't cost too many codegen cycles. Anyway given the number of ld/st I currently have, pairing will be low. BTW it is a known fact that...

I finally started taking care of x87. I took code from fdlibm for transcendental functions (the libm on the board isn't compiled with VFP) and I started adding support for FP in QEMU which only knew about integers. A side-effect is that there's no fast support for FP80 and this will cause some...

I lack a screen to setup my Beagle :( The board I'm talking about is a Cortex-A9 board. EDIT - For the fun, here is how it was when I started: ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 0.427 FLOATING-POINT INDEX: 0.136 Baseline...

Quick update: nbench gcc 4.1.2 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 2.126 FLOATING-POINT INDEX: 0.277 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA...

Currently QEMUonARM seems to exceed Pentium 75 speed for nbench in similar conditions (cf this). Note the results on that post are for a chip @400 MHz. No, I have no Pandora to test and can't seem to setup my Beagle :( OTOH Wine would slow it down, and it's very probable that the game...

So I definitely don't understand: ldr r2, [r1, r2]! ; r2' <- mem[r1 + r2] r1' <- r1 + r2 teq r2, r0 bne .L12 ldr pc, [r1, #4] ; pc <- mem[r1' + 4] = mem[r1 + r2 + 4] Is that really what you want? Your key and your pc are not in contiguous...

I miss something (sorry my brain is again not functioning due to heavy pain): the writeback will write r1+r2 to r1, which won't be the next word in general. That's QEMU original hash function, I'm not sure why it's done this way. I have not yet reached the point where I can do this kind of...

I was thinking about that too. The problem is programs that play with the return value...

Exophase: Yes, I often quote DynamoRIO work. It's probably because it's the only work I found that tested many things related to runtime code generation. But I'm well aware I should be cautious not to rely too much on what's in there since it's not a simulator (and also I usually don't accept...

You should come on IRC, that'd help the discussion, though others would miss it (I wonder how many people are interested by this...). I meant smaller numbers of different TCG ops, not smaller memory usage. Making TCG more expressive certainly was not a design goal given its original usage and...

Yes, it's not pretty at the moment :) As far as immediates go, doing it this way makes TCG smaller and this would ease transition to real SSA (though it's not really needed for SSA). When I said statically allocating 8 x86 registers, I meant something such as globally saying r00 = eax and so...

You're right: register allocation is fully dynamic; it's on my TODO list to change that, but I think it should be done along more invasive changes such as not doing instruction per instruction translation, which is a big limitation of QEMU (though flag handling is being done across a block)...

I have various local modifications, that I'm trying to push into QEMU head. The most important one (block linking fix) has been committed yesterday. Another one was proposed last week: it makes sure x86 registers can be allocated into ARM regs instead of being read from memory every time they...

Thanks! I'm downloading it and will give it a try on my PC. That's alas right.

Given I own none of the mentioned games (AoE, SimCity 2000 and Strarcraft), that's a problem :) Is there some free game of that era that runs on Windows? Ha and given I still use a remote board, there's no way I'll be able to test graphics things.

I took the oldest compiler I could put my hands on: gcc 2.96. The previous results that were posted are using gcc 4.1.2. Results on my machine: nbench gcc 4.1.2 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 1.866 FLOATING-POINT INDEX: 0.262...

cb88 correctly explained how to read the nbench results. And indeed floating-point is an issue at the moment; QEMU doesn't natively handle FP, so it's bound to be slow; it's on my TODO list :) As far as Wine goes, it takes its toll on all programs. We did an experiment with a friend on a...

Here are nbench results as measured by notaz (waiting for results from Pickle and Cpasjuste to crosscheck): 500Mhz TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233*...

You mean that instead of measuring QEMU nbench you spent time on Windows? :blink:

You're right and I thought it was clear, but it seems it's not, given some of the replies we get :)