<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Given something like:<BR> <BR><br> TYPE A = RECORD ... END; (* typeid 123456 *) <br> TYPE B = A; <br> <br> <br> VAR a:A; <br> VAR b:B; <BR> <BR><br> <br> ideally the generated code looks like: <BR> <BR> <br> struct T123456; typedef struct T123456 T123456; <br> struct T123456 { ... }; <br> <br> <br> typedef T123456 A; <br> typedef T123456 B; <br> A a; <br> B b; <br> <BR> Currently I produce: <br> T123456 a; <br> T123456 b; <BR><br> it is easy to make the first or better yet last typename for any given typeid win, giving us: <br> B a; <br> B b; <BR><br> However actually producing the ideal/idiomatic: <BR> A a; <br> B b; <BR><br> I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. <br> Reasonable? <BR> <BR> <br> The problem seems worst for records. <br> But it applies to enums, subranges, opaque types. <br> <br><BR> Actual source is full of typenames. M3CG is full of typeids. <br> <br> <br> TYPE Color = {Red, Blue, Green}; <br> <br> <br> The thing to the right is anonymous type with a typeid (structural hash). <br> <br> <br> TYPE Color2 = {Red, Blue, Green}; <br> <br> VAR Color:c; <br> VAR Color2:c2; <br> <br> <br> In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: <br> <br> typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */ <br><BR> <br> Color c; <br> Color2 c2; <BR> <BR><br> However, again, without frontend help we are faced with probably: <br> T1234 c; <br> T1234 c2; <BR><br> or perhaps <br> Color c; <br> Color2 c2; <BR> <BR> <BR> Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. <br> 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. <BR> <BR><br> Similarly for opaque types, currently I have: <BR> <BR><br> typdef char* ADDRESS; <br> TYPE A <: whatever; <br> TYPE B <: whatever; <br> <br> <br> typedef ADDRESS T1234; (* typeid for opaque type *) <br> typedef ADDRESS T123478; (* typeid for opaque type *) <br> <br> <br> T1234 a; <br> T123478 b; <br> <br> <br> This is not particularly readable. <BR> It can go either way: <br> ADDRESS a;<br> ADDRESS b; <br> <BR><br> Or ideally more like:<br> A* a;<br> B* b;<br> <br> <br> or <br> A a; <br> B b; <BR> <BR> <br> Opaque types are a larger problem, at least in my head. <br> I'd like to have pointers to structs, but I don't yet know how to make that work. <BR> Either the public part or the entire thing. If the information is available. <BR> <BR> <br> The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. <br> (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) <BR> <BR> <br> If you have used stock gdb or debugged the NT386 target, you should realize the problem. <BR> <BR> <br> I believe the frontend should be passing typenames along with typeids for locals/parameters. <br> I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. <br> Advise?<BR> <BR> <br> - Jay<br><BR> </div></body>
</html>