This pull request enables java_grinder to compile under Ubuntu 16.04 using g++ and fixes issues triggered by case insensitive file systems. Specifically this PR:

• Removes the leading _ character in the include header guards since g++ uses leading _ for its system headers.
• Renames Math.h to MathUtils.h
• Renames amiga.* to amiga_.* to avoid conflicts with Amiga.*
• Adds entries to .gitignore to avoid checking in generated binaries
• Fixes an issue that prevented functions from getting included in assembly output

Fixes java_grinder include guards to conform to Google standards. See https://stackoverflow.com/questions/4867559/naming-include-guards

Note that it is NOT legal to begin include guards with leading _ or __ because doing so causes issues with system headers. For example, Linux's math.h file looks like:

#ifndef	_MATH_H
#define	_MATH_H	1

Because java_grinder defines Math.h with the identical header guard, it is not currently possible to compile java_grinder under Linux. This change brings java_grinder one step closer to compiling under Linux.

When building with the -UDEBUG -DNDEBUG options set, the build fails with this error:

/usr/local/bin/ld: common/JavaCompiler.o: in function `JavaCompiler::load_class(char const*)':
JavaCompiler.cxx:(.text+0x7484): undefined reference to `JavaClass::print()'

This patch fixes that bug.

I know it does not solve any issue because it seems nakem asm reads correctly the produced asm code but other assemblers dont and it will good for consistency.

This PR fixes an issue compiling java_grinder under Ubuntu 16.04 with g++ 5.4.0 by explicitly specifying to use the C++ 11 standard. The errors that would otherwise pop up typically look like:

../common/JavaCompiler.cxx:510:35: error: 'to_string' is not a member of 'std'
       label = method_name + "_" + std::to_string(jump_to);

More information can be found here.

This PR fixes the final compilation issue with Ubuntu 16.04 and g++ 5.4.0.

Hi,

trying to grind a Test2CPC.zip

** String name = ""; **

I get "Opcode (187) 'new' unimplemented"

Trying ** String name = NULL; **

it states

"Opcode (1) 'aconst_null' unimplemented"

Hi Mike,

As I announced on previous e-mail, this is my first contribution to add MSX support to java_grinder.

I did my work on top of Giovanni's.

As I mentioned with these changes java_grinder and naken-asm are successfully creating a .ROM (binary) file that actually runs on MSX.

Please consider this request.

I have some questions that I'll address in another e-mail.

Thanks and best regards,

Emiliano

Mike,

I fixed some issues on Z80.cxx:

- there's no ld (hl), bc
- there's no ld b, (hl+1), you should inc hl first
- there's no ld d, (hl+1), you should inc hl first
- jr z label_ --> jr z, label_
- label_x   --> label_z:

Other changes are there because my editor removes trailing white spaces.

Thanks.

This is an issue to track the progress for java_grinder on x86_64

• [x] registers
• [ ] data types/sizes
• [ ] code generation
• [ ] enabling support

Please edit as progress continues, and feel free to add more goals.

I'm led hear because java_grinder for the Parallax Propeller just got a mention on the Parallax forums. For the first time I think: http://forums.parallax.com/discussion/168101/propeller-java. An impressive piece of work.

I don't know if you are aware but there is a way to have a very small, tight, PASM loop execute large PASM code from shared memory. Basically it fetches instructions from shared memory, one at a time, and executes them in COG. This is known in the Propeller world as LMM mode. Large Memory Model.

The C compilers for the Propeller generate LMM code so as to allow for reasonably sized programs. Despite the fetch, execute loop they do run at a usable speed. They can also, optionally, generate COG code of course.

GCC is extra clever optimization in that it has a thing called fcache. It will compile tight C loops into COG code and load that into into cog at run time. With fcache your Mandlebrot demo would probably run as fast in LMM mode as it does all from COG!

Anyway, just thought you like a heads up on the Parallax forum post and wondered if you would be interested in getting java_grinder to generate LMM code.