-
Notifications
You must be signed in to change notification settings - Fork 5
Unimplemented and incomplete features
"go" statements are currently unimplemented; they were previously working using pthreads. At the least, we should one-to-one goroutine/thread implementation, as it is relatively simple to implement.
When goroutines are implemented, we should begin investigating implementation of an M-N goroutine/thread scheduler. We may want to lift the scheduler from gc's runtime.
"panic" is currently a crude println + trap; this is not recover()able, and serves only for debugging in the current runtime implementation. We have the option of using LLVM's exception handling support; this requires some investigation.
The "defer" statement is currently unimplemented; depending on how panic is implemented, we may want to use LLVM's exception handling support to invoke deferred functions in the face of panics.
Channels are currently not implemented in a very useful manner (rather, just so they work in a single-threaded application: see pkg/runtime/chan.go). When we have goroutine support, they will have to be reimplemented to handle concurrent operations. Also, their storage mechanism should be changed to be more efficient (e.g. using a circular buffer for bounded channels).
It is currently possible to construct and convert to complex numbers, and extract the real/imaginary parts. Operators remain to be implemented.
Heap allocation is currently provided by malloc from libc. Assuming we want to enable the creation of statically linked executables a la gc, malloc should be reimplemented in the llgo runtime.
There is currently no garbage collector at all. A precise GC would be ideal, time permitting.
Maps are implemented, but have a crude linked-list implementation. This should eventually be changed to use a more appropriate data structure, such as a hash map.
Interfaces are mostly implemented (TODO: enumerate missing functionality), but some short cuts have been taken.
Interface types are currently represented by llgo as (ptr, val, f1, f2, f3...) where f1 etc. are the interface method function pointers; this makes passing around interfaces with methods more expensive than necessary.
Interface conversions are currently not implemented properly (neither static, nor dynamic). Dynamic conversions in the runtime do not check function signatures properly, traverse embedded structures, etc.
There is currently no integration with cgo. It would be ideal to use clang for cgo, as it is capable of generating LLVM IR/bitcode, and is likely to be available alongside the required LLVM runtime.
Currently, all variables are allocated on the heap. We must implement escape analysis in order to move variables to the stack wherever possible.