So I spent some time refactoring the CoolBasic Classic compiler and the Cool VES virtual machine to now operate with signatures instead of arbitrary function IDs. The signature comprises of the function’s name, and the number and types of its parameters (but not its return type.) Based on the supplied arguments, the compiler determines exactly which function to call (and ambiguous function candidates would generate a compile time error.) Therefore, it’s sufficient to just issue “Call a method with this signature” at runtime because the compiler has already enforced that there will be no ambiguity. Introducing function signaturesĪ better way to refer to a function is by signature.
But there’s a little design flaw here… What if we wanted to import functions from another DLL and they had ambiguous IDs.
PUREBASIC IMAGE MEMORY ALLOCATION CODE
Nice, so that’s how we call native code from a CoolBasic program. At runtime, the virtual machine will call a delegate who had defined an ID of 15. When the compiler emits the CallHost instruction it also attaches the number 15 on it. Let’s say a function “PlaySound” has an ID of 15. This list of commands is then fed to both the code editor (so it can syntax highlight,) and the CoolBasic Classic compiler (so it recognizes them.) Within the executing engine, CoolBasic functions are called in a certain way, and functions provided by the hosting engine are called differently (since they’re native code.)Ī host function defines an ID that is presented to the CBC compiler. The engine basically gives a list of commands available in it.
One engine may offer a completely different set of commands than the other (and this is also where project types come into play, more about that later.) The design philosophy here is that CoolBasic Classic is just a language, and there can be any number of game engines that can run CoolBasic code. They’re provided by the engine that’s interpreting the compiled program. The CoolBasic Classic language itself doesn’t include functions such as LoadImage or PlaySound. You’d call them just like any other user-defined function, and you don’t have to declare them before use. But before diving deeper into that, there’s an alternative way to integrate external libraries so that you can use them directly in code. It’s on the TODO list, and both the compiler and runtime have a preliminary support for it already in place. Something like that may still come in for CoolBasic Classic. It’s not a very resourceful way to support or use external DLLs, and I would have liked to implement a proper syntax like Declare Function GetTickCount Lib "kernel32" Alias "GetTickCount" () As Integer. You’d allocate memory for the in parameters and the return value.
To relief this limitation, CallDll was introduced. cb files in the beginning of their programs.Īs CoolBasic is interpreted, the need to execute code with native speed soon become apparent. If you wanted to create a “library” it’d have to be written in CoolBasic and then you’d have to give away the source code. The original design didn’t really support utilizing external code. One of the shortcomings of the old CoolBasic is its limited extensibility.
0 kommentar(er)
