[M3devel] many matters big and small esp. wrt C backend

[Hendrik Boom]

On Sat, Apr 13, 2013 at 02:44:40AM +0000, Jay K wrote:
>  
>  Very old compilers don't support passing structs by value?  

THose would be very okd indeed.  I know it wasn't available in the early 
70's.  But I don't think anyone is running Unix on a PDP-11 any more.
I don't remember any more recent C compilers that don't pass strutures 
by value.  Does anyone else?

>  
>  Third question that has been bugging me.
>  The C backend can output #line directives.
>  So you step through the Modula-3 source. What people expect.
>  This was working, and probably still does.
>    I turned it off subject to a constant in the backend. 
>  Currently I output "//line" instead of "#line". (subject to the constant, and yes, I know // isn't portable C) 
> 
>  This is great for, during backend development/debugging, the C compiler gives me C line numbers.
>  If the backend worked perfectly, this would be pointless.
>  I debug stuff *a lot* (beyond Modula-3) and I am sensitive to anything that inhibits debugging in any way.
>  There are bugs everywhere (I have seen them!) and everything needs to be debugged, both with logs and live. 
>  
>  
>  What to do to cater to both/everyone? 
>  I wish I could have multiple #line directives: 
>   #line 123 foo.m3.c 456 foo.m3 
>  
> 
>  but that doesn't exit. 
>  I could encode information in the file name:
>   #line 123 "foo.m3.c/456 foo.m3" 
> 
>  
>  but that is imperfect; error messages will be good, but debugging won't work
>  
> 
>  I could leave it as an #ifdef in the code. 
>  I do not believe the following works: 
>   #ifndef CLINE  
>   #define LINE(cline, cfile, m3line, m3file) cline cfile 
>   #else 
>   #define LINE(cline, cfile, m3line, m3file) m3line m3file 
>   #endif 
>   #line LINE(123, "foo.c", 456, "foo.m3") 
>  
> 
>  but I'll try it. 
>  
> 
>  I think the "best" ends up being to sprinkle in a steady stream of #ifdefs: 
>   #ifndef CLINE  
>   #line 456 "foo.m3" (* might need to adjust by 1 to account for #endif *)   
>   #endif  
> 
>   This is bloated, but might be best.  
>  
> 
>   if "#define LINE" works, great, but I doubt it will. 

If it works, it's likely to fail on C compilers that are a lot younger 
than PDP-11 Unix.

But it's a lovely idea.

>  
> 
>  --- typeindex besides typeid? --- 
>  
> 
> I'm now doing a lot of lookups of typeids.
> It'd be super nice if the frontend also maintained "small" incrementing
> typeIndices that I could use to index into an array.
>  
> 
>  set_type_count(typeCount:CARDINAL); (* maybe *) 
>  declare_object/pointer/indirect/record/etc.(typeId: TypeUID; typeIndex: CARDINAL; ...); 

That would need the front end to know how many types there would be 
before it can generate the typeCount.  But if the typeCount were 
to be considered an estimate, or not available at all, the back end 
could reaallocate the typeindex-indexed array when necessary (or use 
some array-of-arrays data structure for growing arrays, to reduce 
copying on reallocation).  You'd get almost the same performance, and 
obviate placinng a constraint on all future front-ends.

(Yes, I'm still dreaming of a GPL2-compatible front end someday).

>  
> 
>  and thereafter, use typeIndex instead of typeId, an index into an array. 
>