cvs commit: hugs98/src storage.c storage.h static.c machdep.c connect.h
sof 2003/01/31 22:36:56 PST Modified files: src storage.c storage.h static.c machdep.c connect.h Log: Backwards compatibility for IO primitives implemented using HugsAPI1-4. IO actions now take a single continuation rather than two, causing the stated arity of IO primitives built with these earlier versions of HugsAPI to be off by one. By keeping track of what IO representation an extension DLL assumes, we adjust the arity of IO primitives when they're added to the name table in storage.c:addPrims(). ToDo: bump HugsAPI up to 5...no change in functionality, but if you implement HugsAPI5 you're assumed to be using new IO monad rep. Revision Changes Path 1.61 +27 -6 hugs98/src/storage.c 1.49 +3 -2 hugs98/src/storage.h 1.136 +13 -4 hugs98/src/static.c 1.75 +13 -4 hugs98/src/machdep.c 1.65 +3 -2 hugs98/src/connect.h
On Fri, Jan 31, 2003 at 10:36:56PM -0800, Sigbjorn Finne wrote:
sof 2003/01/31 22:36:56 PST
Modified files: src storage.c storage.h static.c machdep.c connect.h Log: Backwards compatibility for IO primitives implemented using HugsAPI1-4. IO actions now take a single continuation rather than two, causing the stated arity of IO primitives built with these earlier versions of HugsAPI to be off by one. By keeping track of what IO representation an extension DLL assumes, we adjust the arity of IO primitives when they're added to the name table in storage.c:addPrims().
I am sorry about causing this mess, and appreciate your flexibility. But I don't understand how the API versioning works, when the version is selected by the interpreter rather than the DLL. Ross
"Ross Paterson"
...
But I don't understand how the API versioning works, when the version is selected by the interpreter rather than the DLL.
Modules that have 'primitive'-based extension DLLs associated with them are required to use a 'needPrims_hugs <api version>' declaration to signal its loading. That version number is all that's needed. This doesn't deal with extension DLLs generated by the new FFI, where the interpreter simply assumes a specific version number. There aren't too many of those DLLs floating about (yet), which is why I mentioned that these will simply have to be re-compiled for now. The DLL external interface will have to be extended to also convey what HugsAPI version number the exported primitives assume. ---sigbjorn
"Ross Paterson"
But I don't understand how the API versioning works, when the version is selected by the interpreter rather than the DLL.
Sigbjorn's description of how it works describes the status quo but I think we can/should look at changing it. It is my intention that we should stop supporting code generated using 'greencard --target=hugs' since the --target=ffi code does at least as much. We should have a strategy to detect problems caused by dropping support but no more. So, looking at code generated using 'hugs +G', etc. what we're worried about is people using code generated by old versions of Hugs where the binary layout of the virtual table may be different. The simplest way to detect problems would be to have a simple consistency check. For example the 'API number' could be the release date for that Hugs version (e.g. 03022003). This should be inserted in the generated C code. Easy to maintain, works ok with binary packaging systems, will require some recompilation sometimes. We could get fancier (as Hugs was until a month or so ago) and maintain the last few major versions of the binary API. The only difference here is thet the interpreter will accept one of several different API versions. More hassle to maintain for us, a bit easier for people upgrading Hugs or maintaining binary packages. My current feeling is that it's a good idea to check a version number but that supporting more than one version of the binary API isn't necessary. -- Alastair ps There are fancier variants on this plan where the generated code finds functions in the vtable by doing lookups like: cache.getInt8 = hugs->find_function(HUGS_GET_INT8); cache.getInt16 = hugs->find_function(HUGS_GET_INT16); cache.getInt32 = hugs->find_function(HUGS_GET_INT32); The lookup key would be like a COM UID - any change to the semantics of a function requires that the UID be changed. It'd be more tedious changing the code to be like this but easier to maintain in the long run.
participants (4)
-
Alastair Reid -
Ross Paterson -
Sigbjorn Finne -
Sigbjorn Finne