On 08/03/2024 10:01, Don Y wrote:
> On 3/8/2024 1:38 AM, albert@spenarnc.xs4all.nl wrote:
>> In article <urqpn1$pptq$2@dont-email.me>,
>> Don Y  <blockedofcourse@foo.invalid> wrote:
>>> On 2/29/2024 6:37 AM, albert@spenarnc.xs4all.nl wrote:
>>>> One-to-one relationship between assembler mnemonics and numbers?
>>>> This is a myth.
>>>
>>> It has never been true.  An assembler is free to generate whatever code
>>> satisfies the desire stated by the programmer.

No. An assembler is required to generate the opcode that corresponds to
the mnemonic that the programmer specified. A compiler or autocoder is
free to use whichever way of say loading zero into the accumulator it
likes. But if the programmer writes movi acc, #0 then in assembler then
that is what they get (even if xor acc,acc is much faster).

Once you start with macro assemblers and have smart macros then all bets
are off but for intrinsic mnemonics they are a clean translation to hex.

>> That is a silly response to a description of an assembler that
>> accomplish a one to one correspondance between machine code and
>> mnemonics. I don't care what other assemblers do or doesn't do.
>
> The assumption that an assembler -- and, thus, a qualification for
> ALL assemblers -- generates a one-to-one correspondence between
> mnemonic and machine code is false.

I can't offhand think of any assembler that didn't have a regular and
reproducible mapping of its opcode mnemonics to hexadecimal numbers (and
vice versa although going backwards tended to be a many to one mapping).
>
> What term do you apply to tools that take "assembly language"
> mnemonics and DON'T generate one-to-one correspondences?
> Are these NOT "assemblers"?

MOV for instance often has several hexadecimal codes that it corresponds
to because there are so many different sorts. But that is more of a
problem for disassemblers than anything else.

> What term do you apply to tools that take "assembly language"
> mnemonics and DO generate one-to-one correspondences?
> Are these ALSO not assemblers?
>
> I.e., the one-to-one correspondence is an *imagined* requirement
> of "an assembler".

The way I obtain unsupported genuine modern opcodes in some archaic
inline assemblers that lack support or any other way of doing it is to
hack together a jump forward a few bytes and a load immediate long hex
constant. It is only worth doing this as an absolute last resort.

--
Martin Brown

On 3/8/2024 4:03 AM, Martin Brown wrote:
> On 08/03/2024 10:01, Don Y wrote:
>> On 3/8/2024 1:38 AM, albert@spenarnc.xs4all.nl wrote:
>>> In article <urqpn1$pptq$2@dont-email.me>,
>>> Don Y  <blockedofcourse@foo.invalid> wrote:
>>>> On 2/29/2024 6:37 AM, albert@spenarnc.xs4all.nl wrote:
>>>>> One-to-one relationship between assembler mnemonics and numbers?
>>>>> This is a myth.
>>>>
>>>> It has never been true.  An assembler is free to generate whatever code
>>>> satisfies the desire stated by the programmer.
>
> No. An assembler is required to generate the opcode that corresponds to the
> mnemonic that the programmer specified.

An assembler interprets an ASSEMBLY LANGUAGE -- that the author of the
assembler created -- to generate some (usually intermediate) form of
the operation desired.

What "code" does this generate:

FOO EQU 27

Or:
ORG $-1

Or:
JMP FOOBAR

Ans: you can't tell me because they all rely on the manner in which
the PARTICULAR author defined the assembly language for HIS assembler.
(What the hell is a FOOBAR? What is the machine language -- a series
of bits -- for it?)

If you've ever had to port code to a different toolchain, you
quickly learn that ASM is NOT portable (gee, shouldn't it be?
esp if there is a one-to-one correspondence between mnemonics and
machine code???!)

[We'll ignore the fact that the actual bits you *assume* will be
generated will rely on the value of "FOOBAR" AFTER linkage editor
has had a pass at it as, clearly, any changes to its value -- most
typically a symbolic location reference (though it can be ANY
value created with any mechanism the assembler author has provided...
even a manifest constant!) -- would change the bits generated in
the final binary]

Pick a processor. Any processor. What's the assembly language for THAT
processor? Ans: it depends on the assembler that you choose to use.
A processor manufacturer can define mnemonics for "machine code"
but the assembler author is under no obligation to use those.

> A compiler or autocoder is free to use
> whichever way of say loading zero into the accumulator it likes. But if the
> programmer writes movi acc, #0 then in assembler then that is what they get
> (even if xor acc,acc is much faster).

No. You are relying on a particular assembler's (author) interpretation of
those character sequences. I can write an assembler that disables interrupts
when it encounters that sequence of characters (it would confuse YOU but would
be a perfectly acceptable way of defining a means of causing interrupts to
be disabled).

> Once you start with macro assemblers and have smart macros then all bets are
> off but for intrinsic mnemonics they are a clean translation to hex.

Again, no.

>>> That is a silly response to a description of an assembler that
>>> accomplish a one to one correspondance between machine code and
>>> mnemonics. I don't care what other assemblers do or doesn't do.
>>
>> The assumption that an assembler -- and, thus, a qualification for
>> ALL assemblers -- generates a one-to-one correspondence between
>> mnemonic and machine code is false.
>
> I can't offhand think of any assembler that didn't have a regular and
> reproducible mapping of its opcode mnemonics to hexadecimal numbers (and vice
> versa although going backwards tended to be a many to one mapping).

Perhaps you've not had as much experience as I? Historical perspective
is often enlightening.

Here are some examples I previously posted:

<https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_23.html#SEC258>
this behavior is inherited from the early days of as(1).

<http://www.bitsavers.org/pdf/sun/sunos/4.1/800-3807-10A_Sun-3_Assembly_Language_Reference_Manual_199003.pdf>
section 6.2
(30+ years ago)

"as supports extended branch instructions in addition to the
instructions which explicitly specify the instruction length.
These instruction's names are, in most cases, constructed from
the word versions by replacing the b with j. For example,
compare beq with jeq.

"as's rules for handling branch instructions are as follows:
- as automatically generates the corresponding short
branch instruction if the operand of the extended branch
instruction is a simple address in the text segment, and
the offset to that address is sufficiently small. as
generates the corresponding branch instruction if the
offset is too large for a short branch, but small enough
for a branch.
- as implements an extended branch instruction when the operand
either references an external address or is complex (see
below) as follows:
1. By a jmp or jsr (for jra or jbsr).
2. If the target processor is the MC68010, by a conditional
branch (with the sense of the condition inverted) around
a jrnp for the extended conditional branches.
3. If the target processor is the MC68020, by using
the corresponding long branch.

Note that last bit: your "jump if carry" is converted to a "jump if NO carry"
in some cases. Clearly an entirely different opcode! oops! so much for
the "one-to-one mapping"...

<https://www.roug.org/retrocomputing/os/flex/ASM09-6809-assembler.pdf>
and SWTPC wasn't a software trailblazer (40+ years ago):

"Optimize Assembly. The "F" option will cause the
assembler to suppress any optimization of object code.
Foreward [sic] references will be assembled “using the least
restrictive addressing modes. . This. option will force the.
assembler to complete in two passes, but ‘object.. code may. be
considerably larger than required. This option is especially
useful while debugging a program which will later be
optimized. Note that the "R" option takes priority over this

Note that this is nothing "new"; most of the references are for
DECADES old tools. Because tool developers realized that there is
a lot of annoying "cruft" that thinking just one level above machine
code forces on the developer.

Why should I have to know how far away "FOOBAR" is from the current
program counter associated with the JMP instruction that references
it in order to know whether to use JR (jump relative -- which
places limits on how far away the target can be but takes up less
space and executes faster) vs. JP (which takes up more space and
is slower but can go "anywhere"?).

You (tool maker) don't require me to specify numerical addresses
as the target of the jump -- because that would be extra cruft
that the developer would have to track (and the goal of the tool
is to make it EASIER to write CORRECT code). Why would you force
me to know how many program locations EACH instruction between
"here" and "FOOBAR" requires?

Or, do you expect me to try *an* encoding (i.e., choice of mnemonics)
and see if the assembler (or, linkage editor if the displacement isn't
visible to the assembler, directly) throws an error -- and on which
instructions? Then, REWRITE those instructions, reassemble (and relink!)
which could cause OTHER instructions to now be "out of range"?

Should I (developer) have to KNOW that a certain variable will
reside in a special page of memory that can be accessed more
efficiently using a different opcode? If I (developer) opt to
move that variable to a different place in memory, should I
have to rewrite every reference to it?

Should I have to know the FINAL layout of a data structure in
order to access elements of it? Should I be forced to assume
a worst-case implementation that gives *me* (the developer)
the most flexibility in accommodating the evolution of that
structure -- at the expense of efficiency? (e.g., using a
relative addressing mode even when direct addressing could be
more efficient, based on the values of those "relative offsets"...
CONSTANTS!)

What a silly way to waste a developer's time! Why not have him
type in constants for all symbolic references, if we really want
to make him WORK?! Think how much simpler the assembler-writer's
task would be if he required the developer to generate machine code
directly!!

"Dumb" assemblers are/were limited to one-to-one mappings -- because
they were usually written with sparse resources. One can write
such an assembler INSIDE a macro-assembler and letting the *macros*
generate all of the code (a common trick for ASLs) as all you
need is syntactic/lexical analysis and symbol table maintenance.
Things that are available in most macro-assemblers.

Such a tool doesn't need to *understand* your code. So, you can
do "silly" things like arbitrarily move the "location counter" or
reference locations *inside* (multibyte) instructions.

Don Y <blockedofcourse@foo.invalid> wrote:

>On 2/15/2024 3:13 AM, Peter wrote:
>> Graet to see you Don after all these years - 2006!!
>
>Hey there, Mr "Pool" :>

Haha hello :)

The pump packed up; turned out that the 25uF (400V AC) starting cap
degraded to 15uF.

>I trust all is well, remodel long completed, kids now grown
>(which of them was first to make you "Gramps"? and wasn't your
>youngest looking for his pilot's license?), thus PBfH having
>less of an impact on your life, etc.

Divorced the witch in 1999, then the next one (2003-2023) sadly ended
in 2023.

Youngest has a PPL (UK and FAA) and flies, both mine and his RV6.
Chases females on Tinder and Hinge, like everybody else :)

>> I had a customer many years ago who did write a ton of code in hex. To
>> enable modifications they had a bit of space after each function, so
>> edits to a function did not need shifting everything after it :)
>
>But what was their *reason* for this? I had an employer (*had* been
>an engineer and deluded himself into thinking he could still *do*
>engineering) who was stuck in the past -- as if the tools and
>techniques he had used were still relavent, even a few years later!

Stupidity - assemblers have always been around.

>When it took hours to assemble, link, burn images, it made sense to
>have mechanisms to support minor tweeks to the code (overwriting
>instructions with NOPs and filling in a "0xFF" postamble with new
>code). But, nowadays, make world on even large projects is just
>a coffee break -- and, you can dump your code into RAM to watch
>it run (assuming you have to run on a target and not in a
>simulator).
>
>[Nowadays, I netboot images just for the savings that one step
>makes possible!]

Indeed.

RichD <r_delaney2001@yahoo.com> wrote:

>Given these considerations, does anybody write assembly code for
>modern RISC processors?

Yes; some stuff cannot be done in C. Start with loading SP. No way in
C!

Some code in an RTOS is not possible in C. Look at the FreeRTOS
sourcecode. There are bits of asm in there.

Also asm has great uses for protecting from optimisation (which can
change silently by upgrading the compiler!). Asm never gets modified;
essential when talking to devices needing specific minimum /CS timing
etc.

Another example, for accurate delays (ST32F417, 168MHz)

// Hang around for delay in microseconds

__attribute__((noinline))
void hang_around_us(uint32_t delay)
{ delay *= (SystemCoreClock/4100000L);

asm volatile (
"1: subs %[delay], %[delay], #1 \n"
" nop \n"
" bne 1b \n"
: [delay] "+l"(delay)
);
}

On 3/12/2024 6:10 AM, Peter wrote:
>
> RichD <r_delaney2001@yahoo.com> wrote:
>
>> Given these considerations, does anybody write assembly code for
>> modern RISC processors?
>
> Yes; some stuff cannot be done in C. Start with loading SP. No way in
> C!

Doing anything that isn't memory-mapped; how would you generate "I/O"
instructions (for processors with I/O spaces)?

Using any part of the instruction set that isn't directly mapped
to native C constructs (how would you access support for BCD
data types? special commands to control interrupts? opcodes to
control atomic operations/synchronization?)

> Some code in an RTOS is not possible in C. Look at the FreeRTOS
> sourcecode. There are bits of asm in there.
>
> Also asm has great uses for protecting from optimisation (which can
> change silently by upgrading the compiler!). Asm never gets modified;
> essential when talking to devices needing specific minimum /CS timing
> etc.

This is changing. Lots of ongoing work in optimizing and
super-optimizing assembly language code. Even arguments
being made that compilers should NOT be generating (final)
ASM, from HLL sources cuz it forces them to know too
much about the underlying hardware... things that a
(truly) "optimizing assembler" is better suited to knowing.

[E.g., how bondout options can change the costs of different
opcodes from one processor in a "family" to another]

> Another example, for accurate delays (ST32F417, 168MHz)
>
> // Hang around for delay in microseconds
>
> __attribute__((noinline))
> void hang_around_us(uint32_t delay)
> {
> delay *= (SystemCoreClock/4100000L);
>
> asm volatile (
> "1: subs %[delay], %[delay], #1 \n"
> " nop \n"
> " bne 1b \n"
> : [delay] "+l"(delay)
> );
> }
>

On 3/12/2024 6:05 AM, Peter wrote:
>> I trust all is well, remodel long completed, kids now grown
>> (which of them was first to make you "Gramps"? and wasn't your
>> youngest looking for his pilot's license?), thus PBfH having
>> less of an impact on your life, etc.
>
> Divorced the witch in 1999,

Yes. But, IIRC, there was still a lot of "interaction" as a
result of the boys. Now that they are grown, presumably that
is less of an issue, limiting the intensity of any such interactions?

> then the next one (2003-2023) sadly ended in 2023.

(sigh) Sorry to hear that. I recall you had high hopes and,
hopefully, some of those were realized.

"One can't get divorced TWICE; the first takes HALF of everything,
the second would take the OTHER half!"

> Youngest has a PPL (UK and FAA) and flies, both mine and his RV6.

But, is his interest purely recreational? Or, might he pursue
that "commercially"?

> Chases females on Tinder and Hinge, like everybody else :)

Thankfully, I've never been down that road.

>>> I had a customer many years ago who did write a ton of code in hex. To
>>> enable modifications they had a bit of space after each function, so
>>> edits to a function did not need shifting everything after it :)
>>
>> But what was their *reason* for this? I had an employer (*had* been
>> an engineer and deluded himself into thinking he could still *do*
>> engineering) who was stuck in the past -- as if the tools and
>> techniques he had used were still relavent, even a few years later!
>
> Stupidity - assemblers have always been around.

I think a lot has to do with wanting to THINK that an imagined skillset
is still valuable. With UV/OTP EPROM, that tactic *might* make sense
(as a rebuild could be time consuming vs. patching an image, on-the-fly.

But, with FLASH and RAM-based solutions, there's no time to be saved
(to outweigh the potential for screwing up "manually")

>> When it took hours to assemble, link, burn images, it made sense to
>> have mechanisms to support minor tweeks to the code (overwriting
>> instructions with NOPs and filling in a "0xFF" postamble with new
>> code). But, nowadays, make world on even large projects is just
>> a coffee break -- and, you can dump your code into RAM to watch
>> it run (assuming you have to run on a target and not in a
>> simulator).
>>
>> [Nowadays, I netboot images just for the savings that one step
>> makes possible!]
>
> Indeed.

It's delightful to see what can now be done on-the-cheap! No
more playing games with hardware (and its costs/reliability)
when you can just emulate any functionality you want!

(I have a design where a '7180 acted as an EPROM emulator in
a production design to give me debugging support via a
serial console that it provided; i.e., let the 7180 "fetch"
bytes over the serial console instead of having to store them
*in* its EPROM -- a predecessor to netbooting! :> )

I've been tempted to try reimplementing some early designs just to
see how quickly the development would proceed AND how much faster
the code would execute... big change from a ~700KHz i4004 to an
800MHz quad-core (costing a tenth as much!). It would be
depressing to discover that a man-year effort can be reduced to
a long weekend! :<

Don Y <blockedofcourse@foo.invalid> wrote:

>On 3/12/2024 6:05 AM, Peter wrote:
>>> I trust all is well, remodel long completed, kids now grown
>>> (which of them was first to make you "Gramps"? and wasn't your
>>> youngest looking for his pilot's license?), thus PBfH having
>>> less of an impact on your life, etc.
>>
>> Divorced the witch in 1999,
>
>Yes. But, IIRC, there was still a lot of "interaction" as a
>result of the boys. Now that they are grown, presumably that
>is less of an issue, limiting the intensity of any such interactions?

Not dealt with her for ~10 years, and never will :)

>> then the next one (2003-2023) sadly ended in 2023.
>
>(sigh) Sorry to hear that. I recall you had high hopes and,
>hopefully, some of those were realized.
>
>"One can't get divorced TWICE; the first takes HALF of everything,
>the second would take the OTHER half!"

Hahaha. It's actually a power series: 1/2 + 1/4 + 1/8 + 1/16.
According to
https://en.wikipedia.org/wiki/1/2_%E2%88%92_1/4_%2B_1/8_%E2%88%92_1/16_%2B_%E2%8B%AF
it converges to 1/3 so you will always eat afterwards ;)

>> Youngest has a PPL (UK and FAA) and flies, both mine and his RV6.
>
>But, is his interest purely recreational? Or, might he pursue
>that "commercially"?

I think Tinder has curtailed commercial ambitions ;)

>I've been tempted to try reimplementing some early designs just to
>see how quickly the development would proceed AND how much faster
>the code would execute... big change from a ~700KHz i4004 to an
>800MHz quad-core (costing a tenth as much!). It would be
>depressing to discover that a man-year effort can be reduced to
>a long weekend! :<

My last design is 100x faster than anything done before, and the CPU
costs about $7.

But the software takes as long - because 90% of the functionality is
now connectivity! MbedTLS etc. There is even an HTTP server (simple: I
wrote it myself) for config.

Don Y <blockedofcourse@foo.invalid> wrote:

>On 3/12/2024 6:10 AM, Peter wrote:
>>
>> RichD <r_delaney2001@yahoo.com> wrote:
>>
>>> Given these considerations, does anybody write assembly code for
>>> modern RISC processors?
>>
>> Yes; some stuff cannot be done in C. Start with loading SP. No way in
>> C!
>
>Doing anything that isn't memory-mapped; how would you generate "I/O"
>instructions (for processors with I/O spaces)?

I think I/O is rare; it tends to be memory mapped.

>Using any part of the instruction set that isn't directly mapped
>to native C constructs (how would you access support for BCD
>data types? special commands to control interrupts? opcodes to
>control atomic operations/synchronization?)
>
>> Some code in an RTOS is not possible in C. Look at the FreeRTOS
>> sourcecode. There are bits of asm in there.
>>
>> Also asm has great uses for protecting from optimisation (which can
>> change silently by upgrading the compiler!). Asm never gets modified;
>> essential when talking to devices needing specific minimum /CS timing
>> etc.
>
>This is changing. Lots of ongoing work in optimizing and
>super-optimizing assembly language code. Even arguments
>being made that compilers should NOT be generating (final)
>ASM, from HLL sources cuz it forces them to know too
>much about the underlying hardware... things that a
>(truly) "optimizing assembler" is better suited to knowing.

I'll leave that to the next generation. I want to make a bit of money
now :)

Peter <occassionally-confused@nospam.co.uk> wrote:

>>"One can't get divorced TWICE; the first takes HALF of everything,
>>the second would take the OTHER half!"
>
>Hahaha. It's actually a power series: 1/2 + 1/4 + 1/8 + 1/16.
>According to
>https://en.wikipedia.org/wiki/1/2_%E2%88%92_1/4_%2B_1/8_%E2%88%92_1/16_%2B_%E2%8B%AF
>it converges to 1/3 so you will always eat afterwards ;)

I was wrong
https://www.quora.com/How-does-1-2-1-4-1-8-1-16-till-infinity-have-a-sum-2

So yes if you keep divorcing you will eventually lose 100%

On 3/13/2024 9:28 AM, Peter wrote:
>> I've been tempted to try reimplementing some early designs just to
>> see how quickly the development would proceed AND how much faster
>> the code would execute... big change from a ~700KHz i4004 to an
>> 800MHz quad-core (costing a tenth as much!). It would be
>> depressing to discover that a man-year effort can be reduced to
>> a long weekend! :<
>
> My last design is 100x faster than anything done before, and the CPU
> costs about $7.

Yup. I can recall paying $60 for an i4004 -- in 1970's money!
And, a time when 2716's hit $50/each.

For me, it's the difference between a 700KHz processor and an 800MHz
quad processor (at less money).

The idea of trying to save on hardware costs is just silly-speak
(for most designs).

> But the software takes as long - because 90% of the functionality is
> now connectivity! MbedTLS etc. There is even an HTTP server (simple: I
> wrote it myself) for config.

And, there is *increased* functionality. You do things that you wouldn't
ever have considered, previously.

E.g., that first i4004 product required an offline PDP-11 to
calculate initialization coefficients for each customer/deployment.
Customer moves to a different part of the world and we have to
rerun the initialization code.

*Second* product did all of that *in* the device -- something you
would expect, nowadays (but were wowed by, 45 years ago!). A lot
harder to get that sort of code working in a device that you (as
engineer) will no longer be able to stand watch over ("What if the
code throws an error? How will the customer handle that situation?")

But, realizing that connectivity/intercommunications is the
heart of the problem (always has been... "Eschew Globals", etc.)
coaxes you to address THAT issue in your design framework.

My current biggest challenge is designing for 24/7/365 runtimes
where hardware changes and software upgrades happen without
power cycling or rebooting (the MULTICS "Software as a Service"
mantra). A completely new set of design challenges... (how do
you test devices WHILE they are providing services?? how do
you flag them as failed AND replace them without interrupting
the rest of the system?)

On 3/13/2024 9:29 AM, Peter wrote:
>
> Don Y <blockedofcourse@foo.invalid> wrote:
>
>> On 3/12/2024 6:10 AM, Peter wrote:
>>>
>>> RichD <r_delaney2001@yahoo.com> wrote:
>>>
>>>> Given these considerations, does anybody write assembly code for
>>>> modern RISC processors?
>>>
>>> Yes; some stuff cannot be done in C. Start with loading SP. No way in
>>> C!
>>
>> Doing anything that isn't memory-mapped; how would you generate "I/O"
>> instructions (for processors with I/O spaces)?
>
> I think I/O is rare; it tends to be memory mapped.

For *new* hardware, yes. But, still present in older designs
(that likely need to be maintained)

>> Using any part of the instruction set that isn't directly mapped
>> to native C constructs (how would you access support for BCD
>> data types? special commands to control interrupts? opcodes to
>> control atomic operations/synchronization?)
>>
>>> Some code in an RTOS is not possible in C. Look at the FreeRTOS
>>> sourcecode. There are bits of asm in there.
>>>
>>> Also asm has great uses for protecting from optimisation (which can
>>> change silently by upgrading the compiler!). Asm never gets modified;
>>> essential when talking to devices needing specific minimum /CS timing
>>> etc.
>>
>> This is changing. Lots of ongoing work in optimizing and
>> super-optimizing assembly language code. Even arguments
>> being made that compilers should NOT be generating (final)
>> ASM, from HLL sources cuz it forces them to know too
>> much about the underlying hardware... things that a
>> (truly) "optimizing assembler" is better suited to knowing.
>
> I'll leave that to the next generation. I want to make a bit of money
> now :)

There are lots of ways to make money. The joy of engineering is
that you can have *fun* -- and learn stuff -- while doing so!
(imagine being an *accountant*, lawyer, doctor, etc. -- fields where
"new knowledge" drips out at a trickle...)

On 14/03/2024 10:47 am, Don Y wrote:
> On 3/13/2024 9:29 AM, Peter wrote:
>>   Don Y <blockedofcourse@foo.invalid> wrote
>>> On 3/12/2024 6:10 AM, Peter wrote:
>>>>    RichD <r_delaney2001@yahoo.com> wrote:

> There are lots of ways to make money.  The joy of engineering is
> that you can have *fun* -- and learn stuff -- while doing so!
> (imagine being an *accountant*, lawyer, doctor, etc. -- fields where
> "new knowledge" drips out at a trickle...)
Medical doctors have to cope with a flood of new knowledge.

The peer-reviewed literature where most of it comes out isn't as well
regulated in medicine as it is in most sciences - medical professors
still have the god-professor status that all professor had in Germany in
1920s. and they get to publish a lot of half-baked papers.

This means that a lot of what is touted as new knowledge is pretentious
nonsense.

The regular literature contains a lot of stuff that wasn't worth
publishing, but it tends to be more unhelpful than actively wrong.

Of course medical doctors are dealing with the same old problems that
human beings have always had, while engineers have invented new problems
to solve.

--
Bill Sloman, Sydney