Re: Baby X is bor nagain

On 25/06/2024 16:12, David Brown wrote:

On 25/06/2024 17:08, Scott Lurndal wrote:

bart <bc@freeuk.com> writes:

On 25/06/2024 14:48, Scott Lurndal wrote:

>

That's why in my original post in this sub-thread, in order to give
a feeling of the size of compiler's job I gave the size of text
segment rather than size of the elf.
The size of text segment is, of course, not a good measure of
compiler's job, esp. when we are trying to compare compile jobs for
different target architectures, but it is less bad than any alternative
measure [that is not too hard to gather] that I can think of.
If you can think about anything better, please tell us.

>
Does the compiled code meet functional and performance  specifications?
>
That's the only criteria that matters.  Size of the executable
and compilation speed are basically irrelevent metrics in my
experience.

>
If apparently anything goes,

>
I never said that.
>

and you don't care how slow a tool is or

>
I never said that.
>

how big its output, how do you detect unnecessary bloat?

>
I don't write programs with unnecessary bloat.
>

>
How do you detect gratuitous use of machine resources?

>
I write code that doesn't gratuitously use machine resources.
>

 These answers apply to me tool.
 

>
BTW since you and DB are both keen on products like Python,

>
I have never posted anything about python here, that I recall.
>
I use it very infrequently.

(It seemed to be a big part of that 8Mloc project of yours)

 I /do/ use Python.  I use it when it is an appropriate language to use,   which is very different circumstances from when I use C (or C++). Different tools for different tasks.
 

And yet neither of you are interested in answering my question, which was why its simplistic bytecode compiler is acceptable in this scenario, but would be considered useless if applied to C code.