1. 64-bit blues

I've run into a couple of problems converting to 64-bit Euphoria: The first, I've solved myself; the second is beyond my skill level.

Stats: Euphoria Interpreter v4.1.0 development 64-bit Linux, Using System Memory Revision Date: 2011-06-30 16:06:49, Id: 5038:3739d931e005

GTK version 3.4.1 EuGTK version 4.5.9 Platform Linux 3.2.0-23-generic #36-Ubuntu SMP ... x86_64 GNU/Linux 2x AMD Athlon II X2 220 Processor 3791MB Linux Mint Maya


To get string arrays to work in 64bits, I modified the marked lines in std/machine.e:


public function allocate_pointer_array(sequence pointers, types:boolean cleanup = 0) 
    atom pList 
	integer len = length(pointers)  * ADDRESS_LENGTH  
 
    pList = allocate( (len + ADDRESS_LENGTH ) ) 
    poke8(pList, pointers) --IGM these were poke4, will have to be wrapped in an 
    poke8(pList + len, 0)  --IGM ifdef to work on both platforms, I guess. 
	if cleanup then 
		return delete_routine( pList, FREE_ARRAY_RID ) 
	end if 
    return pList 
end function 

Do we already have a CPU_64 defined somewhere, otherwise, how best to determine this?


Problem passing pointers via c_func/c_proc?


SET: GtkWindow property: 'position'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 107 
     ARGS: {32874896,1} 
 
SET: GtkWindow property: 'border_width'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 108 
     ARGS: {32874896,1} 
 
SET: Cairo_t property: 'fill_rule'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 114 
     ARGS: {2604572528,0} -- first arg is the handle 
 
/home/irv/demos/GtkEngine.e:494 in function set()  
A machine-level exception occurred during execution of this statement (signal 11)  
The call at line 494 is: c_proc(method[VECTOR],args)

The same programs work perfectly when running 32-bit Eu, but there the handles never exceed 9 digits.

Further testing shows that both c_proc and c_func cause an exception whenever the handle passed to them looks too large; greater than 1_000_000_000 apparently.

This happens 100% of the time with test60.ex or any program which creates a Cairo object, and unreliably at random times with other controls.

What to do?

new topic     » topic index » view message » categorize

2. Re: 64-bit blues

irv said...

I've run into a couple of problems converting to 64-bit Euphoria: The first, I've solved myself; the second is beyond my skill level.

Stats: Euphoria Interpreter v4.1.0 development 64-bit Linux, Using System Memory Revision Date: 2011-06-30 16:06:49, Id: 5038:3739d931e005

You've got a pretty old version. The latest eubin (13MB) is from April 25th of 2012. I suspect that updating would solve this issue for you.

irv said...

Do we already have a CPU_64 defined somewhere, otherwise, how best to determine this?

There are several new ifdefs, though none are actually required. You can use sizeof( C_POINTER ) and poke_pointer() / peek_pointer() for dealing with pointers portably. The new ifdefs are:

  • BITS32 / BITS64
  • X86 / X86_64 / ARM
  • LONG32 / LONG64 - the size of a native C "long int" on this platform
irv said...

Problem passing pointers via c_func/c_proc?


SET: Cairo_t property: 'fill_rule'  
     Expects: Ptr Int  
     Returns: Nul  
     Vector: 114 
     ARGS: {2604572528,0} -- first arg is the handle 
 
/home/irv/demos/GtkEngine.e:494 in function set()  
A machine-level exception occurred during execution of this statement (signal 11)  
The call at line 494 is: c_proc(method[VECTOR],args)

The same programs work perfectly when running 32-bit Eu, but there the handles never exceed 9 digits.

Further testing shows that both c_proc and c_func cause an exception whenever the handle passed to them looks too large; greater than 1_000_000_000 apparently.

This happens 100% of the time with test60.ex or any program which creates a Cairo object, and unreliably at random times with other controls.

What to do?

Make sure that the parameter is defined as C_POINTER. In general, use the best match for whatever the C prototype is. Note that some of the C_* constants are different than in 4.0, because they actually refer to different things when you go to a 64-bit architecture.

Matt

new topic     » goto parent     » topic index » view message » categorize

3. Re: 64-bit blues

Thanks Matt:

I shall try this as soon as I get back home.

Oh, are the includes from 4.0.4 still usable, or do I need some updated ones?

new topic     » goto parent     » topic index » view message » categorize

4. Re: 64-bit blues

irv said...

Thanks Matt:

I shall try this as soon as I get back home.

Oh, are the includes from 4.0.4 still usable, or do I need some updated ones?

You should definitely update or you're going to have similar problems. I believe that eubin I linked to has everything, including updated documentation.

Matt

new topic     » goto parent     » topic index » view message » categorize

5. Re: 64-bit blues

Thanks! It indeed does work (all but a tiny part, see other post). I can now run on 32 or 64 bit machines!

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu