On 9 January 2013 20:58, Eliot Miranda <[email protected]> wrote: > > > Just wrap the assembler up in a string. But this low level shouldn't be > necessary. If you went the compile-time route then you'd analyse the call > according to the platform's ABI and figure out the assembler automatically. > This is the architecture I was hoping yopu'd implement. If the compilation > step is left until the first call then the signatire becomes > platform-independent. >
Assembler is absolutely necessary, because it is a developer who can decide to use it, not me. I just giving an opportunity. This is a primary objective of NativeBoost project. NativeBoost includes FFI implementation as integral part of it. But that doesn't means that i should narrow it down only for this purpose. If i want to implement a primitive using brute-force assembler, it is logical to put it in the source of corresponding method, not somewhere else. Also, since this is executable code, and does not requires separate parser/compiler, you are free to extensively practice a code-reuse, as in any smalltalk code you write (as well as make it platform independent, btw). And so, users are free to mix assembler with own code, and there is little or no constraints and canonical forms, to which everyone should adhere. It is just plain smalltalk. > For a clunkier approach see my callback implementation where you build up a > library of transformers indexed by signature. The library contains > different versions for each platform. If you applied this simple idea to > the above you'd have some pragma somewhere which said "on x86 with signature > #( void (void * address, double aDouble) ) output this marshalling code: > #(pop: EDX "load an...") etc. And then the call site would just supply the > signature. You'd get to share the marshalling code between functions having > the same signatures and you'd have a level of platform-independence. > Wait.. Let us separate concerns. Platform-independence is orthogonal to use (or not) use of pragmas in code. I do not see why i need to focus on platform independence right here right now. Does our beloved VM runs anywhere else than on 32-bit x86 CPUs? Once there will be other options, trust me, i will be first who will concentrate on making things properly separated. But when it is not , why i do even need to think/do something about it? x64 using completely different call convention(s), not saying that object format will require some changes, and as result VM interface(s) as well.. So, why i should constrain myself and introduce some "platform independece" when i have no real thing at hand, so i don't even have a clue whether my "platform-independent" solution will will fit well with future VM/platform or not? Aside of it, right now, you can debug the code generation and see everything from starting point up to the end, using debugger just by stepping into method which uses NB call. You can see what happens, and see how your function signature turned into real bytes which then fed to CPU. So, users can LEARN and improve it. Now if you split things , or even worse, move all logic at compile time, you will make things opaque enough for debugging it and understanding how it works. Yes, this is good, if intent is to prevent a "regular" developer to even think that he can directly use assembler. But my intent is actually straightly opposite. My intent is to expose users to it. I am perfectly fine with those who prefer to keep playing with plastic toys without risk of hurting themselves. But plastic world(s) has own limits, and so, if you want to reach outside, then there is no magic, you have to stop playing in sandbox with plastic toys, but instead grow up and take some risk and responsibility. And so, my philosophy (and NB as well) is to help people breaking out and combine best of two worlds. Because, at the end, which code is more secure/safe: - a well debugged and tested C code - or a well debugged and tested smalltalk code ? -- Best regards, Igor Stasenko.
