dcputeam / dcputoolchain Goto Github PK

The debugger needs to be able to disassemble assembly and display it when requested.

Example code:

int f(char * a) {
    return a;
}

int main() {
    char * a = 0;

    // ooops, the second parameter is not expected
    f(a, 0xa);

    return 0;
}

Result: Compiles, assembles and links fine, sometimes the emulator crashes with an error "Invalid non-basic opcode 2."
Expected result: Should not compile

Hey guys,

I'm going to be pushing an OS X fix for the emulator because it was actually built wrong by default because of a weird bug, but before then, this issue needs to be addressed I supposed.

Basically what happens is when you run the emulator on OS X (perhaps on Linux as well, haven't had the chance to check) it will segfault and the stack trace looks like this:

0   emulator                        0x00000001051bd84a bstrcpy + 26
1   emulator                        0x00000001051d1619 vm_lem1802_init + 89
2   emulator                        0x00000001051bc26a SDL_main + 1130 (main.c:114)

Don't worry about the SDL_main, that's specific for OS X, the important parts are vm_lem1802_init and then bstrcpy
If I run the emulator through gdb, I get this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000632c64
0x000000010000584a in bstrcpy (b=0x632c60) at bstrlib.c:411
411     if (b == NULL || b->slen < 0 || b->data == NULL) return NULL;

The bstrcpy call is made from vm_lem1802_init with this line imagePath = bstrcpy(path);
If you take a look at the memory for path while debugging, you'll see this:

(gdb) display path
1: path = (bstring) 0x554c30
(gdb) display *path
Disabling display 2 to avoid infinite recursion.
2: *path = Cannot access memory at address 0x554c30

So, path is defined on the emulator's main file, with the line path = (bstring) osutil_dirname(bfromcstr(argv[0]));
After stepping through, the return gets lost when getting passed back.

Now, I can easily just remove this line to this external function and just call dirname from main and it will run just fine, but I know you want to provide a solution that will work for everyone. So, do any of you know how you want to go about fixing this problem?

One other thing I noticed, the line dirname(cpath); in osutil, cpath doesn't even store the new dirname, so this function isn't even doing what it's supposed to.

Anyways, hopefully there's enough information in here for you guys to figure out what you want to do.

I followed the guide verbatim for building on Windows from README.md (non-Cygwin).

I get the following errors when attempting to compile in Visual Studio 10:

error C1083: Cannot open include file 'unistd.h': No such file or directory (File: lexer.cpp L26 Project: compiler)
error LNK2001: unresolved external symbol _yylineno (File: parser.obj Project: assembler)

The emulator and linker projects build with no errors and produce executables. I am building in Debug configuration for Win32. I am using the full edition of Visual Studio 10 (obtained via DreamSpark)

Perhaps there's a missing step in the guide for an additional dependency? Help would be appreciated, as the prebuilt windows binaries can't keep up with the rate of update.

The implementation of inline assembly would enhance the possibilities in a great way. Short code sequences can be written in optimized assembler code.

I propose to introduce an __asm statement as follows:

void main() {
__asm {
SET A, 0x39 
SET [0x8000], A
}
}

This bug report was migrated from the old Redmine system.

The argtable2 data is currently showing up in valgrind as leaked memory. We need to update all of the executables so that when they exit, they free the argtable2 data first (or better yet, free the argtable2 data as soon as we are finished with it, and put all of the results from the argtable2 options into stack variables local to main).

i'm getting the follow output during the build:

...
[ 65%] Building CXX object src/CMakeFiles/tcod.dir/zip.cpp.o
/Users/booyaa/libtcod/src/sys_opengl_c.c: In function ‘loadShader’:
/Users/booyaa/libtcod/src/sys_opengl_c.c:296: warning: initialization makes integer from pointer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:297: warning: passing argument 1 of ‘glShaderSourceARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:298: warning: passing argument 1 of ‘glCompileShaderARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:300: warning: passing argument 1 of ‘glGetObjectParameterivARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:304: warning: passing argument 1 of ‘glGetObjectParameterivARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:308: warning: passing argument 1 of ‘glGetInfoLogARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c: In function ‘loadProgram’:
/Users/booyaa/libtcod/src/sys_opengl_c.c:322: warning: assignment makes integer from pointer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:326: warning: passing argument 1 of ‘glAttachObjectARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:326: warning: passing argument 2 of ‘glAttachObjectARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:330: warning: passing argument 1 of ‘glAttachObjectARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:330: warning: passing argument 2 of ‘glAttachObjectARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:332: warning: passing argument 1 of ‘glLinkProgramARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:334: warning: passing argument 1 of ‘glGetObjectParameterivARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:341: warning: passing argument 1 of ‘glGetObjectParameterivARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:345: warning: passing argument 1 of ‘glGetInfoLogARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c: In function ‘TCOD_opengl_render’:
/Users/booyaa/libtcod/src/sys_opengl_c.c:556: warning: passing argument 1 of ‘glUseProgramObjectARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:561: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:562: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:563: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:564: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:569: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:573: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:577: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_opengl_c.c:581: warning: passing argument 1 of ‘glGetUniformLocationARB’ makes pointer from integer without a cast
/Users/booyaa/libtcod/src/sys_sdl_img_png.c:39:1: warning: "int_p_NULL" redefined
In file included from /Users/booyaa/libtcod/src/sys_sdl_img_png.c:33:
/usr/X11R6/include/png.h:547:1: warning: this is the location of the previous definition
/Users/booyaa/libtcod/src/zip_c.c: In function ‘TCOD_zip_put_int’:
/Users/booyaa/libtcod/src/zip_c.c:87: warning: cast to pointer from integer of different size
/Users/booyaa/libtcod/src/zip_c.c: In function ‘TCOD_zip_get_int’:
/Users/booyaa/libtcod/src/zip_c.c:244: warning: cast from pointer to integer of different size
Undefined symbols:
  "_SDL_WaitEvent", referenced from:
      _TCOD_sys_wait_for_event in sys_sdl_c.c.o
  "_SDL_SaveBMP_RW", referenced from:
      _TCOD_sys_write_bmp in sys_sdl_img_bmp.c.o
  "_SDL_LockSurface", referenced from:
      _TCOD_opengl_init_state in sys_opengl_c.c.o
  "_SDL_FillRect", referenced from:
      _TCOD_sys_console_to_bitmap in sys_sdl_c.c.o
      _TCOD_sys_init in sys_sdl_c.c.o
      _TCOD_sys_create_bitmap in sys_sdl_c.c.o
  "_PasteboardPutItemFlavor", referenced from:
      _TCOD_sys_clipboard_set in sys_c.c.o

Confirm that the toolchain assembler is suitable for 0x42c-mt and if needed, make any code changes to the 0x42c-mt code base to get it to execute.

This issue is a prerequisite to supporting linking against the kernel in the linker.

This is an issue with local variables. I haven't checked if only main() is affected.

Expected behavior: print "9" in line 0 and another "9" in line 2
Observed behavior: print "9" in line 0 and "0" in line 2

Test case:

void putc(char chr, int x, int y) {
int mem = 0x8000 + x + y * 32;
*mem = chr + 0xf000;
}

int getNine() {
return(9);
}

void main() {
int n; // absolutely not needed but remove it and the emulator will crash with "Invalid non-basic opcode 0." 
int a;

a = getNine();
    putc(0x30+a,0,0);    // a=9
    putc(0x30+a,0,2);    // a=0  => BUG!
}

This bug report was migrated from the old Redmine system.

It reduces a very bad step in installation which makes this more user friendly

The emulator crashes with "Invalid non-basic opcode 0."

This is the test-case:

int getNine() {
return(9);
}

void main() {
int n; // absolutely not needed but remove it and the emulator will crash with "Invalid non-basic opcode 0." 
int a;
a = getNine();
}

This bug report was migrated from the old Redmine system.

Looks like this could potentially be broken according to comments on http://www.reddit.com/r/dcpu16/comments/t9gqx/dcpu16_toolchain_binary_release_on_12th_may/.

We can have a decent printf then.

The debugger needs a help command to display a list of commands as well as information about what each command does and the arguments it accepts.

It seems that there is a problem with the current version 04174ff and cmake. When i try to compile the toolchain i get this error:

[ 27%] Building C object libdcpu-ci-lang-c/CMakeFiles/libdcpu-ci-lang-c.dir/parser.c.o parser.y:17:1: error: unknown type name 'class' parser.y:18:1: error: unknown type name 'class' parser.y:20:18: fatal error: cstdio: No such file or directory compilation terminated.

Apparently because a C compiler is used for C++ code. After enforcing CXX in CMakeLists.txt (and deleting all generated parser files in libdcpu-ci-lang-c) this compiles well, but it stops now during the asm parser compilation:

parser.cpp:1419:16: error: 'yylex' was not declared in this scope parser.y:91:56: error: invalid conversion from 'void*' to 'ast_node_lines*' [-fpermissive] parser.y:125:83: error: invalid conversion from 'void*' to 'ast_node_instruction*' [-fpermissive] parser.y:126:69: error: invalid conversion from 'void*' to 'ast_node_line*' [-fpermissive] parser.y:127:69: error: invalid conversion from 'void*' to 'ast_node_label*' [-fpermissive] [... many more errors like that and some warnings ...]

I'd like to be able to install the toolchain somewhere in my PATH but with names like compiler, linker, etc. this doesn't seem like such a great idea. I think the executables should be built by default with the names prefixed with dcpu16, d16 or similar.

I suggest the following names, roughly based on the loose conventions used by GCC and other Unix toolchains, as possible examples:

• assembler → d16asm
• compiler → d16cc
• ddb → d16db
• emulator → d16emu
• linker → d16ld
• preprocessor → d16pp

A common prefix would also be handy for those of us who use shells that support tab completion: I could type d16, press tab and immediately have a list of all the DCPU Toolchain commands.

void strcpy(char* src, char* dest) {
    char p;
    int i;
    for(i=0;p = *(src+i);i++) {
        *(dest + i) = p;
    }
}

This code fails with: error at line 16: syntax error, unexpected INCREMENT
(line 16 is the for loop line)

Replacing i++ with i += 1 causes it to compile with no issues.

The following does not assemble due to the

set a, [data+i]

Not sure if this is a bug in our code or if this is just not standard dasm.
If this is not wanted just close the issue :)

; Assembler test for DCPU
; by Markus Persson

:start
    set i, 0
    set j, 0
    set b, 0xf100

:nextchar
    set a, [data+i]
    ife a, 0
        set PC, end
    ifg a, 0xff
        set PC, setcolor
    bor a, b
    set [0x8000+j], a
    add i, 1
    add j, 1
    set PC, nextchar

:setcolor
    set b, a
    and b, 0xff
    shl b, 8
    ifg a, 0x1ff
        add b, 0x80
    add i, 1
    set PC, nextchar

:end
    set PC, end

:data
    dat 0x170, "Hello ", 0x2e1, "world", 0x170, ", how are you?"

I'm seeing some issues with libraries not being correctly referenced in the CMake build; it can't find libtcod, argtable2, etc. I assume this is because on Linux those things are global, whereas on Windows we need to use the libraries in the third-party folder.

Could you look into setting it up so that on Windows it will use the third-party folder for builds?

The compiler and assembler optimization infrastructure needs to be implemented (using Lua as the scripting language).

The readline and pthread libraries for Windows need to be included in the repo.

The linker needs to accept multiple files in an object format and produce a complete application or static library (depending on the compile options).

Currently if you output data from the assembler in intermediate mode and then attempt to run it through the emulator without linking first, you get the cryptic message "Invalid non-basic opcode 3."

Instead, the emulator should detect that the image contains an object table at the start and exit with an error indicating that the image still needs to be linked.

bootstrap.asm is required in order for the compiler to successfully produce correct assembly, thus it should be copied across to the Debug directory automatically via CMake.

The following code needs to run perfectly on the emulator.

set pc, main
:message .dat "QWERTYUIOPASDFGHJKLZXCVBNMMqwertyuiopasdfghjklzxcvbnm1234567890!?", 0
:font
dat 0xB79E, 0x388E, 0x722C, 0x75F4, 0x19BB, 0x7F8F, 0x85F9, 0xB158
dat 0x242E, 0x2400, 0x082A, 0x0800, 0x0008, 0x0000, 0x0808, 0x0808
dat 0x00FF, 0x0000, 0x00F8, 0x0808, 0x08F8, 0x0000, 0x080F, 0x0000
dat 0x000F, 0x0808, 0x00FF, 0x0808, 0x08F8, 0x0808, 0x08FF, 0x0000
dat 0x080F, 0x0808, 0x08FF, 0x0808, 0x6633, 0x99CC, 0x9933, 0x66CC
dat 0xFEF8, 0xE080, 0x7F1F, 0x0701, 0x0107, 0x1F7F, 0x80E0, 0xF8FE
dat 0x5500, 0xAA00, 0x55AA, 0x55AA, 0xFFAA, 0xFF55, 0x0F0F, 0x0F0F
dat 0xF0F0, 0xF0F0, 0x0000, 0xFFFF, 0xFFFF, 0x0000, 0xFFFF, 0xFFFF
dat 0x0000, 0x0000, 0x005F, 0x0000, 0x0300, 0x0300, 0x3E14, 0x3E00
dat 0x266B, 0x3200, 0x611C, 0x4300, 0x3629, 0x7650, 0x0002, 0x0100
dat 0x1C22, 0x4100, 0x4122, 0x1C00, 0x1408, 0x1400, 0x081C, 0x0800
dat 0x4020, 0x0000, 0x0808, 0x0800, 0x0040, 0x0000, 0x601C, 0x0300
dat 0x3E49, 0x3E00, 0x427F, 0x4000, 0x6259, 0x4600, 0x2249, 0x3600
dat 0x0F08, 0x7F00, 0x2745, 0x3900, 0x3E49, 0x3200, 0x6119, 0x0700
dat 0x3649, 0x3600, 0x2649, 0x3E00, 0x0024, 0x0000, 0x4024, 0x0000
dat 0x0814, 0x2200, 0x1414, 0x1400, 0x2214, 0x0800, 0x0259, 0x0600
dat 0x3E59, 0x5E00, 0x7E09, 0x7E00, 0x7F49, 0x3600, 0x3E41, 0x2200
dat 0x7F41, 0x3E00, 0x7F49, 0x4100, 0x7F09, 0x0100, 0x3E41, 0x7A00
dat 0x7F08, 0x7F00, 0x417F, 0x4100, 0x2040, 0x3F00, 0x7F08, 0x7700
dat 0x7F40, 0x4000, 0x7F06, 0x7F00, 0x7F01, 0x7E00, 0x3E41, 0x3E00
dat 0x7F09, 0x0600, 0x3E61, 0x7E00, 0x7F09, 0x7600, 0x2649, 0x3200
dat 0x017F, 0x0100, 0x3F40, 0x7F00, 0x1F60, 0x1F00, 0x7F30, 0x7F00
dat 0x7708, 0x7700, 0x0778, 0x0700, 0x7149, 0x4700, 0x007F, 0x4100
dat 0x031C, 0x6000, 0x417F, 0x0000, 0x0201, 0x0200, 0x8080, 0x8000
dat 0x0001, 0x0200, 0x2454, 0x7800, 0x7F44, 0x3800, 0x3844, 0x2800
dat 0x3844, 0x7F00, 0x3854, 0x5800, 0x087E, 0x0900, 0x4854, 0x3C00
dat 0x7F04, 0x7800, 0x047D, 0x0000, 0x2040, 0x3D00, 0x7F10, 0x6C00
dat 0x017F, 0x0000, 0x7C18, 0x7C00, 0x7C04, 0x7800, 0x3844, 0x3800
dat 0x7C14, 0x0800, 0x0814, 0x7C00, 0x7C04, 0x0800, 0x4854, 0x2400
dat 0x043E, 0x4400, 0x3C40, 0x7C00, 0x1C60, 0x1C00, 0x7C30, 0x7C00
dat 0x6C10, 0x6C00, 0x4C50, 0x3C00, 0x6454, 0x4C00, 0x0836, 0x4100
dat 0x0077, 0x0000, 0x4136, 0x0800, 0x0201, 0x0201, 0x0205, 0x0200
:scroff .dat 0x0

:main
    set a, 0x0
    set b, 0x8000
    hwi 0

    set a, 0x1
    set b, font
    hwi 0

    set a, message
    jsr printstr

:end set pc, end

:printstr
    ife [a], 0
        set pc, pop
    jsr putc
    add a, 1
    set pc, printstr

:putc
    set push, a
    set a, [a]
    bor a, 0xf000
    set b, 0x8000
    add b, [scroff]
    set [b], a

    add [scroff], 1
    ife [scroff], 0x17f
        set [scroff], 0x0

    set a, pop
    set pc, pop

I've added most of the code that does this, but I don't know how TCOD works and someone needs to update it. Hachque, I choose you!

Also, color palettes.

Readline isn't available everywhere. The debugger command input needs to use Flex / Bison instead.

Each executable needs to load up with information about what the executable is, the project, the (summary of the) license and the current version that is running.

Assembler directives MVI, ADX, SUX need to be renamed to their new versions.

Implement signed integer support in the compiler.

I have Flex 2.5.35.

simplyianm@ian-desktop-9000:~/dcputoolchain/build$ make
[ 16%] Built target argtable2
[ 16%] Built target libdcpu
[ 16%] Built target libdcpu-vm
[ 16%] Generating /home/simplyianm/dcputoolchain/src/libdcpu-pp/lexer.c
flex: can't open lexer.l
make[2]: *** [/home/simplyianm/dcputoolchain/src/libdcpu-pp/lexer.c] Error 1
make[1]: *** [libdcpu-pp/CMakeFiles/libdcpu-pp.dir/all] Error 2
make: *** [all] Error 2

The compile should support declaring functions without specifying their body.

only the emulator needs libtcod, right? if that's the case and there was an option to omit the compilation of the emulator (maybe even automatically if libtcod is not found) this would make the compilation of the rest easier and more people could use the toolchain.

Implement support for arrays and array operations in the C compiler.

Add support for the .JUMP directive in the assembler.

When used in user code, this implicitly includes the kernel's jump list and exposes each jump list entry automatically as a label.

When used in kernel code, it accepts a single label as it's parameter and defines this to be exported in a jump list. When in kernel code, the .JUMP directive can be used multiple times (whereas in user code calling .JUMP multiple times in the same file has no effect on second and future calls).

James, I got another one for you even though you moved your bugtracker... ;-)

When trying to assign a negative number to a variable, it results in a compiler error.

expected behavior: assign 0xffff to variable
observed behavior: Compiler error "syntax error, unexpected SUBTRACT"

Test case:

void main()
{
    int a;
    a = -1;     // 'a' should be 0xffff but results in compiler error
//  a = 0-1;        // this one works
}

Set up nightly build server.

When compiling on OS X I get the following compilation error:

[ 21%] Building CXX object compiler/CMakeFiles/compiler.dir/parser.cpp.o
In file included from parser.y:20:
/usr/include/c++/4.2.1/bits/stl_pair.h: In instantiation of ‘std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, NType&>’:
/Users/lucas/_dev/DCPUToolchain/compiler/asmgen.h:84:   instantiated from here
/usr/include/c++/4.2.1/bits/stl_pair.h:84: error: forming reference to reference type ‘NType&’
/Users/lucas/_dev/DCPUToolchain/compiler/asmgen.h: In constructor ‘StackFrame::StackPair::StackPair(std::string, NType&)’:
/Users/lucas/_dev/DCPUToolchain/compiler/asmgen.h:86: error: no matching function for call to ‘std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, NType&>::pair(std::string&, NType&)’
/usr/include/c++/4.2.1/bits/stl_pair.h:80: note: candidates are: std::pair<_T1, _T2>::pair() [with _T1 = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, _T2 = NType&]
/usr/include/c++/4.2.1/bits/stl_pair.h:69: note:                 std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, NType&>::pair(const std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, NType&>&)
make[2]: *** [compiler/CMakeFiles/compiler.dir/parser.cpp.o] Error 1
make[1]: *** [compiler/CMakeFiles/compiler.dir/all] Error 2
make: *** [all] Error 2

Apparently the problem lies within asmgen.h, namely the StackPair class, but I only know the very basics of C++, so I can't really tell whats going on...

We need an expression engine implemented in the preprocessor.

The preprocessor does not accept #include on the first line because it requires a newline before the #. This needs to be changed so that the preprocessor can accept if the # is the first character in the file.

There are locations which still use an #ifdef'd dirname for Windows compatibility. These areas should use the osutil functions of libdcpu instead.

Sorry to open another issue, but the last one was closed and I was not able to reopen it.

By moving my GnuWin32 installation to C:\UNIX\GnuWin32 and updating the PATH, I was able to resolve compiler error, however the linker error for the assembler project persists:

error LNK2001: unresolved external symbol _yylineno (File: parser.obj Project: assembler)

Once again, Visual Studio 10 on Windows 7 x64, targeting Debug Win32.

The debugger should be able to update and swap assembly and C code on-the-fly.

After implementing support in the assembler and compiler, support needs to be added to the debugger.

The debugger should search automatically for the file based on the filename being loaded, warning the user if no symbols are loaded (in which case only 'add breakpoint memory:...' will work).

When the user wants to set breakpoints, view backtraces, etc. the debugger needs to use the symbol table to resolve memory locations automatically.

I would guess this will come into play when debug information is produced (yylinenum or similar being passed through to your code model node classes)?

The preprocessor system needs to parse files and output line number information when the line number significantly changes. Thus internally what the C compiler or assembler receives is something akin to:

#1 test.dasm16
ADD A, 5
#1 include.dasm16
SUB B, 6
#2 test.dasm16
ADD B, 8
SET C, 4

The compiler and assembler lexers need to take this information as use it to produce debugging symbols. In the case of C compiler, when it sees # it should output .LINE , passing that to the assembler.

When the preprocessor sees a .LINE symbol, it should then directly output it in the form of # 1 test.dasm16, passing it to the underlying assembler or C compiler (because you can use #line in C as well).

When the assembler compiles a file, it needs to produce a seperate debugging database. If the output filename was test.dcpu16, it would automatically choose the filename test.dsym16, unless otherwise overridden with the -s (--symbol-output) option.

example code

int mod(int a, int b) {
    return a % b;
}

int div(int a, int b) {
    return a / b;
}

int main() {
    int a;
    int b;

    a = 5 / 3;
    b = 5 % 3;

    a = div(5, 3);
    b = mod(5, 3);

    return 0;
}

The div and mod inside main work fine, the first div function call seems to get 5 as both parameters and before the mod function can be called, the PC is messed up in the debugger and gets completely lost.

I've been working trying to get this thing building for Mac again with the latest changes, I'll be sending a pull request once I fix this issue.

Basically, when running the emulator I see a black screen, nothing comes up. Running debug mode does show that instructions are going by and things look all well, it looks like this.

So, what I'm seeing is that in order for the text to be drawn that location_screen needs to be something that isn't 0, and it seems like that's not the case.

I search through the project to see where that it's called, see that it's in vm_hw_lem1802_mem_set_screen which is one called directly through legacy mode which looks a bit like this so that's closer to what I want, but the characters are completely off. This is the default test.c compiled from the compiler/dist folder with the repo by the way.

It's also called in vm_hw_lem1802_interrupt when you request for LEM1802_MEM_MAP_SCREEN
So, I tried to see if vm_hw_lem1802_mem_set_screen was ever called, and it looks like that's not the case.

It is my understanding that the DCPU is supposed to send an interrupt to the LEM1802 and passing in the space in memory the DCPU has the screen located, but it looks like that isn't happening, is this supposed to be working?

When compiling on Ubuntu 12.04 i get this error:

lexer.l:29:21: error: ‘INITIAL’ was not declared in this scope

I guess its definition is missing in parser.hpp.