Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #381780 > unrolled thread

What I've learned in comp.lang.c

Back to article view | Back to comp.lang.c

Contents

  What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-05 01:09 +0000
    Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 05:58 +0000
      Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 22:49 -0800
        Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 07:03 +0000
          Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:51 -0800
            Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:52 -0800
              Re: What I've learned in comp.lang.c Jan van den Broek <balglaas@dds.nl> - 2024-02-05 08:36 +0000
      Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:23 +0200
      Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:32 +0200
        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 20:53 +0100
          Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 20:53 +0000
            Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:44 +0100
              Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:03 -0800
              Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 13:41 +0200
                Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 13:08 +0100
              Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:23 +0000
                Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:54 +0100
                  Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 08:59 +0000
                    Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:47 +0000
                      Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 11:04 +0000
                        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:21 +0100
                          Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 14:24 +0000
                            Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:30 +0100
                        Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:36 +0000
                          Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 18:05 +0000
                            Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 18:26 +0000
                              Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 19:53 +0000
                                Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:38 +0000
                                  Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:29 +0000
                            Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:37 +0100
                              Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 22:52 +0000
                                Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:13 +0000
                                  Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 02:09 +0000
                                    Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
                                      Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 14:17 +0000
                                    Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 16:02 -0800
                                      Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-09 00:48 +0000
                                        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 08:53 +0100
                                        Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 21:55 -0800
                                Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:01 +0100
                            Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:37 +0000
                              Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:10 +0000
                                Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:24 +0100
                                  Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 13:03 +0000
                                  Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 13:17 +0000
                                    Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 16:52 +0100
                                Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:17 +0000
                              Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 14:50 -0800
                      Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 12:44 +0000
                        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:49 +0100
                        Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 16:13 +0000
                        Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 08:21 -0800
                    Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:01 +0100
                      Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-07 13:21 +0000
                      Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 13:42 +0000
                        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 16:17 +0100
                      Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:34 +0000
                    Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:21 +0000
                      Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:26 +0200
                  Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:04 +0000
                    Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:51 +0100
                      Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:30 +0000
                        Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 15:45 +0000
                          Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:44 +0100
                            Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:33 +0000
                              Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:30 +0000
                              Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 01:38 +0000
                                Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 02:21 +0000
                                  Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
                          Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:45 +0000
                            Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:15 +0000
                              Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:29 +0100
                                Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:55 +0000
                                  Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:02 +0100
                                Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 16:09 +0000
                                  Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-08 16:28 +0000
                                  Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:13 +0000
                        Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:53 -0800
      Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 19:02 +0200
        Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:28 +0000
          Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-05 23:40 +0000
          Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 01:46 +0200
            Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:54 +0100
          Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:03 -0800
            Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:06 -0800
          Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:50 +0100
            Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:01 -0800
            Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:24 +0000
              Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:56 +0100
                Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 12:09 +0200
                  Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 15:03 +0100
                Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:25 +0000
                  Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:49 +0100
                    Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-07 13:04 -0800
                    Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 23:37 +0200
                      Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 08:52 +0100
                        Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 15:55 +0200
                          Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 15:29 +0100
                            Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 16:52 +0200
                              Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 17:22 +0100
                                Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 07:18 +0000
                                  Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-10 17:11 +0100
                                    Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:23 +0000
                                      Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-11 14:01 +0100
                  Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:41 +0000
      Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 02:18 +0000
        Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 09:30 +0100
        Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 09:04 +0000
        Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 23:24 +0000
          Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 01:46 +0000
            Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 02:50 +0000
              Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 11:08 +0000
              Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:10 +0200
                Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 17:48 +0000
                  Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 21:30 +0200
                  Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 20:39 +0000
                  Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 13:39 -0800
                    Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 14:18 -0800
                      Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-08 22:29 +0000
                        Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 14:43 -0800
                          Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:12 +0100
    Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 23:36 -0800
      Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:52 +0000
        Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 22:58 +0000
      Re: What I've learned in comp.lang.c Jim Jackson <jj@franjam.org.uk> - 2024-02-05 18:01 +0000
    Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 08:29 +0000
      Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 01:35 +0000
        Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 02:26 +0000
          Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 10:47 +0000
    Re: What I've learned in comp.lang.c Dan Purgert <dan@djph.net> - 2024-02-05 11:03 +0000
    Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 13:15 +0100
      Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-05 14:09 +0000
    Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:29 +0000

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#382260

On Fri, 9 Feb 2024 17:22:53 +0100, David Brown wrote:

> But we have lots of them using embedded Linux.

What sort of CPUs, out of interest? Presumably x86/x86-64, ARM ... maybe 
even RISC-V by now? Anything else (e.g. Motorola ColdFire)? Any feel for 
relative popularity?

[toc] | [prev] | [next] | [standalone]

#382274

On 10/02/2024 08:18, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 17:22:53 +0100, David Brown wrote:
> 
>> But we have lots of them using embedded Linux.
> 
> What sort of CPUs, out of interest? Presumably x86/x86-64, ARM ... maybe
> even RISC-V by now? Anything else (e.g. Motorola ColdFire)? Any feel for
> relative popularity?

Almost all ARM, as far as I know, with a couple of x86 systems.  But I 
don't know the details of everything we make as pure production 
contracts - it's only if the developers are needed to help with 
problems, suggest improvements for the customers, or work with test 
setups that we get involved.

Long ago, I worked a little with both MIPS and Coldfire embedded Linux 
systems, but those are pretty much gone from the market now.

[toc] | [prev] | [next] | [standalone]

#382280

On Sat, 10 Feb 2024 17:11:47 +0100, David Brown wrote:

> Long ago, I worked a little with both MIPS and Coldfire embedded Linux
> systems, but those are pretty much gone from the market now.

MIPS gone as well? At one point I heard they were accounting for something 
like 840 million chips per year. They had a particular niche in wireless 
routers.

The company that used to own what there was of the MIPS IP is now called 
Imagination Tech, and has gone all-in on RISC-V.

[toc] | [prev] | [next] | [standalone]

#382331

On 10/02/2024 22:23, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 17:11:47 +0100, David Brown wrote:
> 
>> Long ago, I worked a little with both MIPS and Coldfire embedded Linux
>> systems, but those are pretty much gone from the market now.
> 
> MIPS gone as well? At one point I heard they were accounting for something
> like 840 million chips per year. They had a particular niche in wireless
> routers.
> 

Emphasis on /had/.  MIPS used to be the most common architecture in 
routers of all kinds, but they have been pushed out by ARM.  You see 
them only in legacy designs.  (Of course, many routers, switches, and 
the like are still made with them - there's no need to change a hardware 
design that works perfectly well for the task.  But you won't find many 
/new/ chips with MIPS cores.)

> The company that used to own what there was of the MIPS IP is now called
> Imagination Tech, and has gone all-in on RISC-V.

RISC-V has a number of technical and economic advantages over the 
incumbent, ARM.  How much of the market it will take remains to be seen. 
  (I personally hope it gains a lot - the x86/ARM duopoly is not good 
for the market.)

[toc] | [prev] | [next] | [standalone]

#382033

On Wed, 07 Feb 2024 16:25:45 GMT, Scott Lurndal wrote:

> ... the linux kernel + busybox is probably the most common.

That “Ingenuity” Mars helicopter, that recently met its end after breaking 
a rotor blade, ran Linux and other open-source software.

It was very much an afterthought project, a proof of concept, only meant 
to last maybe 30 days. It ended up making dozens of flights over 3 years.

[toc] | [prev] | [next] | [standalone]

#381940

On 05/02/2024 05:58, Kaz Kylheku wrote:
> On 2024-02-05, bart <bc@freeuk.com> wrote:

> Writing a compiler is pretty easy, because the bar can be set very low
> while still calling it a compiler.

> Whole-program compilers are easier because there are fewer requirements.
> You have only one kind of deliverable to produce: the executable.
> You don't have to deal with linkage and produce a linkable format.

David Brown suggested that they were harder than I said. You're saying 
they are easier.

BTW your statements are wrong, but I'm not going to argue about it.

My whole-program compiler is here:

  https://github.com/sal55/langs/blob/master/MCompiler.md

It has a dozen different outputs.


> GCC is maintained by people who know what a C compiler is, and GCC can
> be asked to be one.

So what is it when it's not a C compiler? What language is it compiling 
here:

   c:\qx>gcc qc.c
   c:\qx>

This program passes. Mine does the same:

   c:\qx>mcc qc.c
   Compiling qc.c to qc.exe

Whatever language that mcc processes must be similar to that that gcc 
processes.

Yet it is true that gcc can be tuned to a particular standard, dialect, 
set of extensions and a set of user-specified behaviours. Which means it 
can also compile some Frankensteinian version of 'C' that anyone can devise.

Mine at least is a more rigid subset.

> Your idea of writing a C compiler seems to be to pick some random
> examples of code believed to be C and make them work.  (Where "work"
> means that they compile and show a few behaviors that look like
> the expected ones.)

That's what most people expect!


> Basically, you don't present a very credible case that you've actually
> written a C compiler.

Well, don't believe it if you don't want. There 1000s of amateur 'C' 
compilers about, it must be the most favoured language for such projects 
(since it looks deceptively simple).

Among such compilers, mine is quite accomplished by comparison. One task 
it is used for is to take APIs defined by C header files and turn into 
into bindings in my two languages. It does that as well as any such tool 
can. So fuck you.

> I currently work on a a firmware application that compiles to a 100
> megabyte (stripped!) executable.

And yet 90% of the executables on my PC are under 1MB. SOMEBODY must be 
writing small programs!

The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7% 
smaller than your giant program.

You want to make me feel bad about my stuff because you work on a big 
project and mine are small. Let me go and find that length of rope then...


>> * There is not a single feature of my alternate systems language that is
>> superior to the C equivalent
> 
> The worst curve ball someone could throw you would be to
> be eagerly interested in your language, and ask for guidance
> in how to get it installed and start working in it.

That happened 2-3 years ago and I was able to help out. However I'm not 
pushing my actual language, which is anyway volatile as it is a vehicle 
for new ideas, I was only discussing the utility of certain features.

Surely somebody can do that without going to the trouble of creating and 
implementation a whole language, and using the feature over years, as 
proof of concept.

But when someone actually does that, THEN they are not worth listening to?

I mean, where is YOUR lower-level system language? Where is anybody's? I 
don't mean the Zigs and Rusts because that would be like comparing a 
40-tonne truck with a car.

My language is a modernish family car compared with C's Model T.

> Not as much as fast executable code, unfortunately.

And yet most people code in Python and JavaScript and a whole pile of 
slow languages.

> Compilers that blaze through large amounts of code in the blink of an
> eye are almost certainly dodging on the optimization.

Yes, probably. But the optimisation is overrated. Do you really need 
optimised code to test each of those 200 builds you're going to do today?

Not for a language at the level of C. (Maybe for C++ code as it needs it 
to collapse the mountain of redundant code that templates etc will produce.)

For the programs I write, gcc-O3 makes then 1.5 to 2.0 faster typically, 
for 100 times longer compile time.

And if I do want the boost, I can transpile to C to use gcc-O3. I don't 
need the super-optimisation within my own product.

> And because they
> don't need the internal /architecture/ to support the kinds
> optimizations they are not doing, they can speed up the code generation
> also. There is no need to generate an intermediate representation like
> SSA; you can pretty much just parse the syntax and emit assembly code in
> the same pass. Particularly if you only target one architecture.
> 
> A poorly optimizing retargetable compiler that emits an abstract
> intermediate code will never be as blazingly fast as something equally
> poorly optimizing that goes straight to code in one pass.

My non-C compiler uses multiple passes including an IL stage. It is not 
much slower than TCC which is one pass, but generally produces faster code.

It can compile itself at about 15Hz. (That is, 15 new generations per 
second. Unoptimised.)

>> * There is no benefit at all in having a tool like a compiler, be a
>> small, self-contained executable.
> 
> Not as much as there used to, decades ago.

Simplicity is always good. Somebody deletes one of the 1000s of files of 
your gcc installation. Is it something that is essential? Who knows.

But if your compiler is the one file mm.exe, it's easy to spot if it's 
missing!

[toc] | [prev] | [next] | [standalone]

#381950

On 07/02/2024 03:18, bart wrote:
> On 05/02/2024 05:58, Kaz Kylheku wrote:
>> On 2024-02-05, bart <bc@freeuk.com> wrote:
> 
>> Writing a compiler is pretty easy, because the bar can be set very low
>> while still calling it a compiler.
> 
>> Whole-program compilers are easier because there are fewer requirements.
>> You have only one kind of deliverable to produce: the executable.
>> You don't have to deal with linkage and produce a linkable format.
> 
> David Brown suggested that they were harder than I said. You're saying 
> they are easier.

I described what /I/ see as "whole program compilers", and where I see 
them being used as serious tools that give better results than 
traditional compile-and-link toolchains.  The key here is whole program 
/optimisation/ and static analysis.  And I think there can be little 
doubt that this is a far harder task than the much more limited tools 
you are talking about.

Maybe it was unreasonable of me to conflate "whole program compiler" and 
"whole program optimiser", even though I see no real-world use of the 
former without the later.  Using your definition of the term, your tool 
is a "whole program compiler".

And I think Kaz was using the term in the same way as you do when he 
says he thinks it is easier.  I don't know either way, but it would 
certainly skip several things that are otherwise necessary in a 
traditional setup - assembly generation, an assembler, and a linker. 
You also don't have to deal with linking object files from other sources.

(For the record, I there are many things that cannot be done with C and 
traditional compile-link setups, that could be done with some kind of 
whole-program analysis and a suitable language.  Rust's borrow checker, 
and XMOS XC's thread analysis are two examples.)

> 
>> GCC is maintained by people who know what a C compiler is, and GCC can
>> be asked to be one.
> 
> So what is it when it's not a C compiler? What language is it compiling 
> here:
> 

You walked right into that one - how many times has the difference 
between standard C and sort-of-C been explained to you?  As always, I 
must point out that a tool does not have to be standards compliant - 
that's a choice of the tool developer.  But when the distinction is 
made, and Kaz was clearly making that distinction, a "C compiler" is one 
that follows the C standards (one or more published version) accurately 
in terms of what it accepts or does not accept, the minimum guaranteed 
behaviour, and the minimum required diagnostics.  As has been explained 
many times, "gcc" is not, in those terms, a "C compiler" by default - it 
needs flags to put it in a compliant mode.  Your tool, AFAIK, has never 
claimed to be a standards-compliant C compiler.

> 
> Whatever language that mcc processes must be similar to that that gcc 
> processes.

Yes.  Both accept some version of sort-of-C, with a common subset.  (The 
common subset in this example code may also, by coincidence, be standard 
C.  I haven't looked at it to see.)

> 
> Yet it is true that gcc can be tuned to a particular standard, dialect, 
> set of extensions and a set of user-specified behaviours. Which means it 
> can also compile some Frankensteinian version of 'C' that anyone can 
> devise.
> 
> Mine at least is a more rigid subset.
> 

Your idea of "rigid" is other people's idea of "inflexible".  Rigid is 
fine for one user.


>> Your idea of writing a C compiler seems to be to pick some random
>> examples of code believed to be C and make them work.  (Where "work"
>> means that they compile and show a few behaviors that look like
>> the expected ones.)
> 
> That's what most people expect!
> 

No, it is not.  /I/ expect a compiler to be written by people who have 
extensive knowledge of the C standards and who do their best to get the 
compiler correct /by design/.  Not by luck or trial and error.  By 
/design/.  And I expect it to have an extensive test suite of both 
simple code and extreme code and corner cases, because even the best 
designers can get things wrong sometimes and testing helps catch bugs.

[toc] | [prev] | [next] | [standalone]

#381953

On 07/02/2024 02:18, bart wrote:
> On 05/02/2024 05:58, Kaz Kylheku wrote:
>>
> 
>> Basically, you don't present a very credible case that you've actually
>> written a C compiler.
> 
> Well, don't believe it if you don't want. There 1000s of amateur 'C' 
> compilers about, it must be the most favoured language for such projects 
> (since it looks deceptively simple).
> 

It's absolutely clear to me that Bart has written a C compiler, and this 
statement by Kaz is ridiculous.

> 

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

[toc] | [prev] | [next] | [standalone]

#382040

On 2024-02-07, bart <bc@freeuk.com> wrote:
> On 05/02/2024 05:58, Kaz Kylheku wrote:
>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>
>> Writing a compiler is pretty easy, because the bar can be set very low
>> while still calling it a compiler.
>
>> Whole-program compilers are easier because there are fewer requirements.
>> You have only one kind of deliverable to produce: the executable.
>> You don't have to deal with linkage and produce a linkable format.
>
> David Brown suggested that they were harder than I said. You're saying 
> they are easier.

I'm saying it's somewhat easier to make a compiler which produces an
object file than to produce a compiler that produces object files *and*
a linker that combines them.

There is all that code you don't have to write to produce object files,
read them, and link them. You don't have to solve the problem of how to
represent unresolved references in an externalized form in a file.

David made it clear he was referring to whole program optimization.

>> GCC is maintained by people who know what a C compiler is, and GCC can
>> be asked to be one.
>
> So what is it when it's not a C compiler? What language is it compiling 
> here:
>
>    c:\qx>gcc qc.c
>    c:\qx>

Yes, sorry. It is compiling C also: a certain revision of GNU C,
which is family of dialects in the C family.

> Mine at least is a more rigid subset.

Rigid? Where this subset it documented, other than in the code?

GNU C is documented, and tested.

>> Your idea of writing a C compiler seems to be to pick some random
>> examples of code believed to be C and make them work.  (Where "work"
>> means that they compile and show a few behaviors that look like
>> the expected ones.)
>
> That's what most people expect!

That's may be verbal way of expressing what a lot of developers
want, but it it has to be carefully interpreted to avoid a fallacy.

"Most people" expect the C compiler to work on /their/ respective code
they care about, which is different based on who you ask. The more
people you include in a sample of "most people", the more code that is.

Most people don't just expect a compiler to work on /your/ few examples.

>> Basically, you don't present a very credible case that you've actually
>> written a C compiler.
>
> Well, don't believe it if you don't want.

Oh I want to believe; I just can't do that which I want, without
proper evidence.

Do you have a reference manual for your C dialect, and is it covered by
tests? What programs and constructs are required to work in your C dialect?
What are required to be diagnosed? What is left undefined?

If you make changes to the compiler which accidentally cause it to stray
from the dialect, how are you informed?

> The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7% 
> smaller than your giant program.

That's amazingly large for an assembler. Is that stripped of debug info?

> I mean, where is YOUR lower-level system language? Where is anybody's? I 
> don't mean the Zigs and Rusts because that would be like comparing a 
> 40-tonne truck with a car.

I'm not interested in working on lower-level systems languages.

I work on a the implementation of a Lisp dialect.

As far as low-level systems goes, I'm quite satisfied with the C
language and its mainstream implementations.

>> Compilers that blaze through large amounts of code in the blink of an
>> eye are almost certainly dodging on the optimization.
>
> Yes, probably. But the optimisation is overrated. Do you really need 
> optimised code to test each of those 200 builds you're going to do today?

Yes, because of the principle that you should test what you ship.

>>> * There is no benefit at all in having a tool like a compiler, be a
>>> small, self-contained executable.
>> 
>> Not as much as there used to, decades ago.
>
> Simplicity is always good. Somebody deletes one of the 1000s of files of 
> your gcc installation. Is it something that is essential? Who knows.

That someone will have to hack the superuser account, since those
files are writable only to root, sitting in directories that are
writable only to root.

You will know when someting complains about the file not being found.

(A problem will arise if the file is part of a search, such that another
file will be found if that one is missing.)

> But if your compiler is the one file mm.exe, it's easy to spot if it's 
> missing!

What if a bit randomly flips in mm.exe? Is it in a byte that is
essential? Who knows ... I don't see where this is going.

Sofware installations big and small can be damaged.

It seems disadvantageous for a compiler to have no satellite files.  If
you have to fix something in <stdlib.h>, and that's buried in the
executable, you have to roll out a whole new mm.exe. The user has to
believe you when you say that you changed nothing else.

If the satellite files are kept reasonably small in number, and not
proliferated throughout a complex tree, that could be a good thing.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#382062

On 07/02/2024 23:24, Kaz Kylheku wrote:
> On 2024-02-07, bart <bc@freeuk.com> wrote:
>> On 05/02/2024 05:58, Kaz Kylheku wrote:
>>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>
>>> Writing a compiler is pretty easy, because the bar can be set very low
>>> while still calling it a compiler.
>>
>>> Whole-program compilers are easier because there are fewer requirements.
>>> You have only one kind of deliverable to produce: the executable.
>>> You don't have to deal with linkage and produce a linkable format.
>>
>> David Brown suggested that they were harder than I said. You're saying
>> they are easier.
> 
> I'm saying it's somewhat easier to make a compiler which produces an
> object file than to produce a compiler that produces object files *and*
> a linker that combines them.

Is there a 'than' missing above? Otherwise it's contradictory.

> There is all that code you don't have to write to produce object files,
> read them, and link them. You don't have to solve the problem of how to
> represent unresolved references in an externalized form in a file.
Programs that generate object files usually invoke other people's linkers.

But your comments are simplistic. EXE formats can be as hard to generate 
as OBJ files. You still have to resolve the dynamic imports into an EXE.

You need to either have a ready-made language designed for whole-program 
work, or you need to devise one.

Plus, if the minimal compilation unit is now all N source modules of a 
project rather than just 1 module, then you'd better have a pretty fast 
compiler, and some strategies for dealing with scale.

If your project involves only OBJ format, then you can also choose to 
devise your own simple file format, then linking is a trivial though 
fiddly task.

> David made it clear he was referring to whole program optimization.
> 
>>> GCC is maintained by people who know what a C compiler is, and GCC can
>>> be asked to be one.
>>
>> So what is it when it's not a C compiler? What language is it compiling
>> here:
>>
>>     c:\qx>gcc qc.c
>>     c:\qx>
> 
> Yes, sorry. It is compiling C also: a certain revision of GNU C,
> which is family of dialects in the C family.
> 
>> Mine at least is a more rigid subset.
> 
> Rigid? Where this subset it documented, other than in the code?

In early versions of the compiler, there was a specification. Now, it's 
a personal tool and I don't bother. So shoot me.

> GNU C is documented, and tested.
> 
>>> Your idea of writing a C compiler seems to be to pick some random
>>> examples of code believed to be C and make them work.  (Where "work"
>>> means that they compile and show a few behaviors that look like
>>> the expected ones.)
>>
>> That's what most people expect!
> 
> That's may be verbal way of expressing what a lot of developers
> want, but it it has to be carefully interpreted to avoid a fallacy.
> 
> "Most people" expect the C compiler to work on /their/ respective code
> they care about, which is different based on who you ask. The more
> people you include in a sample of "most people", the more code that is.
> 
> Most people don't just expect a compiler to work on /your/ few examples.

A C compiler that works on any arbitrary existing code is years of 
effort. That's hard enough to achieve even with better and more mature 
products than mine.

>>> Basically, you don't present a very credible case that you've actually
>>> written a C compiler.
>>
>> Well, don't believe it if you don't want.
> 
> Oh I want to believe; I just can't do that which I want, without
> proper evidence.
> 
> Do you have a reference manual for your C dialect, and is it covered by
> tests? What programs and constructs are required to work in your C dialect?
> What are required to be diagnosed? What is left undefined?

So no one can claim to write a 'C' compiler unless it does everything as 
well as gcc which started in 1987, has had hordes of people working with 
it, and has had feedback from myriads of users?

I had some particular aims with my project, most of which were achieved, 
boxes ticked.

>> The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7%
>> smaller than your giant program.
> 
> That's amazingly large for an assembler. Is that stripped of debug info?

The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it was 1.5MB.

Mine is about 100KB, but it covers a subset of x86 opcodes and outputs 
only a limited number of formats.

But the size of NASM is not an issue; it's an example of modestly sized 
application which seem rare. People here claim their apps are always so 
massive and complicated that a 'toy' compiler will never work.

>> Yes, probably. But the optimisation is overrated. Do you really need
>> optimised code to test each of those 200 builds you're going to do today?
> 
> Yes, because of the principle that you should test what you ship.

Then you're being silly. You're not shipping build#139 of 200 that day, 
not even #1000 that week. You're debugging a logic bug that is nothing 
to do with optimisation.

[toc] | [prev] | [next] | [standalone]

#382068

On 2024-02-08, bart <bc@freeuk.com> wrote:
> On 07/02/2024 23:24, Kaz Kylheku wrote:
>> On 2024-02-07, bart <bc@freeuk.com> wrote:
>>> On 05/02/2024 05:58, Kaz Kylheku wrote:
>>>> On 2024-02-05, bart <bc@freeuk.com> wrote:
>>>
>>>> Writing a compiler is pretty easy, because the bar can be set very low
>>>> while still calling it a compiler.
>>>
>>>> Whole-program compilers are easier because there are fewer requirements.
>>>> You have only one kind of deliverable to produce: the executable.
>>>> You don't have to deal with linkage and produce a linkable format.
>>>
>>> David Brown suggested that they were harder than I said. You're saying
>>> they are easier.
>> 
>> I'm saying it's somewhat easier to make a compiler which produces an
>> object file than to produce a compiler that produces object files *and*
               ^^^^
>> a linker that combines them.
>
> Is there a 'than' missing above? Otherwise it's contradictory.

Other "than" that one? Hmm.

>> There is all that code you don't have to write to produce object files,
>> read them, and link them. You don't have to solve the problem of how to
>> represent unresolved references in an externalized form in a file.
> Programs that generate object files usually invoke other people's linkers.
>
> But your comments are simplistic. EXE formats can be as hard to generate 
> as OBJ files. You still have to resolve the dynamic imports into an EXE.

Generating just the EXE format is objectively less work than generating
OBJ files and linking them into that ... same EXE format, right?

> You need to either have a ready-made language designed for whole-program 
> work, or you need to devise one.
>
> Plus, if the minimal compilation unit is now all N source modules of a 
> project rather than just 1 module, then you'd better have a pretty fast 
> compiler, and some strategies for dealing with scale.

Easy; just drop language conformance, diagnostics, optimization.

>>> Well, don't believe it if you don't want.
>> 
>> Oh I want to believe; I just can't do that which I want, without
>> proper evidence.
>> 
>> Do you have a reference manual for your C dialect, and is it covered by
>> tests? What programs and constructs are required to work in your C dialect?
>> What are required to be diagnosed? What is left undefined?
>
> So no one can claim to write a 'C' compiler unless it does everything as 
> well as gcc which started in 1987, has had hordes of people working with 
> it, and has had feedback from myriads of users?

Nope; unless it is documented so that there is a box, where it says what
is in the box, and some way to tell that what's on the box is in the
box.

> I had some particular aims with my project, most of which were achieved, 
> boxes ticked.
>
>>> The NASM.EXE program is bit larger at 1.3MB for example, that's 98.7%
>>> smaller than your giant program.
>> 
>> That's amazingly large for an assembler. Is that stripped of debug info?
>
> The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it was 1.5MB.

"as" on Ubuntu 18, 32 bit.

$ size /usr/bin/i686-linux-gnu-as
   text    data     bss     dec     hex filename
 430315   12544   37836  480695   755b7 /usr/bin/i686-linux-gnu-as

Still pretty large. Always use the "size" utility, rather than raw
file size. This has 430315 bytes of code, 12544 of non-zero static data, 37836
bytes of zeroed data (not part of the executable size).

That's still large for an assembler, but at least it's not larger
than GNU Awk.

>>> Yes, probably. But the optimisation is overrated. Do you really need
>>> optimised code to test each of those 200 builds you're going to do today?
>> 
>> Yes, because of the principle that you should test what you ship.
>
> Then you're being silly. You're not shipping build#139 of 200 that day, 

If I make a certain change for build #139, and that part of the code
(function or entire source file) is not touched until build #1459 which
ships, that compiled code remains the same! So in fact, the #139 version of
that code is what build #1459 ships with. That code is being tested as part of
#140, #141, #142, ... even while some other things are changing.

You should not be doing all your development and developer testing with
unoptimized builds so that only Q&A people test optimized code before
shipping.

Every test, even of a private build, is a potential opportunity to find
something wrong with some optimized code that would end up shipping
otherwise.

Here is another reason to work with optimized code. If you have to debug
at the machine language level, optimized code is shorter and way more readable.
And it can help you understand logic bugs, because the compiler performs
logical analysis in doing optimizations. The optimized code shows you what your
calculation reduced to, and can even help you see a better way of writing the
code, like a tutor.

> not even #1000 that week. You're debugging a logic bug that is nothing 
> to do with optimisation.

Though debugging logic bugs that have nothing to do with optimization can be
somewhat impeded by optimization, it's still better to prioritize working with
the code in the intended shipping state.

You can drop to an unoptimized build when necessary.

Pretty much that only happens when

1. It is just a logic bug, but you have to resort to a debugger, and
   the optimizations are interfering with being able to see variable values.)

2. You suspect it does have to do with optimization, so you see if it
   the issue goes away in the unoptimized build.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#382084

On 08/02/2024 02:50, Kaz Kylheku wrote:
> On 2024-02-08, bart <bc@freeuk.com> wrote:

>> But your comments are simplistic. EXE formats can be as hard to generate
>> as OBJ files. You still have to resolve the dynamic imports into an EXE.
> 
> Generating just the EXE format is objectively less work than generating
> OBJ files and linking them into that ... same EXE format, right?

That depends:

* Are you generating OBJ files, or just ASM files and using a 3rd party 
assembler?

* Are you producing OBJ files and relying on a 3rd party linker, or also 
writing the linker?

* If the latter, are you using an official binary OBJ format, or 
devising your own? That latter can make it a lot simpler.

And also, what exactly do you mean by a whole-program compiler?

I don't mean a C compiler which takes N source files at the same time, 
compiles them internally, and links them internally. That's just 
wrapping up all the steps involved in independent compilation into one 
package.

>> Plus, if the minimal compilation unit is now all N source modules of a
>> project rather than just 1 module, then you'd better have a pretty fast
>> compiler, and some strategies for dealing with scale.
> 
> Easy; just drop language conformance, diagnostics, optimization.

You're sceptical about something, I'm not sure what. Maybe you're used 
to compilers taking forever to turn source into binary, so that you're 
suspicious of anything that figures out how to do it faster.

Have you considered that recompiling after a one-line change, you don't 
really the same in-depth analysis that you did 30 seconds ago?

/I/ am suspicious of compilers that produce a benchmark that completes 
in 0.0 seconds, since it is most likely shirking the task that has been set.

> "as" on Ubuntu 18, 32 bit.
> 
> $ size /usr/bin/i686-linux-gnu-as
>     text    data     bss     dec     hex filename
>   430315   12544   37836  480695   755b7 /usr/bin/i686-linux-gnu-as
> 
> Still pretty large. Always use the "size" utility, rather than raw
> file size. This has 430315 bytes of code, 12544 of non-zero static data, 37836
> bytes of zeroed data (not part of the executable size).

Raw file size is fine. The 'size' thing on my WSL shows that 'as' is 
about 700KB for text and data.

BTW the same exercise on the 1.3MB NASM.EXE shwows the code as 0.3MB, 
the rest is data. On my mcc compiler:

Compiling cc.m---------- to cc.exe
Code size:     186,647 bytes
Idata size:     86,392
Zdata size:  1,333,240
EXE size:      277,504

> That's still large for an assembler, but at least it's not larger
> than GNU Awk.

So Awk is another product that is still smaller than 1MB. Maybe there's 
more of such programs than was thought!

But can you imagine if you're a developer of such a program, and being 
told your product is a toy. Or being denied that use of a fast compiler, 
because such a compiler will not scale to something that is 100x the size.

>>>> Yes, probably. But the optimisation is overrated. Do you really need
>>>> optimised code to test each of those 200 builds you're going to do today?
>>>
>>> Yes, because of the principle that you should test what you ship.
>>
>> Then you're being silly. You're not shipping build#139 of 200 that day,
> 
> If I make a certain change for build #139, and that part of the code
> (function or entire source file) is not touched until build #1459 which
> ships, that compiled code remains the same! So in fact, the #139 version of
> that code is what build #1459 ships with. That code is being tested as part of
> #140, #141, #142, ... even while some other things are changing.
> 
> You should not be doing all your development and developer testing with
> unoptimized builds so that only Q&A people test optimized code before
> shipping.
> 
> Every test, even of a private build, is a potential opportunity to find
> something wrong with some optimized code that would end up shipping
> otherwise.

OK. This is entirely up to you. But then you can't complain when builds 
routinely take makes minutes or even hours.

On the stuff I do, a whole-program build completes in about the time it 
takes you to take your finger off the Enter key.

> Here is another reason to work with optimized code. If you have to debug
> at the machine language level, optimized code is shorter and way more readable.

I think the exact opposite is true, since optimised code can bear little 
relation to the source code. The code may even have been elided.

> And it can help you understand logic bugs, because the compiler performs
> logical analysis in doing optimizations. The optimized code shows you what your
> calculation reduced to, and can even help you see a better way of writing the
> code, like a tutor.
> 
>> not even #1000 that week. You're debugging a logic bug that is nothing
>> to do with optimisation.
> 
> Though debugging logic bugs that have nothing to do with optimization can be
> somewhat impeded by optimization, it's still better to prioritize working with
> the code in the intended shipping state.
> 
> You can drop to an unoptimized build when necessary.
> 
> Pretty much that only happens when
> 
> 1. It is just a logic bug, but you have to resort to a debugger, and
>     the optimizations are interfering with being able to see variable values.)
> 
> 2. You suspect it does have to do with optimization, so you see if it
>     the issue goes away in the unoptimized build.

My method is to do 99.99% of builds unoptimised. The program may or may 
not be in C.

If I want the finished program to be faster, then I can transpile to C 
if necessary, and invoke an optimising C compiler. Or I can just supply 
some C source to somebody and they can do what they like.

Millions of people code in scripting languages where there is no deep 
analysis or optimisation at all. And yet they manage. Behind the scenes 
there will be a fast bytecode compiler that does little other than 
generated code that corresponds 99% to the source code.

But you're saying that as soon as you step over the line into AOT 
compiled code, nothing less than full -O3 with a million other options 
will do FOR EVERY SINGLE CCOMPILATION, even if the only change is to add 
an extra space to a string literal because some message annoyingly 
doens't line up?

OKay....

[toc] | [prev] | [next] | [standalone]

#382085

On Thu, 8 Feb 2024 02:50:08 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-08, bart <bc@freeuk.com> wrote:
> > On 07/02/2024 23:24, Kaz Kylheku wrote:  
> >> On 2024-02-07, bart <bc@freeuk.com> wrote:  
> >>> On 05/02/2024 05:58, Kaz Kylheku wrote:  
> >>>> On 2024-02-05, bart <bc@freeuk.com> wrote:  
> >>>  
> >>>> Writing a compiler is pretty easy, because the bar can be set
> >>>> very low while still calling it a compiler.  
> >>>  
> >>>> Whole-program compilers are easier because there are fewer
> >>>> requirements. You have only one kind of deliverable to produce:
> >>>> the executable. You don't have to deal with linkage and produce
> >>>> a linkable format.  
> >>>
> >>> David Brown suggested that they were harder than I said. You're
> >>> saying they are easier.  
> >> 
> >> I'm saying it's somewhat easier to make a compiler which produces
> >> an object file than to produce a compiler that produces object
> >> files *and*  
>                ^^^^
> >> a linker that combines them.  
> >
> > Is there a 'than' missing above? Otherwise it's contradictory.  
> 
> Other "than" that one? Hmm.
> 
> >> There is all that code you don't have to write to produce object
> >> files, read them, and link them. You don't have to solve the
> >> problem of how to represent unresolved references in an
> >> externalized form in a file.  
> > Programs that generate object files usually invoke other people's
> > linkers.
> >
> > But your comments are simplistic. EXE formats can be as hard to
> > generate as OBJ files. You still have to resolve the dynamic
> > imports into an EXE.  
> 
> Generating just the EXE format is objectively less work than
> generating OBJ files and linking them into that ... same EXE format,
> right?
> 
> > You need to either have a ready-made language designed for
> > whole-program work, or you need to devise one.
> >
> > Plus, if the minimal compilation unit is now all N source modules
> > of a project rather than just 1 module, then you'd better have a
> > pretty fast compiler, and some strategies for dealing with scale.  
> 
> Easy; just drop language conformance, diagnostics, optimization.
> 
> >>> Well, don't believe it if you don't want.  
> >> 
> >> Oh I want to believe; I just can't do that which I want, without
> >> proper evidence.
> >> 
> >> Do you have a reference manual for your C dialect, and is it
> >> covered by tests? What programs and constructs are required to
> >> work in your C dialect? What are required to be diagnosed? What is
> >> left undefined?  
> >
> > So no one can claim to write a 'C' compiler unless it does
> > everything as well as gcc which started in 1987, has had hordes of
> > people working with it, and has had feedback from myriads of users?
> >  
> 
> Nope; unless it is documented so that there is a box, where it says
> what is in the box, and some way to tell that what's on the box is in
> the box.
> 
> > I had some particular aims with my project, most of which were
> > achieved, boxes ticked.
> >  
> >>> The NASM.EXE program is bit larger at 1.3MB for example, that's
> >>> 98.7% smaller than your giant program.  
> >> 
> >> That's amazingly large for an assembler. Is that stripped of debug
> >> info?  
> >
> > The as.exe assembler for gcc/TDM 10.3 is 1.8MB. For mingw 13.2 it
> > was 1.5MB.  
> 
> "as" on Ubuntu 18, 32 bit.
> 
> $ size /usr/bin/i686-linux-gnu-as
>    text    data     bss     dec     hex filename
>  430315   12544   37836  480695   755b7 /usr/bin/i686-linux-gnu-as
> 
> Still pretty large. Always use the "size" utility, rather than raw
> file size. This has 430315 bytes of code, 12544 of non-zero static
> data, 37836 bytes of zeroed data (not part of the executable size).
> 

$ /mingw32/bin/as.exe --version
GNU assembler (GNU Binutils) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i686-w64-mingw32'.

$ size /mingw32/bin/as.exe
   text    data     bss     dec     hex filename
2941952   10392   43416 2995760  2db630
C:/bin/msys64a/mingw32/bin/as.exe


$ /mingw64/bin/as.exe --version
GNU assembler (GNU Binutils) 2.39
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.

$ size /mingw64/bin/as.exe
   text    data     bss     dec     hex filename
2966156   14776   45216 3026148  2e2ce4
C:/bin/msys64a/mingw64/bin/as.exe



> That's still large for an assembler, but at least it's not larger
> than GNU Awk.
>

$ awk --version
GNU Awk 5.1.1, API: 3.1 (GNU MPFR 4.1.0-p13, GNU MP 6.2.1)
Copyright (C) 1989, 1991-2021 Free Software Foundation.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.


$ size /usr/bin/awk.exe
   text    data     bss     dec     hex filename
 619497   15884   23104  658485   a0c35 C:/bin/msys64a/usr/bin/awk.exe


Looks like on msys2 GNU as is much larger than GNU awk.

[toc] | [prev] | [next] | [standalone]

#382131

On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> $ /mingw32/bin/as.exe --version
> GNU assembler (GNU Binutils) 2.40
> Copyright (C) 2023 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of the GNU General Public License version 3 or later.
> This program has absolutely no warranty.
> This assembler was configured for a target of `i686-w64-mingw32'.
>
> $ size /mingw32/bin/as.exe
>    text    data     bss     dec     hex filename
> 2941952   10392   43416 2995760  2db630
> C:/bin/msys64a/mingw32/bin/as.exe

LOL, even a 400 kilobyte assembler is bat shit crazy.

Can you imagine working with that on a 512 Kb IBM PC?

GNU as probably doesn't have half the features of, say, Randy Hyde's
LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).

Might that be statically linking numerous libraries, like libbfd and
whatnot? Possibly it supports unnecessary object formats that the MinGW
user will never use.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#382134

On Thu, 8 Feb 2024 17:48:38 -0000 (UTC)
Kaz Kylheku <433-929-6894@kylheku.com> wrote:

> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> > $ /mingw32/bin/as.exe --version
> > GNU assembler (GNU Binutils) 2.40
> > Copyright (C) 2023 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the
> > terms of the GNU General Public License version 3 or later.
> > This program has absolutely no warranty.
> > This assembler was configured for a target of `i686-w64-mingw32'.
> >
> > $ size /mingw32/bin/as.exe
> >    text    data     bss     dec     hex filename
> > 2941952   10392   43416 2995760  2db630
> > C:/bin/msys64a/mingw32/bin/as.exe  
> 
> LOL, even a 400 kilobyte assembler is bat shit crazy.
> 
> Can you imagine working with that on a 512 Kb IBM PC?
> 
> GNU as probably doesn't have half the features of, say, Randy Hyde's
> LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).
> 
> Might that be statically linking numerous libraries, like libbfd and
> whatnot? Possibly it supports unnecessary object formats that the
> MinGW user will never use.
> 

I am pretty sure that it is because of static libraries (which by
itself is a reasonable choice on platform like msys2) but don't want to
guess which library is in fault.

[toc] | [prev] | [next] | [standalone]

#382137

On 08/02/2024 17:48, Kaz Kylheku wrote:
> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>> $ /mingw32/bin/as.exe --version
>> GNU assembler (GNU Binutils) 2.40
>> Copyright (C) 2023 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms
>> of the GNU General Public License version 3 or later.
>> This program has absolutely no warranty.
>> This assembler was configured for a target of `i686-w64-mingw32'.
>>
>> $ size /mingw32/bin/as.exe
>>     text    data     bss     dec     hex filename
>> 2941952   10392   43416 2995760  2db630
>> C:/bin/msys64a/mingw32/bin/as.exe
> 
> LOL, even a 400 kilobyte assembler is bat shit crazy.

That's how I feel about a lot of programs.

You think it's crazy because you understand the task that is to be done 
and know that 4MB or 40MB would be over the top.

The code part section of my own x64 assembler, if I strip out exraneous 
things like the disassembler, is 70KB. That includes a .EXE target. If I 
take that out (so only .OBJ target) then it's 61KB, of which 21KB is the 
standard library of the language anyway.

So code just for the assembler is about 40KB, which is for a subset of x64.

> Can you imagine working with that on a 512 Kb IBM PC?

Can you imagine working with any of the compilers that are highly 
regarded here on such a machine? And with floppy disks?

[toc] | [prev] | [next] | [standalone]

#382139

On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
[...]
> LOL, even a 400 kilobyte assembler is bat shit crazy.
> 
> Can you imagine working with that on a 512 Kb IBM PC?

This assembler was pretty small... ;^D

https://youtu.be/bCSDkjhVM2A



> 
> GNU as probably doesn't have half the features of, say, Randy Hyde's
> LISA for APPLE II. (Lazer Systems Interactive Symbolic Assembler).
> 
> Might that be statically linking numerous libraries, like libbfd and
> whatnot? Possibly it supports unnecessary object formats that the MinGW
> user will never use.
> 

[toc] | [prev] | [next] | [standalone]

#382140

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
> [...]
>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>> Can you imagine working with that on a 512 Kb IBM PC?
>
> This assembler was pretty small... ;^D
>
> https://youtu.be/bCSDkjhVM2A

Please stop doing this.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#382141

In article <87il2yfvmp.fsf@nosuchdomain.example.com>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>> [...]
>>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>>> Can you imagine working with that on a 512 Kb IBM PC?
>>
>> This assembler was pretty small... ;^D
>>
>> https://youtu.be/bCSDkjhVM2A
>
>Please keep doing this.

"Introduction to Assembly Language Programming on the Apple IIgs - Lesson 1"

-- 
"He is exactly as they taught in KGB school: an egoist, a liar, but talented - he
knows the mind of the wrestling-loving, under-educated, authoritarian-admiring
white male populous."
    - Malcolm Nance, p59. -

[toc] | [prev] | [next] | [standalone]

#382142

On 2/8/2024 2:29 PM, Kenny McCormack wrote:
> In article <87il2yfvmp.fsf@nosuchdomain.example.com>,
> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> On 2/8/2024 9:48 AM, Kaz Kylheku wrote:
>>>> On 2024-02-08, Michael S <already5chosen@yahoo.com> wrote:
>>> [...]
>>>> LOL, even a 400 kilobyte assembler is bat shit crazy.
>>>> Can you imagine working with that on a 512 Kb IBM PC?
>>>
>>> This assembler was pretty small... ;^D
>>>
>>> https://youtu.be/bCSDkjhVM2A
>>
>> Please keep doing this.
> 
> "Introduction to Assembly Language Programming on the Apple IIgs - Lesson 1"
> 

Yup. I forgot to put in the title. Sorry everybody. ;^o

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

Back to top | Article view | comp.lang.c

csiph-web