Re: [Pearpc-devel] Proposal: jitc_x86-64 ( linux, that is ! )

[Sebastian B. <sb...@bi...>]

Jens von der Heydt wrote:

>> What means they differ? Is there no #pragma oder __attribute__ for the
>> functions? That's currently used to make the interface predictable...
> 
> i don't know of any compiler switches our defines that would change
> the amd64 ABI in gcc (currently). Information on porting to amd64 on
> WINDOWS is quite easy to find whereas linux docs are sparse
> but there are some. I will drop them onto my webspace for everybody
> to download. It took me quite some googling to find something that's
> for linux and ONLY for linux :) Even the calling conventions were
> extremely hard to find. Strange enough...

The real problem is that there is no gcc port for x86_64 windows yet.

> 
> and AMD states linux's calling conventions to be "quite the same" but 
> not identical.
> For example: Calling convention is fastcall, BUT Registers are: RDI, 
> RSI, RSX, RCX, R8, R9
> and XMMS (not important here).
> 
> So if we cannot define a clearn calling convention for our jit, the 
> assembler
> won't be compatible - the generated code could be.

No, I couldn't if it has to call functions.

> 
>>
>>> Who is interested in this new approach, who is willing to help?
>>
>> Maybe you should wait a little bit, since I'm currently thinking about
>> making the jitc/jitc-generated-code reentrant, i.e. independent of
>> global variables.
> 
> Well, I don't expect any mayor code release in the amd64 direction  very
> soon...
> But you could explain a little more why you would like to do this.

Well, as I wrote: to make it reentrant, so you can have multiple CPUs
(SMP or just a gui with multiple windows etc.)

> 
>>> I'd say we start with the linux plattform since gcc-4 and yasm are
>>> supporting all
>>> that we need, whereas visual studio (and cygwin ?) would require a 
>>> major
>>> rewriting of the jitc to work, leave alone starting on the main
>>> subject: 64bit.
>>>
>>> It might be a good starting point if the main devs, like  Sebastian  and
>>> Daniel, would
>>> jump onto this thread to delegate the way (hint, hint: MMU :) )
>>
>> There is no chance that the x86_64 mmu will be any better than the x86
>> mmu as long as the mmu branch doesn't work. And there is no way I'll
>> look into x86_64 as long as HT has no x86_64 disassembler... :)
> 
> Could be true, I was asking for the MMU subject because that's
> a part where I'm going to fail :)  

And as long as we don't get the x86 hwmmu to work I doubt we can
accelerate the x86_64 mmu.

> ... by the way, there's a nice 
> simulator
> by AMD you can download at www. x86-64.org

> 
> .. and what's HT anyway? :)
> 

My most important debugging tool :)

Sebastian