Re: define_c_func/proc and 64-bit return types

new topic     » goto parent     » topic index » view thread      » older message » newer message
ghaberek said...
petelomax said...

As far as Ansi/Unicode versions of dll routines go, don't we just leave that up to the programmer? Should 64-bit really be any different?

I'm pretty sure, especially on *NIX, that a 64-bit application will attempt to load 64-bit shared libraries, i.e. open_dll("libwhatever.so") will result in a call to e.g. /usr/lib/libwhatever.so on from a 32-bit app and /usr/lib64/libwhatever.so from a 64-bit app. So it isn't as "manual" of a process as calling FunctionA vs FunctionW. (I could be wrong but this is my basic understanding.)

Ah. Yes. It's generally impossible to link to a shared/dynamic library that isn't the same architecture (e.g., x86 vs x86-64). The operating system handles this for you. Windows has WOW64 and Linux has its own way of separating these things.

ghaberek said...
petelomax said...

As you say, 32-bit apps need to be able to throw 64-bit ints around, so I would add explicit C_I32, C_I64, C_UI32, C_UI64, etc as well as changing C_INT from #01000004 on 32-bit to #01000008 on 64-bit.

I think this is a great idea. Perhaps we could use some ifdef's to set the generic constants based on bitness:

Noooooooooooooooooooooooo...

ghaberek said...
public constant  
    C_INT32 = #01000004, 
    C_INT64 = #01000008 
 
ifdef EU64 then 
public constant C_INT = C_INT64 
elsedef 
public constant C_INT = C_INT32 
end ifdef 

What is gained here? I could possibly see having explicit C_INTN type of constants. But I really see only downside to linking these to the more generic C_INT type of constants.

Constructing the ifdefs for C_LONG is an exercise left to the reader.

ghaberek said...
petelomax said...

I would also say a 64-bit compiler should generate 64-bit apps; if you want to generate 32-bit apps on a 64-bit box then you should (also) install the 32-bit compiler. If the source has to differ, so be it.

I'm sure the translator could output the code differently based on a flag, and I know with GCC it's just -m32 versus -m64. Perhaps the translator could simply have the same options, and revert to its native bitness by default.

Yes, the translator handles this:

$ euc -? 
euc options: 
... 
   [-arch architecture]  <0356>:: Specify the target architecture (X86, X86_64, ARM) 
... 

Obviously, this is a 4.1 feature, since 4.0 is only available on a single architecture.

Matt

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu