Posts Tagged 'codeswitch'
CodeSwitch assembly glue for native functions
Last time, I discussed native functions, but I didn't really talk about how CodeSwitch makes the transition from interpreted code to native code. CodeSwitch uses a bit of assembly glue code to load arguments from the interpreter's stack into the right places.
CodeSwitch API: native functions
I've added the capability for CodeSwitch to call native functions written in C++. This means that when you write a package, part of it can be written in Gypsum, and part of it in C++. This is useful for implementing new low-level primitives, such as files and sockets.
CodeSwitch API improvements
CodeSwitch is designed to be a library that can be embedded in any application. A good API is crucial. While I can't say that CodeSwitch's C++ API is completely stable yet, I think it's gotten to a pretty usable state.
Memory management in CodeSwitch
CodeSwitch has its own garbage collected heap, which is used not only for objects allocated by interpreted code, but also for most internal data structures. In this article, I'll describe how the heap is built, how the garbage collector works, and how it tracks pointers to the heap from C++ code.
CodeSwitch bytecode and interpretation
The interpreter is essentially a loop with a big switch-statement. In each iteration, it reads one instruction, switches on the opcode, branches to the appropriate case, then executes some code for that instruction.
Package loading in CodeSwitch
CodeSwitch manages code in chunks called packages. Each package is stored in a separate file. A package has a name, a version, and a list of dependencies (other packages it depends on). Each dependency has a name, a minimum version, and a maximum version (both versions are optional).
How CodeSwitch got its name
Code switching is a linguistic term for when a person speaks in one language, then switches to another language mid-sentence. I want programmers to be able to do that with code.
Packages in Gypsum and CodeSwitch
Packages are named bundles of related code. They make code easier to understand and distribute. Each package is compiled into a single file, and has a unique name, a version, and a list of dependencies.