Re: [Tinycc-devel] inline assembly and optimization passes

[Sylvain BERTRAND]

> A purpose for everything, and for everything a purpose. C is a
> difficult language to write big programs in, most of all because you
> have to do all memory management yourself (non-cyclic dependencies
> make this easy, cyclic dependencies make this hard, data outside of
> basic foundations such as trees usually involves cyclic
> dependencies... and unlike those you can introduce to basic data
> structures, these dependencies are not simple to manage). It's also an
> awkward language due to it's lack of higher-end constructs such as
> classes, closures (well, lambda functions, really), casting operators,
> and language-enforced RAII.
> 
> The applications language would be C-based, a closure would look
> something like the following:
> 
> _int( _int ) _closure abs = @< _int ( _int arg ) { _return( arg >= 0 ?
> arg : -arg ); };
> 
> Basically, a rationalized form of C (e.g., pointers are now part of
> the TYPE portion of the declaration, NOT the VARIABLE part; a keyword
> is used instead of a re-purposed operator; and the pointer operators
> have their own character sequences instead of reusing other's), and
> THEN adapted to the application-programming realm. Part of the idea is
> that while C has the right basic syntax, when you get out of the
> bare-metal realm you want some richer (and, more importantly, more
> convenient) features to use. Thus, a language that takes the most of
> the good from C, tries to fix the bad (declaration and pointer syntax
> goofs, namespace collisions, multiple types in a single declaration),
> and adds some general convenience features, such as GC (because doing
> it correctly is hard), and some things that GC suddenly makes
> practical (like closures).
> 
> The output of the compiler would be C, intended to be linked with a
> provided runtime library (it wouldn't be that big, as the "standard
> library" would be something separate: the runtime provides the bits
> inherently required by the language, the standard library provides the
> stuff you normally use, and thus can be replaced with what the
> programmer wants). This would certainly be made easier by the firm
> resemblance to C (everything will either be lifted from C, implemented
> with a C library, or built on top of such capabilities).
> 
> Frankly, if I were running a software company, I would keep most of my
> employees away from languages like C-- while on company time. The
> moment you get into memory management, everything becomes more
> complex, and the simple reference counting scheme that seems to
> commonly be used isn't up to the job of correctly managing
> reference-loops. It's a task best left to a dedicated library.
> 
> I don't think the designers of C-- would suggest it for applications
> programming, or at least some systems programming, either. C-- (unless
> you're talking about the Sphinx one, which I don't remember anything
> about) was designed as a language for COMPILERS to target. And indeed,
> you could design a fairly good compiler target language if you lifted
> syntax from C. Unfortunately, C-- is (at least to the best of my
> knowledge) tied rather directly to the x86 architecture. Furthermore,
> as I best recall the only real advantage that it had was a swap
> operator, and some more-efficient versions of e.g. if. This is not
> really what you want in a compiler-target language. What you really
> want to a way to describe functions and data structures in such a way
> that you both convey the details that you require, and allow the "C--"
> compiler to reinterpret your information into an improved form.
> Annotations are certainly useful for this, but you're probably not
> quite looking at C, because I'm pretty certain that you would really
> want compile-time code to be run during that phase, which C in no way
> provides for.

Again, I mostly do not agree and you really keep missing
my point: a C- compiler would be easier to code than a C compiler
(C-- is a project already taken by some evil people and is not
interesting). And I would use it for system and application
programming. I'm going the "other way", I certainly do *not* want
a language which has a richer syntax, with a special attention
*not* to have more complex data structures (class...),
because it makes the syntax exponentially more complex (one of
the worst being c++).

The comfort provided by a higher level language is never worth its technical 
cost.
That's my final opinion based on my "ground" experience.

Moreover, as I said, you end up in facts with tons of "high
level" languages, which make the software stack insanely costly.

Sure if C- happens one day, pointer syntax and implicit casts
will need some cleanup, and I'm thinking about friendlyness with
formal proof.

> The "standard route" to optimizations is that your C parse outputs
> something that represents the C input, but in a more convenient form,
> which is then read in by your optimizer and assembler. As I understand
> it, this is normally some version of Polish notation (either normal,
> or reverse) due to the greater ease in parsing it.
> 
> C is sometimes used as intermediate code, but in those instances it is
> used as if it were assembly code, being handed to an assembler, rather
> than intermediate code being handed to an optimizer. You should be
> able to come up with a C-derived syntax that would work well as a true
> IC, but I wouldn't try to do it with C itself, just with something
> based on it.
> 
> Honestly, using C as an intermediate code for optimizers IS a kludge:
> if it were genuinely a good idea, it would have become common. C aims
> to be a systems language, and while you could PROBABLY make your idea
> work, I wouldn't want to bet on it working any better than attempting
> to write an OS in Java, if even that well.
> 
> Besides which, all of the important bits of optimization are in the
> syntax tree. C might be chosen by someone as an output for an
> optimization stage, but x86 assembly would do roughly as well, or JVM
> bytecode, or CIL, or whatever else. The output is a distraction, you
> should erase it from your mind.

Indeed, from a parse-tree, it may be really hard to generate C
code, even insane. But the idea of passes which "clean C code" is
very sexy because you may be able to "see" what did each cleanup
pass. Since I have no experience on the matter... need to try
one day. Sure it would limit the type of optimization pass you
would want, but for tinycc, a good thing would be to give it
enough performance boost, to reasonnably drop gcc (from 4.8).

> Get a parse-tree builder first. Worry about specific uses afterwards.

Right, that would be the first step.

Now, it's trying to code something, namely trying to get some
"brain" time (the really hard part is here).