[solved] issue with opaque-type, struct tag_name not implemented

[DiTBho]

So I have about 7000 lines of C code where something like the following stuff is massively used.

Code: [Select]

typedef struct my_sc_t   opaque_t;   /* inform the compiler of something to define later*/
typedef opaque_t*        p_opaque_t; /* and whatever it will be, let's prepare its pointer-type */

typedef struct my_sc_t /* this line makes the trick */
{
    p_opaque_t p_next;
} my_t;
typedef my_t* p_my_t;

Everything is elegant and fine with all of my C compilers and the code passes all the QA, it really looks good and nice and makes me feel good, etc, except that when I try to compile on a Japanese SH4 C compiler provided by the customer, the compiler surprisingly stops at this line.

Code: [Select]

typedef struct my_sc_t
on the email - don't worry, it's C89 - he wrote, so I don't seriously know why the compiler has to cry up like a baby complaining that this line is nothing but "syntax error" (really?), with no way, no magic flag to override this crazy behavior, and whatever you do it will still refuses to continue.

Why!?! holy crap, struct tag_name should be *standard feature*. Isn't it?

The general syntax for a struct declaration in C should be

Code: [Select]

struct tag_name
{
...
and such a struct declaration may also appear in the context of a typedef declaration, where ok, "tag_name" is *optional* in some contexts - so the manual says - but does it mean not implemented at all?

Code: [Select]

typedef struct tag_name /* this is optional, in my case the CC-parser doesn't understand it at all */
{

I am lost here, and as workaround I am doing the dirtiest thing ever

Code: [Select]

typedef void*        p_opaque_t; /* horrible dirty, please don't look at this line */
typedef struct
{
    p_opaque_t p_next;
} my_t;
plus some wild casting here and there along the lines of the source code.

I prepared a patch with this but I seriously feel embarrassed.

I mean, now by applying the patch the code is still back compiling and working, but I am looking at my shoes ... because ... I don't really know a better way to fix this, and I have the feeling that no matter how much effort you invest to polish your shoes, once again "a wild dirty hack is saving your day".


edit:
solved, missing feature updated to the C-compiler

[SiliconWizard]

The compiler seems a bit nasty, but why don't you just write:

Code: [Select]

typedef struct my_sc_t   opaque_t;   /* inform the compiler of something to define later*/
typedef opaque_t*        p_opaque_t; /* and whatever it will be, let's prepare its pointer-type */

struct my_sc_t /* this line makes the trick */
{
    p_opaque_t p_next;
};

typedef struct my_sc_t my_t;
typedef my_t* p_my_t;

Which I guess should pass alright with this compiler?

[magic]

Code like this convinces me that Linus is right about typedefs

I suppose it's all legal C and whatnot, but why?

[TheCalligrapher]

on the email - don't worry, it's C89 - he wrote

There's nothing wrong with that code neither in C89 nor in any other iteration of C standard. On top of that, the code is perfectly valid in C++ as well.

If some compiler complains, there must be something very wrong with the compiler.

---

It is not clear though why it declares multiple names for the same thing. `opaque_t` and `my_t` are the same. `p_opaque_t` and `p_my_t` are the same.

[DiTBho]

The compiler seems a bit nasty, but why don't you just write:

Code: [Select]

struct my_sc_t
{
Which I guess should pass alright with this compiler?

Because this works for the compiler, but not for the ICE which needs to see types

[magic]

Then you've got a problem because the code posted by SiliconWizard is equivalent, so it seems like you are stuck between to shitty tools which misunderstand different aspects of the language

Maybe the solution is to drop this madness of having three different names for the exact same type.

Pro tip 1:
Making your clients use opaque_t doesn't hide the type's implementation from them. They still know it's the same type as struct my_sc_t because your header says so. C permits them to do everything with that type that they can do with the struct itself.

Pro tip 2:
Simply omitting the struct's definition from the header restricts your clients to doing exactly one thing with the struct: storing pointers to it and passing them around. They can't even create their own struct my_sc_t because they don't know the type's size, let alone its layout.

[DiTBho]

Code like this convinces me that Linus is right about typedefs

I like Linus, seriously I love that guy's idea and efforts, but regarding typedefs ... Linus is rather my Yin and Yang.

He has a completely opposite view to my ICE's needs, that also describes how obviously opposite or contrary forces may actually be complementary

Code: [Select]

Linus = - me

Oh, that's why I don't touch the kernel too much

Code: [Select]

Linus + me = 0
(A) + (- A) = 0
the reworked code may vaporize 

(edit: humor, but it's true ... also, I am not qualified to touch the kernel)

[DiTBho]

Then you've got a problem because the code posted by SiliconWizard is equivalent, so it seems like you are stuck between to shitty tools which misunderstand different aspects of the language

Déjà vu 

surprisingly, that's precisely what the Japanese dude wrote me - yes, but - he showed me a piece of code similar to the one posted by SiliconWizard - the code is equivalent, so what's the problem? why do you need a typedef struct with tag_name? - he asked rather perplexed.

Misunderstanding different aspects of the language && misunderstanding different needs of the debugging tools, that's precisely the problem here

Yesterday I spent the whole day trying my new Carbon bike, and thought that pro-ICEs are somehow like Carbon frame bikes, they cost a lot of money, but they offer insanely great performance.

Mine is cheap, but Aero Carbon Bikes can't go on dirt roads, they need some care for properly work, as well as some pro-ICEs need some special care about the source code to properly work.

Some pro-ICEs are able to directly understand the C code even without any host support (so they can be used in production, for QA), that means there is a kind of C-interpreter in their firmware, that's also why I do care to write the source code in a very clean way, otherwise the ICE doesn't understand it, and a human being (do you guess who?  ) needs to waste his time fixing stuff instead of enjoying his carbon bike.

I remember some years ago a colleague in Osaka must have "forgotten" (let's say "forgot") to add a token to the parse module, or something. I don't remember, but I remember that for I couple of hours I was tempted to kick the desk because it didn't work with nested-structs and I had to split them.

Kind of crazy situation when the workaround is that you first you define a type-struct, than you define a new type-struct and you use the previous definition, otherwise the tool doesn't understand things like this:

Code: [Select]

typedef struct
{
    struct /* now it's fix, but this didn't work for the ICE, because it didn't understand nested struct, O_M__G__! */
As result, I had to rework the code to save my day. Something like 30 lines of patch, and it didn't too so long, but it was rather annoying.


Anyway, yesterday night I asked the teams behind the Japanese C compiler (which fortunately is a division inside the same company) to kindly add the tag_name, because it's a "C standard feature".

And they questioned a lot. Why? what? Can you tell, umm? ... So very likely tomorrow we will have on a Skype micro conference, where, since I don't speak Japanese, I will repeat my email and look at my shoes.

[SiliconWizard]

The compiler seems a bit nasty, but why don't you just write:

Code: [Select]

struct my_sc_t
{
Which I guess should pass alright with this compiler?

Because this works for the compiler, but not for the ICE which needs to see types

Good lord, but the typedef's are still there!

[Siwastaja]

Code like this convinces me that Linus is right about typedefs

It's worth noting that Linus Torvalds thinks that people who reinvent the pointer syntax and bake it into the typedef should be shot 

https://yarchive.net/comp/linux/typedefs.html

[DiTBho]

Code like this convinces me that Linus is right about typedefs

It's worth noting that Linus Torvalds thinks that people who reinvent the pointer syntax and bake it into the typedef should be shot 

I just hope that for the Japanese of Higashiyodogawa it is not an ideological issue like Linus's, otherwise it's the right time that I change my job and I start preparing Aerobie AeroPress coffees for the cos-players in Tokyo 

We will see tomorrow ...

[SiliconWizard]

Code like this convinces me that Linus is right about typedefs

It's worth noting that Linus Torvalds thinks that people who reinvent the pointer syntax and bake it into the typedef should be shot 

https://yarchive.net/comp/linux/typedefs.html

I don't much like pointers "hidden" in type definitions either.
But structures not typedef'ed? That's insane. (But if I read correctly, Linus was not so harsh against this.)

The fact C has some kind of "dangling" type system with structs and unions and enums just each living in their own tag world is a legacy of early C, but does not make much sense IMHO.
The only reason I've been using struct tags is when I need forward definition (including recursive definitions of structs), since there's no way around that in C.

Data types are an abstraction per se. And whatever type you use, you need to know what there is behind it anyway to use it properly, in most cases. The exception is with "opaque" types - in which case, you need to use typedef anyway if you want to make them look really "opaque". (Like, who cares if the type is actually a struct or not if it's meant to be opaque?)

The point that typedefs "hide" data types is not a silly one, but it's questionable. But as it's very much in the coding style category and has a largely subjective side, it's probably not really useful to debate it.

[magic]

It makes sense in libraries where people would endlessly ask questions about what the members of the struct are and why accessing them doesn't seem to work. Telling them to use fuckoffitsasecret_t in the first place gets the message across

Subjecting yourself to this in a monolithic project like Linux is simply masochistic.

[Siwastaja]

But structures not typedef'ed? That's insane. (But if I read correctly, Linus was not so harsh against this.)

The reason for this seems to be simply matter of preference - and encouraging similar style across the whole project. Not a strong rule.

Some people prefer to use a typedef and add some made-up suffix to tell them it's a struct (like _struct or _s). If you think about it, this doesn't make a lot of sense, you could just use the bare language and the struct keyword!

Though, I typedef all my non-single-use structs, with the usual _t suffix. It's just what I'm used to. The keyword struct in the middle of the code just looks weird to me. But if I had to read more linux kernel code, I'm sure I'd get used to it in no time.

[DiTBho]

The only reason I've been using struct tags is when I need forward definition (including recursive definitions of structs), since there's no way around that in C.

Yup. Me too.

[DiTBho]

Subjecting yourself to this in a monolithic project like Linux is simply masochistic.

For programmers who were young in the 80's, nowadays you can just look at the line of code on the IDE, ask with one click-over, and it will tell you!

[DiTBho]

- We will add the struct tag_name to our SH4 C compiler - the promise they made today after 2 hours of conference yesterday.

It wasn't a piece of cake to convince them, but it's kind of victory for a celebration day, and I am so happy that I no more need to apply dirty patches to sources.

Yeess 

[Nominal Animal]

If one looks at the Linux Kernel Mailing List for GCC issues, one will see that there were quite a lot of cases where the kernel developers, too, had to convince the GCC folks to either guarantee a specific behaviour, or provide a compiler option to do so.

This is exactly what I mean when I say it is the practical use cases that override the standards, and not vice versa.  (The C standard itself, all the way up to C99, only described what compilers had already widely implemented; it is only since C11 that the standard started suggesting what compilers should implement.)

Sure, here the compiler isn't standards compliant in the first place, but the same demands of real-world code applies.

It would be very nice if the language was fully specified and standards-driven, with a reference implementation and all –– that would change the situation completely –– but for C, that just isn't possible due to the vast amount of existing code.

[SiliconWizard]

- We will add the struct tag_name to our SH4 C compiler - the promise they made today after 2 hours of conference yesterday.

I guess I hadn't fully understood the issue there, explaining my earlier answer. Either you description was not clear or I just assumed something because the actual issue was just not "believable".

So, I assumed that this compiler choked on using struct tags *in the context of a typedef*, but not outside of a typedef, which looked nasty but more believable as a compiler bug. Thus my answer. What led me to this assumption was, sure, that not supporting struct tags at all was kinda unbelievable, but your example code didn't show any struct definition outside of a typedef.

So not supporting struct tags at all? They were there for the longest time, even in original C, I think?

It wasn't a piece of cake to convince them, but it's kind of victory for a celebration day, and I am so happy that I no more need to apply dirty patches to sources.

It's obvious they wouldn't like any change, that's probably an already old compiler that has probably worked "well enough" for a long time, so they'd be reluctant.
Still, that one missing "feature" is absolutely unbelievable.

[DiTBho]

I assumed that this compiler choked on using struct tags *in the context of a typedef*, but not outside of a typedef

Their C parser is able to understand "typedef struct {" but not "typedef struct tag_name {". They assumed "tag_name" was optional, so the rule is missing in their parser.

struct tag_name is supported by their C compiler, but not by my ICE because we do not support tag_name space, we need type_space for our analyses, so I had to find a solution, which is ugly and only partially supported by my ICE, but hey? better than nothing.

As far as I understood, their SH4 C compiler was created in 2011, tested for two years and committed as stable. They said they never needed to support "typedef struct tag_name" before my code, but as now they want "QA" code and they buy some software stuff from my company plus other debugging tools, it is in their best interest to support the missing functionality.

[SiliconWizard]

Ah, so I understood correctly after all. And this was a mix of issues between their compilers and your own tools.
So in that case, does declaring the struct as I wrote not work with both?

Code: [Select]

struct <tag> { ... };
typedef struct <tag> <type>;

[DiTBho]

does declaring the struct as I wrote not work with both?

Code: [Select]

struct <tag> { ... };
typedef struct <tag> <type>;

It works for the Japanese SH4 C compiler but my ICE only considers type-space, not pure tag-space,  if something begins with "struct" without being preceded by "typedef" then it's ignored; therefore in your second line, "tag" is unknown.

[DiTBho]

Querying the ICE over the serial line(1), it says

Code: [Select]

typedef struct <tag> <type>;
<type> is opaque, still to be defined, which means it's recognized it as "opaque" and it's waiting for its definition, which unfortunately it won't never find because it doesn't understand "struct tag".

Code: [Select]

struct <tag> { ... }; // this line is ignored an not understood
I can even break-in, and manually teach the ICE about the tag through the debug channel, but the whole process should be automatic, so this is not acceptable.


(1) yes, I can *debug* the debugger 

[SiliconWizard]

I see, so it looks like your ICE is as "buggy" (read: limited) as the SH4 compiler.

[DiTBho]

I see, so it looks like your ICE is as "buggy" (read: limited) as the SH4 compiler.

The differences are
-  "struct without typedef" is bad habit and it's banned in several debugging plans
- "typedef tag" is supported ( the tag is a property in the type-space ) and used by several analysis tools

so they omitted "typedef tag" because they thought it was "optional", while we omit "struct without typedef" because it's useless, bad, not used during analyses, and supporting it would over-complicate the ICE firmware.

[SiliconWizard]

So you say. =)
But however you look at it, you're not supporting C fully in your own tool, and the compiler is not either. And both limitations unfortunately (and somewhat funnily) are orthogonal.

Now I suppose this is some in-house tool that is not actually used outside of your company? In which case, that's a different story for this reason. But otherwise...

[newbrain]

As far as I understood, their SH4 C compiler was created in 2011, tested for two years and committed as stable.

This is insane.
The standard is available for a modest sum (and the drafts are free).
There is plenty of conformance test suites.
And maybe they even want money for that compiler.
How can you trust its results when even the basic language features are misunderstood?

With the risk of stereotyping, I am quite surprised that this a Japanese firm: whenever I worked with Japanese people, both internal and external, they were extremely competent, thorough and precise.

I can understand that your ICE, an in-house built tool IIUC, which is not a compiler, might miss some stuff here and there.

[DiTBho]

How can you trust its results when even the basic language features are misunderstood?

I'm not naive enough to trust a C compiler without my own verification - their C compiler has been tested and is in great shape for what really matters: Gcc does not even support their DSP fuse-ISA, while the code generation of their C compiler is excellent! So don't overdo it now, no doubt "typedef struct tag" is a missing feature, but honestly rarely used and defined as "optional", so it's an "ops, we must have forgotten a branch in the parser table", and it makes perfect sense that I was not considered during their test cases.

[DiTBho]

the basic language features are misunderstood

I've seen far worse, a C compiler made by TI, where sizeof(char) returns 2.
*THIS* was/is crazy 

[magic]

Well, we have seen OP07 from TI which has more flicker noise than AD/LT subs, NE5532 from TI which has more THD than any other, TL072H from TI which is not a JFET opamp in the first place...
Starts to look like there is a pattern here

[DiTBho]

With the risk of stereotyping, I am quite surprised that this a Japanese firm: whenever I worked with Japanese people, both internal and external, they were extremely competent, thorough and precise.

umm, here nobody said those guys are not competent. You cannot judge people so fast!

We are talking about experimental things, it's too easy to speak about a compiler you just download from the web, and you get compiled with "./configure blablabla ; make ; make install". They *designed*, *implemented*, an *tested* it from scratch, and the story is easy: there was/is simply a radical different philosophy about the use of "structs"

Pretty like Linus vs others.

In two hours of micro-conference with a crappy microphone on a crappy Skype internet connection (plus my Japanese that honestly sucks, and my English that is quite idiomatic and gesticulated) the two delegates from the engineering department figured out my needs, talked to the management department and planned that the missing feature will be likely added in a couple of days.

- We know how to fix it, and we will quickly! - All of this in 2 hours!!! Not weeks or months.

That's what makes them extremely efficient and competent!

[newbrain]

I'm still not convinced.

there was/is simply a radical different philosophy about the use of "structs"

Philosophy? We are talking about basic language constructs.

This is literally the second example in the chapter "6.9 Typedef" of K&R's book - from the 1978 original one, same in the revised ANSI version:

Code: [Select]

typedef struct tnode {      /* the basic node */
    char *word;             /* points to the text */
    int count;              /* number of occurrences */
    struct tnode *left;     /* left child */
    struct tnode *right;    /* the right child */
} TREENODE, *TREEPTR;

How can they maintain that it's rarely used?

So, it's an "experimental" compiler from 10 years ago - good luck!

[DiTBho]

Philosophy? We are talking about basic language constructs.

Philosophy!

People like Linux never writes "typedef struct tag", as well as all the software they wrote to test the compiler never used "typedef struct tag". Always "struct tag".

It's radically different in terms of mental approach.

[DiTBho]

For me they did well to resume an old project that has remained dormant.
It is a great opportunity, a nice thing for these dark days.

edit:
Ok, guys, I won't tell more 

[newbrain]

People like Linux

I was not aware Linux managed to gain sentience. It really is more advanced than Windows. 

I'm sorry, but the mental approach of the user does not exonerate (and should not bind) a compiler writer. The language definition does.

Look at the Wikipedia. "typedef struct tag" is defined as "optional".

Sorry, but this is  .
In that vein, also int i = 5; is optional. Or the else part of an if. Or the default label in a switch().

I think we'll have to keep disagreeing (not the first, probably not the last time), but this makes for interesting discussions.

[magic]

On Wikipedia, factual accuracy is oftentimes optional
And where did you even find such information there?

[DiTBho]

I'm sorry, but the mental approach of the user does not exonerate (and should not bind) a compiler writer. The language definition does.

not even if it were your turn to fix things.

[Siwastaja]

One could think that a new compiler would be tested with at least the examples given in the language standard.

But of course, if the compiler is mostly for "internal use", then nothing prevents just not supporting some of the language features, if they are not used within that company.

[DiTBho]

One could think that a new compiler would be tested with at least the examples given in the language standard.

But of course, if the compiler is mostly for "internal use", then nothing prevents just not supporting some of the language features, if they are not used within that company.

Precisely! 

[DiTBho]

On Wikipedia, factual accuracy is oftentimes optional

Yup, no doubt about 

- What will happen with your ICE with typedef struct XYZ { ... } XYZ; ? - asked a senior dude during the micro-conference.

Who? What? 

For the Wikipedia you are free to choose both the tag-name and the type-name

Code: [Select]

typedef struct tag_name
{

} type_name;
and it doesn't discourage you from choosing type_name = tag_name, which is the senior's question: what will happen in this case?

Code: [Select]

typedef struct myxyz // <---------- collision? or will it work?
{

} myxyz; // <---------- collision? or will it work?
His doubt was solid because, at the open brace, his old C compiler registers myxyz as a structure tag name, and then when myxyz appears a second time, you get a syntax error, clarified as "redeclaration error", so he was curious to understand how our ICE behaves in that case.

Crucial question - although it is not a problem for the modern c compiler, it's not recommended ... - I replied
- yes, but what about your ICE in this specific case? - he frowning asked

The screen was forming an expression of disapproval, typically by turning down the corners of the mouth - well,  ... it depends - I glossed, and we got five second of reciprocal awkwardness.

His colleague then asked me why I am using "typedef struct tag type" in the first place, since, he pointed point out , one should *typedef something* when its data is inaccessible (opaque), or when the data is not supposed to be edited by hand, and in both cases they will probably only use the type in one header, in which case you can omit the tag (which is nothing but a true struct-name).

And they don't like to use the tag in "typedef struct tag" because seniors still fear that every name you add to the global namespace increases the chance of a collision.

Now, back to his question, I got a quick flashback on the standard workaround for the above trouble (to avoid collision), which an article on Dr. Dobb's Journal described as the simple trick of making the structure tag name a minor modification of the typedef name, most typically by putting a word e.g. "tc" or "sc" in front.

Code: [Select]

typedef struct tc_myxyz // <---------- thanks to this trick
{

} myxyz; // <---------- no more collision
We are talking about 1989-1995, there was kind of inertia to adapt to the standard, and this is what programmers do with ancient C compilers where using the same name causes a name collision.

Standard C begins with C89 and modern C compilers separate the structure and typename name spaces, the workaround is no longer necessary, but some-people is still used to use it.

And, sometimes that's not what you get with some tools; for example our ICE ... in performance analysis keeps structure tags, union tags, and typedefs in the same namespace to save precious RAM, so in this case it will report collision-errors.

[newbrain]

Just as a single data point, I eyeballed* the ~150 repos that make up our product (just a part of a bigger thing), something in the ballpark of 10 MLOC.
The use of typedef struct struct_tag { accounts for about 30% of the typedefs.

It's there both in legacy and in recent code.

But yes, an internal tool is less constrained than a publicly available one. I understood it was something they bought.

Out of curiosity, is the behaviour the same for typedef enum tag { or typedef union tag { ?
If so, maybe you should pressure them to make sure it's fully corrected.

*OpenGrok helped me. Unfortunately it does not support regexp in search, at least in our installation.

[DiTBho]

A lot of the firmware I analyzed and reworked, use void* to bypass the problem.

When you cannot recursively use struct*, you use void* inside the struct.
It's ugly and requires casting, but it's what I have observed in the last 10 years.

Someone calls that "void*" as "beaver", never understood why 

They say "use the beaver pointer", like in star wars they say "use the force", or something.
I don't know what a beaver is supposed to do, so I don't know why they say so, perhaps because a beaver builds dams with mud, branches and stones, so, because the beaver survives with an hack that should be solid engendering, but actually it works.

It's an idiomatic urban dictionary used by some hackers of the deep internet underground, probably a joke or something.

Anyway, if this is a true hack, articles about SmallC are plenty of examples about that.

Next time your C compiler doesn't support typedef struct tag, remember you can always "use the beaver" 

(damn, now I want a t-shirt with that meme!!! I want it!  )

Out of curiosity, is the behaviour the same for typedef enum tag { or typedef union tag { ?
If so, maybe you should pressure them to make sure it's fully corrected.

typedef enum tag and typedef union tag are supported and work well.
No problem at all.

[DiTBho]

One of my Dr. Dobb's Journal. Perhaps The best one.
But it's not the one with the trick I mentioned above.

[newbrain]

typedef enum tag and typedef union tag are supported and work well.
No problem at all.

Bizarrer and bizarrer.

Why single out structs then?
It would seem to be the exact same kind of parse tree, it's the same use case, especially with unions, and, most important, it's the frigging same tag namespace that got the 'senior' so worried!

I must admit you are a mine of odd stuff.
You should print that T-shirt with one of the many online services!

[SiliconWizard]

If they just singled out struct tags in this context, then it's definitely either just that they *forgot* to implement this... or, that they *intentionally* didn't implement it because, as they stated, they thought it was "optional" and they decided not to implement it as such, in order to make the product "leaner" so to speak, which would be a typically japanese attitude actually.

What is unfortunate is that they didn't read the standard, or could not make sense of it, and of course, the bizarre factor is why did they think tags were not optional for unions and enums?

[DiTBho]

*forgot* to implement this

This one!
Considered optional.
A sort of "if it's optional, then will be implemented if we have the will and the time, otherwise skipped".
And nobody noticed before me because they *use the beaver* 

[DiTBho]

the bizarre factor is why did they think tags were not optional for unions and enums?

Seniors are so worried about collisions that those other two tags have never been used seriously internally the company.

Literally I can't find anything but only test-cases, to test their C compiler, that use those two supported tags.  Not a firmware, or something. It intrigued me and I wrote a couple of simple-demos and everything works with them, but it's not even mentioned anywhere except in a couple of test-cases.

It's more likely the reason was that they started implementing them, but then ran out of time and skipped the struct-tag function completely (to be done later ... then forgotten forever)

Who knows 

edit:
Before being presented on the Dr. Dobb's Journal magazine in the 90s, the first versions of SmallC were full of similar oddities with tags, firstly banned to simplify stuff (name-collisions was a real issue), then un-banned because each kind of typedef must have its personal space, and ... the C compiler code got fixed, improved and extended, and finally polished when they understood that Small-C was important for tiny computers in a manner somewhat analogous to the importance of GCC for larger computers.

Anyway, nowadays, it's time for llvm / clang ... I am afraid that stuff is only good for veterans and sweet memories 

[SiliconWizard]

I still stick to GCC rather than LLVM for a number of reasons. But that's another story.