apoch/epoch-language

Home of the Epoch Programming Language Project

epoch-language's Issues

Supplement code with checked assertions/assumptions

Currently many possible errors in the code are allowed to slide; introduce 
assertions (and, where appropriate ASSUMEs) to trap error conditions early 
and report them.

Consider splitting this up into "debug only" assertions that only Fugue 
developers will care about, and "user related" assertions that end-user Epoch 
programmers might be able to handle.

Original issue reported on code.google.com by [email protected] on 1 Feb 2010 at 5:19

Make function code blocks optional

There are cases where it may make sense to create a function that performs 
a simple operation and returns the result. For example:

add : (integer(x), integer(y)) -> (integer(ret, 0.0))
{
   ret = x + y
}

This function can be expressed more succinctly as:

add : (integer(x), integer(y)) -> (integer(ret, x + y))

For such cases the code block itself is useless as it is left empty.

Ensure it is possible to perform operations in the return value initializer 
list, and add support in the grammars/parser for omitting the subsequent 
(empty) code block.

Original issue reported on code.google.com by [email protected] on 30 Nov 2009 at 10:49

Add operations for random access (both read and write) of arrays

Arrays are currently fairly limited, due to the lack of read/write access 
operations. Define a syntax and implement the operations for reading and 
writing array values.

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 7:04

Functions invoked via CUDA blocks cannot return void

Returning void from a function which is invoked via a CUDA block will cause a 
crash.

Original issue reported on code.google.com by [email protected] on 28 Feb 2010 at 9:49

CUDASetThreads cannot handle function calls

If the CUDASetThreads() function is invoked with the return of another 
function as its parameter, the cross compiler doesn't know what to do.

Original issue reported on code.google.com by [email protected] on 28 Feb 2010 at 8:22

Function calls from return value initializers are broken

Test the following code file:


//
// RETVAL.EPOCH
//
// Test case for returning values from functions
//

entrypoint : () -> ()
{
    debugwritestring(cast(string, adderfunction(40, 2)))
    debugwritestring(cast(string, shortadderfunction(40, 2)))
    debugwritestring(cast(string, testfunction(40, 2))
    debugwritestring(cast(string, anothertestfunction(40, 2)))
}

adderfunction : (integer(a), integer(b)) -> (integer(ret, 0))
{
    ret = a + b
}

shortadderfunction : (integer(a), integer(b)) -> (integer(ret, a + b)) { }

testfunction : (integer(alpha), integer(beta)) -> (integer(value, 
shortadderfunction(alpha, beta))) { }

anothertestfunction : (integer(a), integer(b)) -> (integer(ret, testfunction(a, 
b) + testfunction(a, b))) { }


Currently this causes the parser to vomit.

Original issue reported on code.google.com by [email protected] on 18 Sep 2010 at 7:33

Implement failover to CPU when CUDA not available

Add functionality to redirect CUDA-flagged code blocks to the CPU if CUDA-
aware hardware is not available. This will ensure that programs remain at 
least minimally functional if the requested hardware support cannot be 
obtained.

Original issue reported on code.google.com by [email protected] on 8 Feb 2010 at 8:13

Add stream manipulators for output stream coloration

Supplement existing OutputStream.ColorFoo(); style functions with stream 
manipulators, to enable syntax like:

outstream << red << "This is red text." << endl;

Original issue reported on code.google.com by [email protected] on 21 Dec 2009 at 4:18

CUDA compiler cannot handle multiple active compile sessions

Invoking separate compilations simultaneously (i.e. before finalizing one of 
the compiles) causes EpochCUDA to mutilate the temporary files used during 
compilation. Temporary files should be allocated and named per compile 
session rather than globally.

Original issue reported on code.google.com by [email protected] on 29 Nov 2009 at 10:42

Improve error messages generated from CUDA extension

Currently when an error occurs inside a cuda block, the compiler loses track 
of what instruction is actually to blame, and displays spurious errors which 
often refer to the wrong line of code.

Original issue reported on code.google.com by [email protected] on 22 Feb 2010 at 2:38

Structure copy constructors don't work

When constructing a new structure-typed variable, it is not possible to use a 
"copy" style syntax. The parser expects explicit values for each field, when 
it often makes more sense to initialize the variable with the value of 
another structure of the same type.

There are two particular problems: copying from an existing variable with 
syntax of the form "foostruct(baz, quux)", and copying from a function return 
value with syntax of the form "foostruct(baz, xorph())". Both syntaxes should 
be supported in order to consider this issue resolved.

Original issue reported on code.google.com by [email protected] on 30 Nov 2009 at 11:47

• Blocking: #2

Improve exception types

Define specific exception types for particular sorts of errors (i.e. less 
generic than "ExecutionException" for example).

Original issue reported on code.google.com by [email protected] on 27 Feb 2010 at 7:43

Loop with empty body repeats infinitely

Release 7, as shipped

Run the following program:

entrypoint : () -> ()
{
    integer(y, 0)
    while(y++ < 100)
    {
    }

    debugwritestring("hi")
}


Program should quit after 100 iterations of the empty loop; instead, loops 
infinitely.

Original issue reported on code.google.com by [email protected] on 15 Jun 2009 at 3:48

Free blocks are not compiled correctly

When compiling a program, free blocks (artificial lexical scopes) do not get 
compiled correctly, due to missing traverser logic.

Original issue reported on code.google.com by [email protected] on 2 Mar 2010 at 1:24

Move infix tag to function declaration

Currently, infix operators are created using a separate infix() function at 
global scope. Instead, change this so that infix is an annotation on the 
function definition itself:

infix foo : (...) -> (...)

Original issue reported on code.google.com by [email protected] on 15 Jun 2009 at 2:32

Design and implement a non-trivial CUDA example

This task consists of three parts:

 - Determine an effective sample program that exploits CUDA properly
 - Implement the program in Epoch syntax
 - Back-fill any necessary functionality into Fugue to make the example run


This is considered top priority for Release 9/the GDC'10 preview package.

Original issue reported on code.google.com by [email protected] on 13 Feb 2010 at 3:05

Allow function calls in CUDA blocks

Extend the CUDA language extension module to support generation of function 
calls. Make sure to forbid recursion (direct or indirect).

Original issue reported on code.google.com by [email protected] on 21 Feb 2010 at 11:10

Extend bitwise operator support to Integer16s

Currently the bitwise operators are only implemented for Integer data types. 
Expand the functionality to support Integer16s.

Original issue reported on code.google.com by [email protected] on 11 Oct 2009 at 12:07

Infix assignments with structure members are broken

Infix assignments that involve structure members are not parsed correctly 
(error is thrown).

Example: foostruct.bar = baz.quux

It is not clear if this is a problem in the lvalue parse, the rvalue parse, 
or both.

Original issue reported on code.google.com by [email protected] on 15 Jun 2009 at 4:24

• Blocking: #2

Recursive structures are not handled properly

Defining two mutually recursive structures causes chaos. Check for recursion 
when setting up structure definitions and throw a nice compiler error.

Original issue reported on code.google.com by [email protected] on 17 Feb 2010 at 4:47

Passing empty arrays to CUDA causes crash

Invoke a CUDA function which takes an array as a parameter; if the array is 
empty (element count is 0) the marshaling code will crash.

Original issue reported on code.google.com by [email protected] on 28 Feb 2010 at 4:16

Decide on how to handle messages sent to thread pools

Currently threads created in a worker pool do not have an assigned message 
mailbox; while it is legal for a worker thread to message other 
tasks/threads, a worker cannot actually receive any reply. This limits the 
usefulness of pooled threads somewhat.

Determine if it makes sense to message a worker thread at all, and implement 
either safeguards to prevent it, or full support for doing so.

Original issue reported on code.google.com by [email protected] on 8 Feb 2010 at 7:35

Language extension traverser doesn't handle recursion correctly

When traversing code to pass to an external language extension, the traverser 
can get caught in an infinite loop when encountering recursive functions. Add 
safety checks to prevent traversing code multiple times.

Original issue reported on code.google.com by [email protected] on 12 Feb 2010 at 1:59

Pre-packaging for release

The following tasks need to be taken care of prior to packaging the release:

 - Ensure all examples are up to date
 - Ensure all code compiles and runs
 - Ensure all code can be compiled to (WORKING) .exes via Exegen
 - Check install on clean machine
 - Check CUDA failover on clean machine

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 7:47

Implement marshaling of array values to CUDA programs

Add the necessary logic to send arrays to CUDA programs and retrieve the 
resulting values.

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 7:05

Ensure fugue.cfg is available prior to building/running CUDA-enabled projects

The CUDA integration currently requires configuration via the file fugue.cfg. 
If this file is not present, Exegen will crash when attempting to build CUDA-
enabled projects. Ensure that this is clearly documented and provide a 
utility for generating the file.

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 6:26

Triage - comb code for TODOs

Search the existing code base for TODO comments and generate issue reports for 
each one; then select which ones are relevant for fixing in Release 10.

Original issue reported on code.google.com by [email protected] on 19 Sep 2010 at 8:44

Centralize type meta-information

Currently we have a fair number of cases where we specifically check a type 
for certain traits, such as whether or not a type is numeric. This should be 
centralized for easier maintenance when adding or changing type meta-
information.

An example candidate can be found in the opening lines of the function 
ParserState::PostincrementVariable().

Original issue reported on code.google.com by [email protected] on 11 Sep 2009 at 5:38

Prefer anonymous namespaces to static functions/etc.

The code widely uses static linkage for containment of implementation 
details. In most (if not all) cases this could be improved by using anonymous 
namespaces instead. Convert the existing code and adopt a new convention for 
future code.

Original issue reported on code.google.com by [email protected] on 16 Jun 2009 at 4:28

Improve build configurations

Currently the Fugue Visual Studio solution only supports vanilla debug and 
release build modes. Add supplemental modes to allow for optionally building 
without CUDA support, and any other modes that may be worth setting up.

Original issue reported on code.google.com by [email protected] on 17 Jan 2010 at 1:39

Ensure compiler, assembler, and disassembler are all functional

Release 8 includes major additions to the language; many of these are 
currently not supported by the assembler/disassembler or (by extension) the 
.EXE compiler. Update the assembly table and any other necessary code to 
support these new features.

Original issue reported on code.google.com by [email protected] on 24 Jan 2010 at 12:38

CUDA integration is not thread-safe

Invoking CUDA code from multiple threads can cause errors during the data 
marshaling phase, as well as during the module loading and initialization 
phase. All CUDA invocation logic needs to be inspected for thread safety 
issues and repaired accordingly.

Original issue reported on code.google.com by [email protected] on 29 Nov 2009 at 10:51

Ensure projects work correctly

Test the project support in Exegen to make sure it still works.

Original issue reported on code.google.com by [email protected] on 9 Feb 2010 at 12:22

Clean up structure initializer code

Three problems currently exist in the structure initialization code 
(OpGenerator.cpp):

 - Copy constructors are broken
 - Function pointer members are not validated
 - Nested structures are not validated

Original issue reported on code.google.com by [email protected] on 9 Feb 2010 at 7:30

Triage - select remaining unit tests to pass for Release 10

Release 10 will feature substantially less functionality than prior releases of 
the language, due to the rewrite of the compiler toolchain and the need to get 
the new software into the wild as soon as possible.

As a result there will be many of the example programs and unit tests which do 
not pass against Release 10. A triage pass is necessary to select which tests 
should be targeted for passing in Release 10. Once a set of tests is selected, 
those tests should be entered individually as issues against Release 10, so 
that total progress towards the release can be tracked.

Original issue reported on code.google.com by [email protected] on 18 Sep 2010 at 7:54

EXEGen mangles output paths on batch operations

When using the batch feature of exegen (e.g. /compile c:\foo\*.epoch) the 
output path is mangled and can result in incorrect output results.

For example, specifying "c:\baz" as the output filename truncates the "baz" 
and results in outputting to "c:\". This is because of the way trailing 
slashes are handled by the batch code.

This issue affects ALL commands that support batching.

Original issue reported on code.google.com by [email protected] on 23 Nov 2009 at 8:01

Improve code documentation

The current code is poorly documented and needs a lot of improvement in that 
department.

Original issue reported on code.google.com by [email protected] on 18 Sep 2010 at 7:39

Update documentation/wiki for Release 10

Review the site content, especially the wiki pages, for accuracy, up-to-date 
information, and general content coverage for Release 10.

Original issue reported on code.google.com by [email protected] on 19 Sep 2010 at 5:43

Access to variables that rely on handles is not thread-safe

Variables that use handles (i.e. strings, arrays, buffers) are currently not 
thread-safe. Implement safety to prevent handle data from getting mangled.

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 4:18

Expand supported types for language extensions

Currently language extensions can only marshal data of integer32, float32, or 
string types. Implement additional type support so that language extensions 
can use the full range of Epoch's built-in types. This includes developing a 
marshaling system for handling structure/tuple types.

Original issue reported on code.google.com by [email protected] on 29 Nov 2009 at 11:03

Language control flow extensions can only instantiate one counter variable

Language extensions such as "cudafor" can only create one local counter 
variable; this limits the flexibility of control flow extensions. Expand 
support to allow an arbitrary number of local counters.

Original issue reported on code.google.com by [email protected] on 3 Mar 2010 at 3:43

Consider continued inclusion of tuple types

Tuples and structures are increasingly appearing to be redundant. Carefully 
consider the role of tuples and, if necessary, remove support in order to 
minimize duplication of functionality.

Original issue reported on code.google.com by [email protected] on 6 Dec 2009 at 5:13

Improve exception handling

Currently almost all exceptions are totally fatal, especially in the parser; 
revise the exception handling so that errors are recoverable as often as 
possible.

Original issue reported on code.google.com by [email protected] on 19 Sep 2010 at 10:27

Structures cannot be returned from functions

At the moment the grammar misses a case where a user-defined function 
returns a structure. Specifically, the grammar does not permit 
initialization of the structure members.

The following code should reproduce this issue:


structure Vector : (real(X), real(Y), real(Z))

infix(plus)

plus : (Vector(left), Vector(right)) -> (Vector(result, 0.0, 0.0, 0.0))
{
    result.X = left.X + right.X
    result.Y = left.Y + right.Y
    result.Z = left.Z + right.Z
}


entrypoint : () -> ()
{
    Vector(a, 1.0, 1.0, 1.0)
    Vector(b, 2.0, 2.0, 2.0)

    Vector(c, a plus b)
    display(c)
}


display : (Vector(v)) -> ()
{
    debugwritestring(cast(string, v.X))
    debugwritestring(cast(string, v.Y))
    debugwritestring(cast(string, v.Z))
}

Original issue reported on code.google.com by [email protected] on 15 Jun 2009 at 4:15

• Blocked on: #3, #15

Update all examples

Check all example programs to ensure they use the latest features (syntax, 
etc.) and are adequate demonstrations of their respective Epoch features.

Original issue reported on code.google.com by [email protected] on 9 Feb 2010 at 5:49

Ensure that compiled .EXEs support CUDA properly

Provide a mechanism to embed compiled CUDA code into binaries, so that CUDA-
enabled programs can be distributed without requiring the CUDA compiler on 
the end-user's machine.

Original issue reported on code.google.com by [email protected] on 20 Feb 2010 at 6:30

Add support for thread pools

Currently, tasks and futures both involve splitting an OS thread for parallel 
execution. Although this is acceptable for the vast majority of situations, 
it is suboptimal when tasks/futures are short-lived. The overhead of forking 
a thread is substantial and will likely cause performance issues in heavily 
parallel code. Therefore, we should implement support for thread pools that 
wait for a task/future to fork, and execute them within the context of an 
existing thread rather than spinning off a new one. Of course it is 
imperative that the user have complete control over the pool size as well as 
which tasks/futures are forked into new threads and which are delegated to a 
pooled worker thread. Syntax for this is to be decided.

Original issue reported on code.google.com by [email protected] on 29 Nov 2009 at 5:00

Add option to build .EXE directly from single .epoch source file

Currently the Epoch toolchain only supports building .EXE files from a 
project. Build in a default project template that allows the toolchain to 
immediately build a running .EXE file given only a single valid .epoch source 
file.

Original issue reported on code.google.com by [email protected] on 24 Jan 2010 at 12:36

Array lengths cannot be retrieved in all CUDA functions

If a CUDA code block invokes an external function, that function's GPU 
compiled version has no access to the __foo_array_sizes metadata (which is 
only passed to the main kernel and not propagated to child calls).

Find a way to pass this data efficiently to function calls, perhaps with 
"global" device-side variables, or by simply passing pointers to the 
appropriate metadata to child function calls.

Original issue reported on code.google.com by [email protected] on 4 Mar 2010 at 2:10

Code review prior to release

Perform a complete code review of the current codebase, looking for 
formatting/documentation, general cleanup opportunities, and appropriate code 
improvements.

Original issue reported on code.google.com by [email protected] on 29 Nov 2009 at 11:05