OpenEuphoria

2. Re: My frustration

• Posted by mattlewis (admin) May 19, 2014
• 1274 views

You could still do this. Of course, if your routine relies on other routines, you'll need those, too.

One challenge in generating code is avoiding naming conflicts. C has different namespace rules than euphoria, so we need to make sure it all works when we translate the symbol names from euphoria to C. We do that by including the symbol's index in the symbol table in its name, so all of your variables are guaranteed unique. Even so, you should be able to simplify that with some search and replace.

Symbols that are all numbers / underscores are temporary variables. _0, _1 and _2 are created and used automatically by the translator. The others are temporary variables from the IL code. Of course, a human could probably optimize them down to fewer distinct variables, but so will a compiler, and it keeps the translator simpler to not worry about those.

You could also get help here on specifics and maybe find someone more comfortable with C to collaborate with. But as the back end of euphoria really is C, the best way is just to write stuff in C to begin with.

Matt

4. Re: My frustration

• Posted by mattlewis (admin) May 19, 2014
• 1217 views

The front end of the interpreter has a feature to instrument your code for the purpose of measuring code coverage for your tests (see coverage.e). These are written as part of the front end, but need to be called by the back end. The back end is started by a machine call from the front end. We pass along the routine id of the routines we need to call as specific parameters in the start_backend machine call. There are a few others. Here is the call from backend.e:

 
	-- M_BACKEND: 
	machine_proc(65,  
		{ 
			st,  
			sl,  
			ms,  
			lit,  
			include_info,  
			get_switches(),  
			Argv, 
			routine_id( "cover_line" ), 
			routine_id( "cover_routine" ), 
			routine_id( "write_coverage_db" ), 
			routine_id( "DisplayColorLine" ), 
			external_debugger_ptr, 
			routine_id( "map:new" ), 
			routine_id( "map:put" ), 
			routine_id( "map:get" ), 
			trace_lines, 
			$ 
		}) 

These routines are handled as translated routine ids, and are separate from the normal routine ids that happen in the users code. The translator keeps a lookup table for these routines, and we use that to call the translated functions. There's no reason why this couldn't be done for other things.

In be_machine.c, start_backend(), we save these values:

	// Front End CallBacks: 
	cover_line        = get_pos_int(w, *(x_ptr->base+8)); 
	cover_routine     = get_pos_int(w, *(x_ptr->base+9)); 
	write_coverage_db = get_pos_int(w, *(x_ptr->base+10)); 
	syncolor          = get_pos_int(w, *(x_ptr->base+11)); 

You can look at be_coverage.c for the wrappers around these callbacks (there are a few others in other parts, too, but they give you an idea of what's going on):

void COVER_LINE(int line) 
{ 
	if (cover_line != -1) 
	{ 
		internal_general_call_back(cover_line, 
		line,0,0, 0,0,0, 0,0,0); 
	} 
} 

Matt