[M3devel] typenames vs. typeids in M3CG?

[Jay K]

Given something like: 
  TYPE A = RECORD ... END; (* typeid 123456 *)   
  TYPE B = A;  
    
   
  VAR a:A;  
  VAR b:B;   
 
  ideally the generated code looks like:     
    struct T123456; typedef struct T123456 T123456;  
    struct T123456 { ... };  
   
   
    typedef T123456 A;      
    typedef T123456 B;     
    A a;      
    B b;      
    Currently I produce:  
      T123456 a;   
      T123456 b;     
   it is easy to make the first or better yet last typename for any given typeid win, giving us:   
     B a;   
     B b;   
  However actually producing the ideal/idiomatic:      A a;    
    B b;    
 I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. 
 Reasonable?   
  The problem seems worst for records.  
  But it applies to enums, subranges, opaque types. 
    
  Actual source is full of typenames. M3CG is full of typeids.  
  
  
  TYPE Color = {Red, Blue, Green};  
 
 
  The thing to the right is anonymous type with a typeid (structural hash).  
  
   
 TYPE Color2 = {Red, Blue, Green};   
  
  VAR Color:c;    
  VAR Color2:c2;   
  
  
  In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*:    
  
  typedef enum { Red, Blue, Green } Color, Color2;   /* importat gcc and Visual C++ extensions omitted */ 
  
  Color c;    
  Color2 c2;    
  However, again, without frontend help we are faced with probably: 
   T1234 c;  
   T1234 c2;  
  or perhaps  
    Color c;   
    Color2 c2;       Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. 
 That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to  do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger.  
 Similarly for opaque types, currently I have:  
  typdef char* ADDRESS;  
  TYPE A <: whatever;  
  TYPE B <: whatever;  
  
  
  typedef ADDRESS T1234; (* typeid for opaque type *)   
  typedef ADDRESS T123478; (* typeid for opaque type *)   
  
  
  T1234 a;   
  T123478 b;   
   
    
 This is not particularly readable.   It can go either way:  
    ADDRESS a;
    ADDRESS b; 
  
 Or ideally more like:
    A* a;
    B* b;
  
  
  or 
    A a;  
    B b;    
 Opaque types are a larger problem, at least in my head. 
 I'd like to have pointers to structs, but I don't yet know how to make that work.  Either the public part or the entire thing. If the information is available.      
 The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. 
  (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...)    
 If you have used stock gdb or debugged the NT386 target, you should realize the problem.    
  I believe the frontend should be passing typenames along with typeids for locals/parameters.  
  I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. 
  Advise?   
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/48f717cd/attachment-0001.html>