On 12/01/2024 16:50, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 13:40, David Brown wrote:
>>> On 12/01/2024 00:20, bart wrote:
>>
>> But with 'as', it just sits there. I wonder what it's waiting for; for
>> me to type in ASM code live from the terminal?
>
> It does that so you can pipe the assembler source code in to the
> assembler.
>
> $ cat file.s | as
>
> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o

Using ">" on binary content? That seems off.

But I've been playing with 'as', and it has issues. I'm not surprised
you have to use it via pipes, because used conventionally, it stinks.

If you do this:

as hello.s

What might someone expect the output to be? Probably not 'a.out', more
likely hello.o. Why /isn't/ it just hello.o?

Here a.out will be an object file; on Linux, it will sometimes it will
be an executable. No possibility of confusion at all.

What do you expect it to do here:

as one.s two.s

I expected two object files; I got one composite one. (Just as well if
they would both be called a.out!)

> or, if you want, you can type in the assembler source directly.
>
> Or you can save it in a file and supply the file argument to the command.
>
> None of which your stuff supports, which makes it useless to me.

I understand. Because writing:

$ command inputfile

is too complicated. Certainly it is if you have to do:

$ command inputfile -o outputfile

where outputfile is just putfile with the extension changed.

I been running assemblers since the late 70s; I have never seen one
behave as weirdly as 'as'.

I thought /my/ 'aa' product was unconventional (in normally turning ASM
sources directly to executables), but 'as' has it beat.

On 12.01.2024 18:09, bart wrote:
> On 12/01/2024 16:34, David Brown wrote:
>>>
>>> It looks like 'make' is competing with 'bash' then!

Why don't you just read about those two tools and learn, instead
of repeatedly spouting such stupid statements of ignorance.

>>
>> I have no idea why you think that - except perhaps because you still
>> have no concept of what "make" is and what it does, and think it is
>> just a script with a complicated syntax.
>
> So, what the hell is it then? What makes it so special compared with any
> other scripting language?

Meanwhile you seem to have read a bit about it, as you show below.

It's a _simple_ tool - not complex, as you've previously posted -
where you can define dependencies of entities, and define commands
that create the targets if entities that are required by the target
had changed. Its basic syntax and also its logic is simple, and it
does the specific task very well, and it is not bound to a specific
language, or to languages generally, but also to any generation
processes.

>
> All I can see is that it can create dependency graphs between files -
> which have to be determined from info that you provide in the file, it's
> not that clever - and can use that to avoid recompilation etc of a file
> unless its dependencies have changed.

Or rather, unless the entities (that are dependent on) have changed.

And this is a crucial feature; for professional non-trivial projects.

>
> That is something I've never needed done automatically in my own work (I
> do it manually as I will know my projects intimately when I'm working
> with them).

Yes, we know. You've repeatedly shown that you are actually doing
small one-man-shows in projects that I can only call toy-projects.

Professional projects have a different situation in many respects.
(I don't go into detail here, since you're anyway only interested
in your local comfort zone.)

>
> For production builds, it doesn't matter if everything is compiled.

For a production build we extract a committed release into an own
file system branch and build all, first for the tests, then to pack
the source (optionally), and then the complete runtime environment.

But we're doing professional software products. And the production
build comes _at the end_.

Before that we need efficient mechanisms to create consistent systems
and configurations, and to avoid unnecessary compiles. And the 'make'
process does exactly that.

> [...]
>
> Clearly your idea of 'better' is to be vastly more complicated.

The Makefile mechanism is extremely important and yet very simple.

Clearly your imputations are based on ignorance.

Janis

> [...]

On 12.01.2024 18:40, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 12/01/2024 17:12, bart wrote:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>
>>> It looks like 'make' is competing with 'bash' then!
>>
>> I have no idea why you think that - except perhaps because you still
>> have no concept of what "make" is and what it does, and think it is just
>> a script with a complicated syntax.
>
> I can't tell if he's just trolling, or if he really believes what
> he writes.

My suspicion had been that he's maybe no person but an AI bot.
It's just too pathological what he writes and how he behaves to be
sure that he's a human poster. - On the other hand, this is Usenet,
and everything is possible.

Janis

On 12.01.2024 18:59, bart wrote:
> On 12/01/2024 16:50, Scott Lurndal wrote:
>>
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Using ">" on binary content?

Of course.

> That seems off.

Why?

Janis

On 12/01/2024 18:10, Janis Papanagnou wrote:
> On 12.01.2024 18:59, bart wrote:
>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>
>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>
>> Using ">" on binary content?
>
> Of course.
>
>> That seems off.
>
> Why?

Because when you see ">" on a command line, it means redirecting output
that would normally be shown as text on a console or terminal.

But you rarely see pure binary being displayed like that on a text display.

Also, in the absence of ">", 'as' wouldn't write its output to the
screen (only to some badly named file), so it is off from that
perspective too.

However I'm obviously just a bot, so what do I know.

bart <bc@freeuk.com> writes:
>On 12/01/2024 16:50, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>>>
>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>> me to type in ASM code live from the terminal?
>>
>> It does that so you can pipe the assembler source code in to the
>> assembler.
>>
>> $ cat file.s | as
>>
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
>Using ">" on binary content? That seems off.

Unix files are untyped sequences of bytes.

(e.g. the 'b' flag to the fopen stdio library routine is ignored on unix).

That windows fucks around with line endings and uses CRLF instead of the
more efficient LF is screwed up.

>

>If you do this:
>
> as hello.s
>
>What might someone expect the output to be?

What the FM documents. RTFM.

bart <bc@freeuk.com> writes:
>On 12/01/2024 18:10, Janis Papanagnou wrote:
>> On 12.01.2024 18:59, bart wrote:
>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>
>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>
>>> Using ">" on binary content?
>>
>> Of course.
>>
>>> That seems off.
>>
>> Why?
>
>Because when you see ">" on a command line, it means redirecting output
>that would normally be shown as text on a console or terminal.

No, it doesn't mean that at all. It never has meant that.

'> name' tells the shell to open 'name' on stdout before executing 'as'.

the 'as' command takes text as input and produces binary output (ELF or *Cough*COFF).

bart <bc@freeuk.com> writes:
> On 12/01/2024 16:50, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 13:40, David Brown wrote:
>>>> On 12/01/2024 00:20, bart wrote:
>>>
>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>> me to type in ASM code live from the terminal?
>> It does that so you can pipe the assembler source code in to the
>> assembler.
>> $ cat file.s | as
>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Using ">" on binary content? That seems off.

There's no fundamental reason you can't send binary data through a pipe
or write it to stdout and redirect it to a file. It could cause
problems if you accidentally write binary data to a terminal (it might
put your terminal into an odd state).

As it happens, GNU "as" doesn't and can't write its object file output
to a pipe or terminal, so Scott's hypothetical pipeline wouldn't
actually work. The as command doesn't write its output sequentially.
If you force it to write to stdout, it fails with an "Illegal seek"
error.

The "as" command writes its object file output to "a.out" (assembler
output) by default, or to whatever file you specify with "-o filename".
That's about the simplest interface you could have.

> But I've been playing with 'as', and it has issues. I'm not surprised
> you have to use it via pipes, because used conventionally, it stinks.
>
> If you do this:
>
> as hello.s
>
> What might someone expect the output to be? Probably not 'a.out', more
> likely hello.o. Why /isn't/ it just hello.o?

Partly historical inertia, and partly because "as" can't always know
what the output file should be, for example if its input isn't a file.

Yes, it *could* have been designed so it writes its output to foo.o if
it knows it's reading from foo.s, or to a.out (or to stdout?) otherwise.
That might have been a bit more convenient in some cases. But the
existing interface supports all reasonable uses if you know how to use
it.

I rarely invoke "as" directly myself, so 99% of the time I don't *care*
how it works. I didn't know it reads from stdin by default until you
complained about it.

[...]

--
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 */

On 12/01/2024 19:15, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>> On 12/01/2024 00:20, bart wrote:
>>>>
>>>> But with 'as', it just sits there. I wonder what it's waiting for; for
>>>> me to type in ASM code live from the terminal?
>>>
>>> It does that so you can pipe the assembler source code in to the
>>> assembler.
>>>
>>> $ cat file.s | as
>>>
>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>
>> Using ">" on binary content? That seems off.
>
> Unix files are untyped sequences of bytes.
>
> (e.g. the 'b' flag to the fopen stdio library routine is ignored on unix).
>
> That windows fucks around with line endings and uses CRLF instead of the
> more efficient LF is screwed up.
>
>>
>
>> If you do this:
>>
>> as hello.s
>>
>> What might someone expect the output to be?
>
> What the FM documents. RTFM.

I see. So forget just having intuitive behaviour. Or even behaviour that
is compatible with related tools, so that:

gcc -c file1.c produces file1.o
gcc -c file1.c file2.c produces file1.o file2.o

but:

as file1.s produces a.out
as file1.s file2.s produces a.out

Oh, I see the problem: I haven't read the fucking manual. Except that if
I do read it, the behaviour will still be around the bend.

You guys all deserve medals for being so tolerant.

On 12/01/2024 19:18, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 12/01/2024 18:10, Janis Papanagnou wrote:
>>> On 12.01.2024 18:59, bart wrote:
>>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>>
>>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>>
>>>> Using ">" on binary content?
>>>
>>> Of course.
>>>
>>>> That seems off.
>>>
>>> Why?
>>
>> Because when you see ">" on a command line, it means redirecting output
>> that would normally be shown as text on a console or terminal.
>
> No, it doesn't mean that at all. It never has meant that.
>
> '> name' tells the shell to open 'name' on stdout before executing 'as'.

And without '> name', where does stuff sent to stdout end up?

On 2024-01-12, Scott Lurndal <scott@slp53.sl.home> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>On 12/01/2024 00:20, bart wrote:
>
>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are as
>>> bad: you invoke them, and they just apparently hang. Then you realise
>>> they're waiting for input. Would it kill somebody to get them to display
>>> a prompt?
>>
>>Are you sure you are not exaggerating just a /tiny/ bit?
>
> Clearly, Bart is trolling.
>
> And clearly, he doesn't understand the basic unix philosophy
> of combining commands in pipeline, where "displaying a prompt"
> would be silly.

C:\Users\kazk>findstr d
.... "hangs" ...

Even Microsoft somehow got the memo that at least text filters
shouldn't spew chatter.

I can't think of any Unix programs other than "ed" that take commands on
standard input, but don't print a prompt by default.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/12/2024 8:12 AM, bart wrote:
> On 12/01/2024 13:40, David Brown wrote:
>> On 12/01/2024 00:20, bart wrote:
>
>>> Why, what hairy stuff are you doing that requires a language as
>>> complex as 'make' and a shell environment as capable as 'bash'? It
>>> sounds more like, you just use the capability because it's there. And
>>> then complain when Windows doesn't have that.
>>>
>>
>> People use good tools when good tools are available - they don't go
>> out of their way to use something inferior.  Why is that a surprise?
>> If you want to cut an orange, do you go out to the garage and find a
>> rusty old knife that is nonetheless useable for cutting a bit of fruit
>> - or do you use the shiny new titanium kitchen knife that is right in
>> front of you?
>>
>> I used "make" on DOS and Windows for about 15 years before I started
>> using Linux as a development system (rather than just for servers and
>> for fun).  Every Windows system I have ever owned personally or used
>> at work has had "make" - because "make" has been the standard for
>> quality development tools since early DOS days.  The version I used
>> first on Windows came with Turbo Pascal - Microsoft's tools came with
>> their own slight variation of make called "nmake".
>>
>> If your build uses only a couple of commands, make doesn't add much
>> compared to a script - but it doesn't cost much either.  And you have
>> the convenience that a lot of editors have shortcut keys for doing a
>> "build", so something like ctrl-B will run "make" in the current
>> directory without needing to set up any specific tool shortcuts.
>> That's convenient.
>>
>> And unlike a language/compiler specific build system like you have
>> within your "mm" or "mcc" tools (if I am not mistaken), "make" will
>> work for anything you can run by commands.  My makefiles might not
>> just build executables from C files,
>
> If you isolate that part of it, then it's what I either build-in to the
> language + compiler (for M), or list in a simple text file (for C).
>
> In either case I will have a project file using a similar list for my
> basic IDE that I use for everyday development. But this part is not
> needed when somebody else needs to build my project.
>
> For a C project consisting of three files (one of Chris's), my IDE looks
> like this:
>
>   https://github.com/sal55/langs/blob/master/ff.png
>
> It probably looked about the same in 1984. The project file for that is
> this:
>
>   run cipher c.c output -e
>
>   module cipher.c
>   module sha2.c
>   module hmac.c
>   file sha2.h
>   file hmac.h
>
> The 'run' lines show what happens when I type 'R' in the IDE.
>
> This project is small enough that it can be built by a third party with
> a one-line instruction. Otherwise it would need an @ file of a few lines
> listing the .c files.
>
> Because this project is tidily structured with paired .c/.h files, my
> older BCC compiler could figure out how to build it from just the lead
> module:
>
>   c:\c>bcc -auto cipher
>      1 Compiling cipher.c     to cipher.asm       (Pass 1)
>   *  2 Compiling hmac.c       to hmac.asm         (Pass 2)
>   *  3 Compiling sha2.c       to sha2.asm         (Pass 2)
>   Assembling to cipher.exe
[...]

Fwiw, for some context here is the original thread where Bart helped me
out wrt getting it to compile on many C compilers:

https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ

Thanks again Bart. :^)

scott@slp53.sl.home (Scott Lurndal) writes:
> bart <bc@freeuk.com> writes:
[...]
>>Because when you see ">" on a command line, it means redirecting output
>>that would normally be shown as text on a console or terminal.
>
> No, it doesn't mean that at all. It never has meant that.

Well, maybe. If you drop the "as text", it's fairly accurate, for
certain values of "normally".

If you run "command" at a shell prompt, its stdout goes to the terminal
in which the shell is running. Normally that output should be text. If
it's binary, it's likely to mess up your terminal settings as it
contains byte sequences that look like terminal commands. (If "command"
deliberately outputs terminal commands, that could be useful.)

If you run "command > filename", its stdout goes to the named file.

> '> name' tells the shell to open 'name' on stdout before executing 'as'.
>
> the 'as' command takes text as input and produces binary output (ELF or *Cough*COFF).

And as I mentioned elsethread, at least GNU "as" can only write its
binary output to a seekable file. Apparently it doesn't write it
sequentially.

--
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 */

On 12/01/2024 18:02, Janis Papanagnou wrote:
> On 12.01.2024 18:09, bart wrote:
>> On 12/01/2024 16:34, David Brown wrote:
>>>>
>>>> It looks like 'make' is competing with 'bash' then!
>
> Why don't you just read about those two tools and learn, instead
> of repeatedly spouting such stupid statements of ignorance.

Because I've repeatedly said I don't need them. Why can't you accept that?

How about YOU learn how to build software without those tools?

> It's a _simple_ tool - not complex, as you've previously posted -
> where you can define dependencies of entities, and define commands
> that create the targets if entities that are required by the target
> had changed. Its basic syntax and also its logic is simple,

> And this is a crucial feature; for professional non-trivial projects.

Come on then, tell me how big your projects are. Are they bigger than
Scott Lurndal's 10Mloc example? (Which seems to be mostly Python source
code.)

>>
>> That is something I've never needed done automatically in my own work (I
>> do it manually as I will know my projects intimately when I'm working
>> with them).
>
> Yes, we know. You've repeatedly shown that you are actually doing
> small one-man-shows in projects that I can only call toy-projects.

This is incredibly patronising.

What is wrong with one-man projects?

What is wrong with writing non-professional software? Is that the same
as non-commercial?

Where is the line between a toy project and a non-toy project? Is it
related to how lines or how many modules an application might have, or
the size of the final binaries?

Is it to do with the number of end-users?

Is lua.exe a toy application? (Since it only has 33 modules and is a
300KB program.)

> Professional projects have a different situation in many respects.
> (I don't go into detail here, since you're anyway only interested
> in your local comfort zone.)

No, don't. I assume you've got some hugely complicated app with a
million moving parts. It's so big that nobody knows what's what. Your
compilers are so slow that you HAVE to use dependencies to avoid
spending 90% of the day twiddling your thumbs.

That's a million miles from the stuff I do, yet you still insist /I/
should be using all the same complicated tools you do.

Actually I don't care what the hell you do. I care when it impacts me
when I sometimes have to build something, WHICH IS RARELY MORE THAN
DOZENS OF MODULES OR 100/200K LINES OF CODE, so obviousy trivial
compared with your stuff, and yet I have to go through some torturous
process to get it done.

Let me tell about my own tools:

* My main compiler (not for C), is a whole-program compiler (so
interdepency graphs are pointless).

* It can whizz through sourcecode at 500,000 lines per second at least

* It can generate executable code at 5MB per second at least

This means that for a project that is about 0.5Mloc, or produces a 5MB
executable, recompiling everything might take ONE SECOND.

(And that is with the cheapest PC in the shop and with a non-optimised
compiler.)

Presumably YOUR apps are massively bigger and more complex than that.
But most stuff /I/ want write, or build of other people's, will be much
smaller.

This is why I consider make and friends pointless at this end of the scale.

>>
>> For production builds, it doesn't matter if everything is compiled.
>
> For a production build we extract a committed release into an own
> file system branch and build all, first for the tests, then to pack
> the source (optionally), and then the complete runtime environment.

> But we're doing professional software products. And the production
> build comes _at the end_.

> Before that we need efficient mechanisms to create consistent systems
> and configurations, and to avoid unnecessary compiles. And the 'make'
> process does exactly that.

Well, /I/ don't need that. I used to write commercial software in the
90s. I really never had some problems.

Half the line count (then about 150Kloc in all) was in scripting code.
That could be modified and tested /in the middle of a running application/.

I could send (by email) a script module to a customer and they could run
that without restarting their session.

Others could use my scripting language to create their own OEM add-on
products, without needing to rebuild the main application.

Yes, there was an install and configuration process, done via a GUI.

So, now tell me where the hell 'makefiles' would fit into that scenario.

Just accept that some of this stuff is out of /your/ comfort zone.

I write all my own tools, including a private C compiler. (I use it to
help with translating bindings from C headers, or to build DLLs of
libraries that exist as C source code, when the build info doesn't make
it in impossible.)

If I needed a tool like 'make', I would have created one.

Instead I developed fast, whole-program compilers and scripting languages.

> Clearly your imputations are based on ignorance.

Yeah. I could say the same thing. But usually I try and stay polite and
argue only against ideas and not people.

Have a good day.

bart <bc@freeuk.com> writes:
> On 12/01/2024 18:02, Janis Papanagnou wrote:
>> On 12.01.2024 18:09, bart wrote:
>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>
>>>>> It looks like 'make' is competing with 'bash' then!
>> Why don't you just read about those two tools and learn, instead
>> of repeatedly spouting such stupid statements of ignorance.
>
> Because I've repeatedly said I don't need them. Why can't you accept that?

There are many tools I don't need. I don't spend my days complaining
that they don't work the way I think they should.

> How about YOU learn how to build software without those tools?

Why?

Or, more to the point: No.

--
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 */

On 2024-01-12, bart <bc@freeuk.com> wrote:
>> but also build documentation (doxygen, LaTeX,
>> pandoc, graphviz, etc.), run tests, run "clean", build release zip
>> files, download to a target board via a debugger, and all sorts of other
>> bits and pieces according to the needs of the project.  One makefile
>> beats a dozen scripts.
>
> It looks like 'make' is competing with 'bash' then!

Make recipes are actually lines of shell code executed by the shell;
make does not reimplement a redundant command interpretation.(*)

You can use the SHELL variable to specify an alternative interpreter
for the make recipe lines.

---

* GNU Make contains logic for recognizing recipe lines that are
trivial commands, and eliding the use of the shell for those. So that is
to say that some simple command like "cc this.c -o this.o -c" is handled
via fork and exec directly. It must be the case that if SHELL is used
to specify an alternative interpreter, that logic is suppressed.

>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are
>>> as bad: you invoke them, and they just apparently hang. Then you
>>> realise they're waiting for input. Would it kill somebody to get them
>>> to display a prompt?
>>
>> Are you sure you are not exaggerating just a /tiny/ bit?
>
> I mainly remember the times when they do hang.

DOS/Windows stuff hangs also:

C:\Users\kazk>findstr foo
.... "hang" ...

Even Microsoft clued in to the idea that a text filter shouldn't
spew extraneous diagnostics by default.

> But with 'as', it just sits there. I wonder what it's waiting for; for
> me to type in ASM code live from the terminal? (If 'as' is designed for
> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
> it generating discrete, temporary .s files.)

gcc -pipe works in pipe mode.

The "as" command is intended for compiler use; not only is it not
an interactive assembler, it doesn't even have particularly good
diagnostics for batch use. You have to know what you're doing.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-12, bart <bc@freeuk.com> wrote:
> On 12/01/2024 18:02, Janis Papanagnou wrote:
>> On 12.01.2024 18:09, bart wrote:
>>> On 12/01/2024 16:34, David Brown wrote:
>>>>>
>>>>> It looks like 'make' is competing with 'bash' then!
>>
>> Why don't you just read about those two tools and learn, instead
>> of repeatedly spouting such stupid statements of ignorance.
>
> Because I've repeatedly said I don't need them. Why can't you accept that?

You do need make, if you're on a Unix-like system and you want to make
"hello" out of "hello.c" with a command that consists of only two words.

This requirement was articulated by you.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>bart <bc@freeuk.com> writes:
>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>> On 12/01/2024 00:20, bart wrote:
>>>>
>>>> But with 'as' it just sits there. I wonder what it's waiting for; for
>>>> me to type in ASM code live from the terminal?
>>> It does that so you can pipe the assembler source code in to the
>>> assembler.
>>> $ cat file.s | as
>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o

Yes, I used this as an example pipeline. I don't recall
if the original as(1) wrote to stdout or always just to
a.out.

>> What might someone expect the output to be? Probably not 'a.out', more
>> likely hello.o. Why /isn't/ it just hello.o?
>
>Partly historical inertia, and partly because "as" can't always know
>what the output file should be, for example if its input isn't a file.

Yup. a.out is the historical inertia.

bart <bc@freeuk.com> writes:
>On 12/01/2024 19:18, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 12/01/2024 18:10, Janis Papanagnou wrote:
>>>> On 12.01.2024 18:59, bart wrote:
>>>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>>>>
>>>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>>>>>
>>>>> Using ">" on binary content?
>>>>
>>>> Of course.
>>>>
>>>>> That seems off.
>>>>
>>>> Why?
>>>
>>> Because when you see ">" on a command line, it means redirecting output
>>> that would normally be shown as text on a console or terminal.
>>
>> No, it doesn't mean that at all. It never has meant that.
>>
>> '> name' tells the shell to open 'name' on stdout before executing 'as'.
>
>And without '> name', where does stuff sent to stdout end up?
>

Wherever the shell points stdout to before executing the program.
Might be a terminal, might be a pipe, might be a fifo, might
be a file, might be a network stream (via netcat or via shell
support for TCP connections), might be a printer.

bart <bc@freeuk.com> writes:
>On 12/01/2024 18:02, Janis Papanagnou wrote:

>
>> And this is a crucial feature; for professional non-trivial projects.
>
>Come on then, tell me how big your projects are. Are they bigger than
>Scott Lurndal's 10Mloc example? (Which seems to be mostly Python source
>code.)

The example shown had 8 million lines of C and C++ code. Less
than 10% was python.

Granted, a significant fraction of that is generated from yaml descriptions
of memory mapped registers, yet it is still compiled by the C and C++ compilers.

On 1/11/2024 2:42 AM, David Brown wrote:
> On 11/01/2024 04:10, Chris M. Thomasson wrote:
>> On 1/10/2024 2:10 AM, David Brown wrote:
>>> On 10/01/2024 08:40, Chris M. Thomasson wrote:
>>>> On 1/9/2024 9:28 PM, Kaz Kylheku wrote:
>>>>> On 2024-01-10, tTh <tth@none.invalid> wrote:
>>>>>> On 1/10/24 01:40, Bart wrote:
>>>>>>> An easy compiler is one where you just do:
>>>>>>>
>>>>>>>      gcc prog
>>>>>>>
>>>>>>> and not, at the very least:
>>>>>>>
>>>>>>>      gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>>>>
>>>>>>> Meanwhile I routinely test C programs on half a dozen compilers.
>>>>>>> I can't
>>>>>>> be bothered with all this crap.
>>>>>>
>>>>>>      So do as all of us do : put this crap in a Makefile or
>>>>>>      a shell script, and forget about it.
>>>>>
>>>>> Please don't get Bart started on makefiles!
>>>>>
>>>>
>>>> Don't get me started about freaking out for some minutes when I
>>>> failed to use a god damn tab! My makefile would not work. God damn
>>>> it! Ahhhh, that was around 20 years ago.
>>>
>>> The author of "make" described the distinction between tabs and
>>> spaces to be his worst mistake ever - but use of the tool took off
>>> too quickly for him to change it.
>>
>> Well, shit happens! lol. Jesting here. ;^)
>>
>>
>>> The difference between Bart and everyone else is that when other
>>> people make a tab mistake, they learn from it - and even 20 years on,
>>> you still remember.
>>
>> Oh my I sure do remember it, David! It managed to ingrain itself
>> firmly into my mind. I was getting a bit pissed saying why the f**k
>> wont this god damn makefile work!!!! GRRRRRR! I can remember it
>> clearly. Fwiw, I just got dropped off at my house from a party, and
>> decided to create a program that generated some makefiles for my
>> AppCore project at the time, don't ask why. I might of been a bit
>> boooozzyy. Yikes!
>>
>>
>>> Bart seems to forget things seconds after someone tells him how to
>>> use any program that he has not written himself.  (It takes him a
>>> little longer to forget how his own programs and languages work.)
>>>
>>
>> No shit? Bard helped me with some of my C code before. He is a nice guy.
>>
>
> I'm sure Bart /is/ a nice guy.  And he is a smart guy.  But he has some
> deep-rooted and obsessive hatreds and prejudices that have blocked all
> sense of logic, rationality or factual considerations in regard to some
> topics.  His fanaticism against C, gcc, development tools and *nix make
> him blind, incapable of understanding other posts, information and
> opinions, and unable to think straight or make a coherent argument.  He
> sees everything on these topics as black or white, for him or against
> him, and warps everything other people say to fit that mould.
>
> As long as none of his triggers are activated, we get along fine.  I'm
> sure if I met him in person, we could spent a pleasant time together
> discussing the pros and cons of different 80's and 90's home computers,
> why the modern Doctor Who will never live up to the originals, how
> pointless and overly commercial football has become, and lots of other
> topics.  We could probably even chat about politics and religion without
> conflict.  I'd /like/ to be able to talk to him in a comfortable and
> friendly manner about C, development tools, OS's, and the rest, but I
> fear it is not likely to happen.
>
>

Agreed! I bet you two would have a very kind and nice time reminiscing
about old compilers and interesting times when you were programming hard
on a hard problems. I wish I could be a fly on the wall for that live
correspondence. :^)

On 1/12/2024 1:31 PM, Kaz Kylheku wrote:
> On 2024-01-12, bart <bc@freeuk.com> wrote:
>>> but also build documentation (doxygen, LaTeX,
>>> pandoc, graphviz, etc.), run tests, run "clean", build release zip
>>> files, download to a target board via a debugger, and all sorts of other
>>> bits and pieces according to the needs of the project.  One makefile
>>> beats a dozen scripts.
>>
>> It looks like 'make' is competing with 'bash' then!
>
> Make recipes are actually lines of shell code executed by the shell;
> make does not reimplement a redundant command interpretation.(*)
>
> You can use the SHELL variable to specify an alternative interpreter
> for the make recipe lines.
>
> ---
>
> * GNU Make contains logic for recognizing recipe lines that are
> trivial commands, and eliding the use of the shell for those. So that is
> to say that some simple command like "cc this.c -o this.o -c" is handled
> via fork and exec directly. It must be the case that if SHELL is used
> to specify an alternative interpreter, that logic is suppressed.
>
>>>> That's exactly how I view gcc's UI. Most Linux-derived utilities are
>>>> as bad: you invoke them, and they just apparently hang. Then you
>>>> realise they're waiting for input. Would it kill somebody to get them
>>>> to display a prompt?
>>>
>>> Are you sure you are not exaggerating just a /tiny/ bit?
>>
>> I mainly remember the times when they do hang.
>
> DOS/Windows stuff hangs also:
>
> C:\Users\kazk>findstr foo
> ... "hang" ...
>
> Even Microsoft clued in to the idea that a text filter shouldn't
> spew extraneous diagnostics by default.
>
>> But with 'as', it just sits there. I wonder what it's waiting for; for
>> me to type in ASM code live from the terminal? (If 'as' is designed for
>> piped-in input, tdm/gcc doesn't appear to use that feature as I remember
>> it generating discrete, temporary .s files.)
>
> gcc -pipe works in pipe mode.
>
> The "as" command is intended for compiler use; not only is it not
> an interactive assembler, it doesn't even have particularly good
> diagnostics for batch use. You have to know what you're doing.
>

For my special atomic lib, I used GAS to create an object file, then
just linked them in. all okay.

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

MASM version... :^)

https://web.archive.org/web/20060214112539/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_masm_asm.html

On Fri, 12 Jan 2024 22:16:25 +0000, Scott Lurndal wrote:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>bart <bc@freeuk.com> writes:
>>> On 12/01/2024 16:50, Scott Lurndal wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 12/01/2024 13:40, David Brown wrote:
>>>>>> On 12/01/2024 00:20, bart wrote:
>>>>>
>>>>> But with 'as' it just sits there. I wonder what it's waiting for; for
>>>>> me to type in ASM code live from the terminal?
>>>> It does that so you can pipe the assembler source code in to the
>>>> assembler.
>>>> $ cat file.s | as
>>>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Yes, I used this as an example pipeline. I don't recall
> if the original as(1) wrote to stdout or always just to
> a.out.

IIRC, Dennis Ritchie told a story about early Unix implemented on a system
without memory protection mechanisms. The language tools of the time took
up a lot of memory when compiling, and could trespass into other user's
process memory space. It became customary, on this system, to holler
"A dot OUT" whenever compiling, to warn the other programmers that the
compiler was in use.

I believe that the compiler suite /always/ wrote an a.out file. But,
it wouldn't have been the assembler (as), but the linker (ld) that
created it.

>>> What might someone expect the output to be? Probably not 'a.out', more
>>> likely hello.o. Why /isn't/ it just hello.o?
>>
>>Partly historical inertia, and partly because "as" can't always know
>>what the output file should be, for example if its input isn't a file.
>
> Yup. a.out is the historical inertia.

--
Lew Pitcher
"In Skills We Trust"

On 1/12/24 18:59, bart wrote:

>> $ cat file.c | cpp | c0 | c1 | c2 | as > file.o
>
> Using ">" on binary content? That seems off.

Why ?

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On Fri, 12 Jan 2024 23:04:56 +0000, Lew Pitcher wrote:
[snip]
>
> I believe that the compiler suite /always/ wrote an a.out file. But,
> it wouldn't have been the assembler (as), but the linker (ld) that
> created it.

Looking back into my manuals, it appears that the assembler defaulted
to writing a.out if the assembly did not require any external references.

To quote the "Unix Assembler Reference Manual" for Seventh Edition Unix
"As ... produces an output file that contains relocation information
and a complete symbol table; thus the output is acceptable to the
UNIX link-editor ld, which may be used to combine the outputs of
several assembler runs and to obtain object programs from libraries.
The output format has been designed so that if a program contains
no unresolved references to external symbols, it is executable
without further processing."
and
"The output of the assembler is by default placed on the file a.out
in the current directory; the "-o" flag causes the output to be
placed on the named file."

[snip]
--
Lew Pitcher
"In Skills We Trust"