-
Notifications
You must be signed in to change notification settings - Fork 5
Unimplemented and incomplete features
The int type should be 64-bit on 64-bit platforms. When this is done, we must also fix type structures to use the architecture-specific int type where int32 is currently being used (e.g. in len/cap of slice header).
Work-in-progress (discussion forthcoming to llgo-dev).
Also: various parts of the current implementation are incomplete, such as hash computation for runtime types. This will be rectified over time, as the information is required by the runtime.
"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.
Type checking only works well in the trivial case right now, i.e. when given a correct program, type checking is expected to work. We should resynchronise with the new exp/types, which gri has improved to the point that it is able to type-check most of the Go standard library, and provides an API suitable for use in llgo.
Closures are currently implemented using LLVM's trampoline intrinsics. In order to improve portability (by not relying on executable heap), we should change to using a pair of pointers to represent stored functions. One pointer will be the real function pointer, and the second will be a memory block to pass in as the first (synthesised) parameter to the function; this memory block will store captured values for closures.
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.