On 2/14/2024 6:09 AM, albert@spenarnc.xs4all.nl wrote:
>> I don't know if there is something malicious in there. That's
>> why I really hate every little stupid program and app that
>> thinks it needs to auto-update and needs admin approval to
>> install and screw with the operating system. If there is
>> a portable option, I get that and I keep old versions until
>> they break.
>
> Totally agree. I'm waiting till one managed to subvert one
> of the mainstream browsers with a backdoor via the obligatory
> daily updates.

How do you know that what you've "frozen" hasn't already been compromised?
A latent virus can wreak havoc on your system *years* after infection.

Graet to see you Don after all these years - 2006!!

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 :)

Peter

Don Y <blockedofcourse@foo.invalid> wrote:

>One writes code to be *read*. Just because you CAN do something
>doesn't mean you SHOULD do that something. People spend inane
>amounts of time arranging dominos... just to knock them over
>(what's the point in that?)
>
>A kid I attended school with built his own little computer (pre-CP/M),
>wrote a monitor in machine code that he then burned into ROM.
>Used that to write an assembler. Then an OS, etc. Interesting
>"hobby" and worthwhile only if your time has no value.
>
>I had a job where we had a cheap, *live* system monitor that would
>let us watch variables and patch code while the system was running.
>But, the UI was limited to a six digit *numeric* display -- which
>means "split octal" (0xFFFF is 377377) instead of hexadecimal -- and
>keypad. So, you had to memorize opcodes in octal and convert
>all arguments to that prior to use/recognition.
>
>"Walking" (ADDRESS++) through the code required you to recognize
>opcodes and recall how many bytes followed before the next opcode
>would be encountered. Or *if* it would be encountered (as absolute
>and relative jumps/calls could interrupt the sequential flow).
>
>Having that *live* ability to interact with the system was a huge
>asset (at a time when ICE was uncommon -- and expensive!) and was
>present in every product that we released (so, you could carry a
>tiny piece of hardware to a site and interact with the system).
>You could twiddle data and code and watch how the system reacted
>without having to go back to the development environment and
>turn the crank for a "what if".
>
>But, the requirement to "hand disassemble/assemble" was just ridiculous!
>(why not the same hardware interface augmented with some code to make
>the UX less risky? Why not tied into the symbol table of the
>running executable so you KNEW what you were seeing and tweaking?)
>
>Prior to that, I'd written machine code (again in octal) for the Nova.
>Data entry via the 16 toggle switches on the front panel. Data
>readout via the 16 indicator lamps associated with them.
>
>Again, a convenient capability (when access to an assembler/compiler
>wasn't possible in the field... "I need to throw together a little
>routine to exercise some particular bit of hardware so I can
>'scope the hardware) but annoyingly complex and not a very portable
>skillset.

On Wed, 14 Feb 2024 11:58:59 -0700 Don Y wrote

>How do you know that what you've "frozen" hasn't already been compromised?
>A latent virus can wreak havoc on your system *years* after infection.

I update the anti-virus, spyware and malware programs.
I got fan-made kerbal space program mods that want to access
to the internet to check for updates. Or your download some
freeware to open some .crap extension that some fool used on
a file and this app wants admin priviledges so it can integrate
into the operation and become a default program. When I was in
college I had programming Professor who taught Pascal and his
big thing was 'scoping'. Every procedure should be self-contained
and have simple defined connection to the global program. Now every
program wants to pepper my computer with dll's they that programmer
picked up from a package he got from who knows where.

You're right. I don't know if my current system is infected but I know
the odds of getting infected don't get better with more interactions and
more partners.

On 2/15/2024 12:02 PM, Wanderer wrote:
> On Wed, 14 Feb 2024 11:58:59 -0700 Don Y wrote
>
>> How do you know that what you've "frozen" hasn't already been compromised?
>> A latent virus can wreak havoc on your system *years* after infection.
>
> I update the anti-virus, spyware and malware programs.

But, if the particular "infestation" hasn't "manifested", in
public, previously, it is possible that the AV tools don't
KNOW about it -- yet.

I don't run AV on this machine (which is the only out-facing
machine here). I keep nothing on it (just a browser and mail
client) so can easily reconstruct it, if ever hosed.

Every 6 months, I pull the disk and set it on a shelf. I
install a fresh disk with the original machine image on it.
And, run a virus scan on the disk pulled 6 months *earlier*
(recycling that media once it has been verified as clean).

> I got fan-made kerbal space program mods that want to access
> to the internet to check for updates. Or your download some
> freeware to open some .crap extension that some fool used on
> a file and this app wants admin priviledges so it can integrate
> into the operation and become a default program. When I was in
> college I had programming Professor who taught Pascal and his
> big thing was 'scoping'. Every procedure should be self-contained
> and have simple defined connection to the global program.

Yes. "Compartmentalization". Most applications fail on this
score (whether for desktop or for an embedded instrument/appliance)
because they reside in a single process container -- any thread
can dick with any other thread's data.

Ideally, you want to partition the problem into small units
that have *slim* interfaces (minimize information sharing
as this leads to a more robust solution and a more *performant*
one, once you put up barriers between those units (processes).

> Now every
> program wants to pepper my computer with dll's they that programmer
> picked up from a package he got from who knows where.

Yup. People have no idea what they are "baking into" their "programs".
So many dweebs thinking "let's use Linux" (as the basis for a product)
without any understanding of what that entails, what risks it presents
and how to *maintain* it ("We'll just ask on some forum and hope
someone takes an interest in solving OUR CUSTOMERS' PROBLEMS").

My current system enforces *every* contract so a program can't
access anything that it hasn't *declared* a need to use (data
as well as code). This exposes all of the interconnects so
a user (customer) can decide if he wants to install that app
("Why does this app need to access...?") or if he wants to
further thwart any abuses he might suspect of the app ("Yeah,
you can access my address book! But, the version that YOU see
won't have any names in it!")

> You're right. I don't know if my current system is infected but I know
> the odds of getting infected don't get better with more interactions and
> more partners.

I think you have to just think about what you want *from* your machine
and use that as a filter when deciding if a new app/upgrade should be
installed, or not.

I keep a set of laptops for "play"; install an app on them to see if
it adds any value (or, to just get some temporary use from it) and
then reinstall the disk image (3 minutes). I used to use disposable
VMs for this (make a clean copy of a VM; install app; play; flush
dirty VM) but laptops are quicker than spinning up all the disks
on my ESXi server!

I avoid updates/upgrades, in general, as they tend to just replace
one set of "bad behaviors" with another. *AND*, take time for me
to identify those! Much easier to live with the problems I already
know about than to keep swapping them for a new set!

[It would be nice if each update came in two flavors: ONLY bug fixes
and bug fixes PLUS changes]

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

Hey there, Mr "Pool" :>

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.

> 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!

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!]

In article <uqivkh$2ontb$2@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 2/14/2024 6:05 AM, albert@spenarnc.xs4all.nl wrote:
>> Nobody hu? Smith does. Written a compiler in hex code using only
>> a hex to bin converter.
>> https://dacvs.neocities.org/SF/
>> The take away is, it is easier than you expect.
>
>One writes code to be *read*. Just because you CAN do something
>doesn't mean you SHOULD do that something. People spend inane
>amounts of time arranging dominos... just to knock them over
>(what's the point in that?)

This project is meant to be read. You can't be serious suggesting
that this is a tool to be used.
If you spend the time looking at the code, you'd discover that it
is quite educational, and make you wonder where the software bloat
comes from.
>

<SNIP>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

On February 11, Don Y wrote:
> Newer compilers are often considerably smarter than the
> programmers using them. They will rearrange code (where
> dependencies allow it) to avoid pipeline stalls. Or,
> realign structures to avoid misaligned memory accesses.
> Or even eliminate calls to functions that it can inline
> more efficiently.

Indeed. This was the motivation, and result, of the original RISC
architecture. Revolutionary, in its day, as processors were
becoming astonishingly complex, with trig functions wired into
a single machine op code!

And still today, those ideas are misunderstood, as many engineers
say "yeah, RISC is faster because they have fewer instructions,
it's obvious." (also cheaper, in cost/benefit)

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

--
Rich

On Sun, 11 Feb 2024 13:43:33 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 2/11/2024 10:47 AM, Wanderer wrote:
>> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>>
>>> It is cool coding in asm without using external libraries.
>>> I can do anything I like in KILOBYTES:
>>
>> Back in the 20th century, I knew how to program in C. I
>> knew what the assembly code would like after I compiled it.
>
>A minor point; you THOUGHT you knew what the ASM would look like...
>you knew what the processor should be *doing*.
>
>Newer compilers are often considerably smarter than the
>programmers using them. They will rearrange code (where
>dependencies allow it) to avoid pipeline stalls. Or,
>realign structures to avoid misaligned memory accesses.
>Or even eliminate calls to functions that it can inline
>more efficiently.

Or it may skip doing things that it thinks are unnecessary. As FPGA
compilers will do.

One trick is to do stuff so complex that the compiler optimizer gives
up. Or use terms that it can't know at compile time.

lørdag den 17. februar 2024 kl. 23.01.21 UTC+1 skrev John Larkin:
> On Sun, 11 Feb 2024 13:43:33 -0700, Don Y
> <blocked...@foo.invalid> wrote:
>
> >On 2/11/2024 10:47 AM, Wanderer wrote:
> >> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
> >>
> >>> It is cool coding in asm without using external libraries.
> >>> I can do anything I like in KILOBYTES:
> >>
> >> Back in the 20th century, I knew how to program in C. I
> >> knew what the assembly code would like after I compiled it.
> >
> >A minor point; you THOUGHT you knew what the ASM would look like...
> >you knew what the processor should be *doing*.
> >
> >Newer compilers are often considerably smarter than the
> >programmers using them. They will rearrange code (where
> >dependencies allow it) to avoid pipeline stalls. Or,
> >realign structures to avoid misaligned memory accesses.
> >Or even eliminate calls to functions that it can inline
> >more efficiently.
> Or it may skip doing things that it thinks are unnecessary. As FPGA
> compilers will do.
>
> One trick is to do stuff so complex that the compiler optimizer gives
> up. Or use terms that it can't know at compile time.

if you need that you are doing something wrong..

On Sat, 17 Feb 2024 15:22:44 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

>lørdag den 17. februar 2024 kl. 23.01.21 UTC+1 skrev John Larkin:
>> On Sun, 11 Feb 2024 13:43:33 -0700, Don Y
>> <blocked...@foo.invalid> wrote:
>>
>> >On 2/11/2024 10:47 AM, Wanderer wrote:
>> >> On Sun, 11 Feb 2024 06:43:31 GMT, Jan Panteltje wrote:
>> >>
>> >>> It is cool coding in asm without using external libraries.
>> >>> I can do anything I like in KILOBYTES:
>> >>
>> >> Back in the 20th century, I knew how to program in C. I
>> >> knew what the assembly code would like after I compiled it.
>> >
>> >A minor point; you THOUGHT you knew what the ASM would look like...
>> >you knew what the processor should be *doing*.
>> >
>> >Newer compilers are often considerably smarter than the
>> >programmers using them. They will rearrange code (where
>> >dependencies allow it) to avoid pipeline stalls. Or,
>> >realign structures to avoid misaligned memory accesses.
>> >Or even eliminate calls to functions that it can inline
>> >more efficiently.
>> Or it may skip doing things that it thinks are unnecessary. As FPGA
>> compilers will do.
>>
>> One trick is to do stuff so complex that the compiler optimizer gives
>> up. Or use terms that it can't know at compile time.
>
>if you need that you are doing something wrong..

I'm doing stuff that works.

On 2/17/2024 3:49 AM, albert@spenarnc.xs4all.nl wrote:
> In article <uqivkh$2ontb$2@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 2/14/2024 6:05 AM, albert@spenarnc.xs4all.nl wrote:
>>> Nobody hu? Smith does. Written a compiler in hex code using only
>>> a hex to bin converter.
>>> https://dacvs.neocities.org/SF/
>>> The take away is, it is easier than you expect.
>>
>> One writes code to be *read*. Just because you CAN do something
>> doesn't mean you SHOULD do that something. People spend inane
>> amounts of time arranging dominos... just to knock them over
>> (what's the point in that?)
>
> This project is meant to be read. You can't be serious suggesting
> that this is a tool to be used.

Why write code that isn't going to be used?

> If you spend the time looking at the code, you'd discover that it
> is quite educational, and make you wonder where the software bloat
> comes from.

Why does your PHONE have a clock in it? AND a calendar?
Don't you remember today's date? Don't you wear a wristwatch?
Why does your PC have these data, too? Don't you have a
*phone* (er, wristwatch and a memory for dates)?

Which of these has the CORRECT information? How do you know?

[I have an "atomic clock" that is supposed to keep correct
time/date. Except, twice a year, it diddles the time for
DST start end. *But*, we don't observe DST! So, while
all of the DUMB clocks in the house correctly track the REAL
time all year round, this one has to be "fixed", twice
a year, to get it to IGNORE the DST changes! So, twice
a year I look at the clock and wonder why *my* notion of
the current time differs from it's -- and then tell
it to move me to the next time zone, east or west, as
appropriate]

Why do I *need* an icon IN my word processor to invoke the
spell-checker? Thesaurus? Grammar check? Reading complexity
assessment? How does having them accessible *in* the word
processor help me if I am writing an email -- in an entirely
different "text editor" that mimics much of the functionality
of the word processor?

Does each possible application that allows for text entry
merit the availability of these tools? What if I wanted
to send an SMS?

Are you just LAZY and can't invoke each of these as STAND-ALONE
tools, as needed?

So, EVERY app gets burdened with new implementations of
tools that should be separate entities. To economize on
resources AND ensure for more consistent results!

[Windows lists files in "user-friendly order" -- which differs
from ALPHABETICAL order! Other applications opt for a more
traditional LRAlpha. Comparing file lists between the two
just ADDS to confusion (loss of productivity).]

Here is a trivial, ubiquitous, algorithm written in machine code:

DD217A00DD7E01FE323805DD3401185FDD360100DD7E02FE3C3805DD3402184F
DD360200DD7E03FE3C3805DD3403183FDD360300DD7E04FE183805DD3404182F
DD360400216F000600DD4E0609DD7E05BE3805DD34051817DD360500DD7E06FE
0C3805DD34061807DD360600DD34071F1F1C1F1E1F1E1F1F1E1F1E1F

No comments -- machines don't read comments! And, machines don't
need the code to be formatted to show instruction breaks -- it's
just a large array of bytes!

Of course, you would have to sort out where the code resides in
memory as all of the transfers of control *could* use absolute
addresses (I deliberately chose a processor that offers relative
addressing as a native addressing mode AND USED THAT to make the
binary less obscure).

Likewise, all absolute DATA addressing would require knowing WHAT
was being referenced, esp if the data are not as interrelated as
in this example.

Machine code *teaches* nothing -- beyond as a historical curio.

A bit easier to understand in ASM:

LD IX,TIMING

LD A,(IX+JIFFY)
CP A,JPS
JR C,NXTSEC

INC (IX+JIFFY)
JR DONE

NXTSEC:
LD (IX+JIFFY),0

LD A,(IX+SECOND)
CP A,SPM
JR C,NXTMIN

INC (IX+SECOND)
JR DONE

NXTMIN:
LD (IX+SECOND),0

LD A,(IX+MINUTE)
CP A,MPH
JR C,NXTHR

INC (IX+MINUTE)
JR DONE

NXTHR:
LD (IX+MINUTE),0

LD A,(IX+HOUR)
CP A,HPD
JR C,NXTDAY

INC (IX+HOUR)
JR DONE

NXTDAY:
LD (IX+HOUR),0

LD HL,DAYMON
LD B,0
LD C,(IX+MONTH)
ADD HL,BC

LD A,(IX+DAY)
CP A,(HL)
JR C,NXTMON

INC (IX+DAY)
JR DONE

NXTMON:
LD (IX+DAY),0

LD A,(IX+MONTH)
CP A,MPY
JR C,NXTYR

INC (IX+MONTH)
JR DONE

NXTYR:
LD (IX+MONTH),0

INC (IX+YEAR)

DONE:

six-significant-character labels (external linkage) not being unusual,
hysterically. (In practice, one would use a pointer to walk through the
list of counters instead of accessing them directly.)

In this form, the structure and intent is clearer. And, it uses exactly
the same run-time resources as the machine language variant, before!

This is how people THINK about the algorithm (assuming 0-based ordinals):

ASSERT( ( (jiffy >= 0) && (jiffy <= JIFFIES_PER_SECOND) ) )
if !(jiffy >= JIFFIES_PER_SECOND-1) {
jiffy++;
} else {
jiffy = 0;
ASSERT( ( (second >= 0) && (second <= SECONDS_PER_MINUTE) ) )
if !(second >= SECONDS_PER_MINUTE-1) {
second++;
} else {
second = 0;
ASSERT( ( (minute >= 0) && (minute <= MINUTES_PER_HOUR) ) )
if !(minute >= MINUTES_PER_HOUR-1) {
minute++;
} else {
minute = 0;
ASSERT( ( (hour >= 0) && (hour <= HOURS_PER_DAY) ) )
if !(hour >= HOURS_PER_DAY-1) {
hour++;
} else {
hour = 0;
ASSERT( ( (day >= 0) && (day <= DAYS_PER_MONTH[month]) ) )
if !(day >= DAYS_PER_MONTH[month]-1) {
day++;
} else {
if ( (0 == year % 4)
&& ((0 != year % 100) || (0 == year % 400)) ) {
day++;
} else {
day = 0;
ASSERT( ( (month >= 0)
&& (month <= MONTHS_PER_YEAR) ) )
if !(month >= MONTHS_PER_YEAR-1) {
month++;
} else {
month = 0;
year++;
}
}
}
}
}
}
}

Use of *longer* symbolic names makes the app easier to understand -- and
recognize! Even in the absence of explanatory comments (Joe Average likely
doesn't understand that 1900 and 2100 would NOT be leap years as the only
"century mark" in their lifetime -- 2000 -- was).

Note that the inclusion of the leap year test is intuitive -- yet absent in
the ASM and machine language versions. It would *likely* occur to Joe
Average if asked to explain how "time" is tracked.

And, I can add contractual declarations in a HLL that improve the quality
of the code, it's readability AND detect *some* types of data corruption
at run time (as most folks code in a single process container so no
protection from *themselves* or other threads, co-executing, there) Note
that people *do* think of these constraints, even if on a purely intuitive
level. Expressing them explicitly makes this more formal (and allows the
compiler, runtime and future developers to be aware of these "intuitions")

But only a newbie would code it like that! THIS form is fraught with the
potential for syntax and logic errors. Quick: which of the parens goes
with each -- if the indentation (which may be incorrect as the compiler
doesn't enforce indentation rules!) wasn't there to "help"? (Have *I*
botched it??)

A smarter way of expressing the algorithm:

{
while (FOREVER) {
ASSERT( ( (jiffy >= 0) && (jiffy <= JIFFIES_PER_SECOND) ) )
if !(jiffy >= JIFFIES_PER_SECOND-1) {
jiffy++;
break;
}

jiffy = 0;
ASSERT( ( (second >= 0) && (second <= SECONDS_PER_MINUTE) ) )
if !(second >= SECONDS_PER_MINUTE-1) {
second++;
break;
}

second = 0;
ASSERT( ( (minute >= 0) && (minute <= MINUTES_PER_HOUR) ) )
if !(minute >= MINUTES_PER_HOUR-1) {
minute++;
break;
}

minute = 0;
ASSERT( ( (hour >= 0) && (hour <= HOURS_PER_DAY) ) )
if !(hour >= HOURS_PER_DAY-1) {
hour++;
break;
}

On 2/17/2024 1:18 PM, RichD wrote:
> On February 11, Don Y wrote:
>> Newer compilers are often considerably smarter than the
>> programmers using them. They will rearrange code (where
>> dependencies allow it) to avoid pipeline stalls. Or,
>> realign structures to avoid misaligned memory accesses.
>> Or even eliminate calls to functions that it can inline
>> more efficiently.
>
> Indeed. This was the motivation, and result, of the original RISC
> architecture. Revolutionary, in its day, as processors were
> becoming astonishingly complex, with trig functions wired into
> a single machine op code!

Compilers can also have broader knowledge of YOUR code than
you do -- or WANT to! So, can deduce relationships that
may not have been obvious to you when writing the code.

Why EVER have "Code not reached"? Did you make some bad
assumptions about the data and control that led you to THINK
that code would be executed?

And, simplify things that you would foolishly try to
"hand optimize". E.g., writing:
foo <<= 1;
can make you THINK you are being clever. But, it causes a
cognitive hiccup in the reader's mind if the intent is:
foo /= 2;
or, more explicitly:
foo = foo / 2;
A good compiler will generate the same code for each
case (assuming integer data types) so why force the
reader to perform that extra step in recognition?

And, eliminate some common syntax "errors" that aren't
actually prohibited by the language:
x = foo & bar;
(are you sure you don't mean "foo && bar"?)
x = y = z;
(are you sure you don't mean "(y == z)"?)

Your goal should always be to make it MORE work for you to do something
wrong than to do it *right*!

> And still today, those ideas are misunderstood, as many engineers
> say "yeah, RISC is faster because they have fewer instructions,
> it's obvious." (also cheaper, in cost/benefit)

Not *fewer* instructions but, rather, SIMPLER instructions.
Less silicon.

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

ASM or machine code? The two differ by the presence of a compiler
in the former that is absent in the latter.

On Sunday, February 18, 2024 at 11:29:27 AM UTC+11, Don Y wrote:
> On 2/17/2024 1:18 PM, RichD wrote:
> > On February 11, Don Y wrote:

<snip>

> > Given these considerations, does anybody write assembly code for
> > modern RISC processors?
>
> ASM or machine code? The two differ by the presence of a compiler
> in the former that is absent in the latter.

Technically speaking, the software that converts assembly code into machine code is an assembler, not a compiler.

There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code. Compilers can generate strings of machine code from a higher-level language command, so it is a real distinction. I wasn't conscious of this when I first learned Fortran coding, but I was taught how the Fortran compiler expanded single lines of code into strings of assembler when I did a year's course on "Theory of Computation" the following year (1966).

--
Bill Sloman. Sydney

On Sat, 17 Feb 2024 17:16:14 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 2/17/2024 3:49 AM, albert@spenarnc.xs4all.nl wrote:
>> In article <uqivkh$2ontb$2@dont-email.me>,
>> Don Y <blockedofcourse@foo.invalid> wrote:
>>> On 2/14/2024 6:05 AM, albert@spenarnc.xs4all.nl wrote:
>>>> Nobody hu? Smith does. Written a compiler in hex code using only
>>>> a hex to bin converter.
>>>> https://dacvs.neocities.org/SF/
>>>> The take away is, it is easier than you expect.
>>>
>>> One writes code to be *read*. Just because you CAN do something
>>> doesn't mean you SHOULD do that something. People spend inane
>>> amounts of time arranging dominos... just to knock them over
>>> (what's the point in that?)
>>
>> This project is meant to be read. You can't be serious suggesting
>> that this is a tool to be used.
>
>Why write code that isn't going to be used?

One perfectly good reason is to make life hard for the
reverse-engineers. Build in a pile of redundant code, only release
executables, never the source, and thereby improve your software
sales.

>> If you spend the time looking at the code, you'd discover that it
>> is quite educational, and make you wonder where the software bloat
>> comes from.
>
>Why does your PHONE have a clock in it? AND a calendar?
>Don't you remember today's date? Don't you wear a wristwatch?
>Why does your PC have these data, too? Don't you have a
>*phone* (er, wristwatch and a memory for dates)?
>
>Which of these has the CORRECT information? How do you know?
>
>[I have an "atomic clock" that is supposed to keep correct
>time/date. Except, twice a year, it diddles the time for
>DST start end. *But*, we don't observe DST! So, while
>all of the DUMB clocks in the house correctly track the REAL
>time all year round, this one has to be "fixed", twice
>a year, to get it to IGNORE the DST changes! So, twice
>a year I look at the clock and wonder why *my* notion of
>the current time differs from it's -- and then tell
>it to move me to the next time zone, east or west, as
>appropriate]

Atomic clocks don't do that. Sounds like you have one of those
radio-controlled jobs that's works off a time signal.

>Why do I *need* an icon IN my word processor to invoke the
>spell-checker? Thesaurus? Grammar check? Reading complexity
>assessment? How does having them accessible *in* the word
>processor help me if I am writing an email -- in an entirely
>different "text editor" that mimics much of the functionality
>of the word processor?
>
>Does each possible application that allows for text entry
>merit the availability of these tools? What if I wanted
>to send an SMS?
>
>Are you just LAZY and can't invoke each of these as STAND-ALONE
>tools, as needed?
>
>So, EVERY app gets burdened with new implementations of
>tools that should be separate entities. To economize on
>resources AND ensure for more consistent results!
>
>[Windows lists files in "user-friendly order" -- which differs
>from ALPHABETICAL order! Other applications opt for a more
>traditional LRAlpha. Comparing file lists between the two
>just ADDS to confusion (loss of productivity).]
>
>Here is a trivial, ubiquitous, algorithm written in machine code:
>
>DD217A00DD7E01FE323805DD3401185FDD360100DD7E02FE3C3805DD3402184F
>DD360200DD7E03FE3C3805DD3403183FDD360300DD7E04FE183805DD3404182F
>DD360400216F000600DD4E0609DD7E05BE3805DD34051817DD360500DD7E06FE
>0C3805DD34061807DD360600DD34071F1F1C1F1E1F1E1F1F1E1F1E1F

That's hex, not MC.

>No comments -- machines don't read comments! And, machines don't
>need the code to be formatted to show instruction breaks -- it's
>just a large array of bytes!

..... and this is why obfuscated language competitions are such fun.
Except obfuscated Perl, of course - as there's no point! :-)

søndag den 18. februar 2024 kl. 05.11.25 UTC+1 skrev Anthony William Sloman:
> On Sunday, February 18, 2024 at 11:29:27 AM UTC+11, Don Y wrote:
> > On 2/17/2024 1:18 PM, RichD wrote:
> > > On February 11, Don Y wrote:
> <snip>
> > > Given these considerations, does anybody write assembly code for
> > > modern RISC processors?
> >
> > ASM or machine code? The two differ by the presence of a compiler
> > in the former that is absent in the latter.
> Technically speaking, the software that converts assembly code into machine code is an assembler, not a compiler.
>
> There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code.

usually but not always

On 2/18/2024 3:26 AM, Lasse Langwadt Christensen wrote:
> søndag den 18. februar 2024 kl. 05.11.25 UTC+1 skrev Anthony William Sloman:
>> On Sunday, February 18, 2024 at 11:29:27 AM UTC+11, Don Y wrote:
>>> On 2/17/2024 1:18 PM, RichD wrote:
>>>> On February 11, Don Y wrote:
>> <snip>
>>>> Given these considerations, does anybody write assembly code for
>>>> modern RISC processors?
>>>
>>> ASM or machine code? The two differ by the presence of a compiler
>>> in the former that is absent in the latter.
>> Technically speaking, the software that converts assembly code into machine code is an assembler, not a compiler.
>>
>> There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code.
>
> usually but not always

Optimizing assemblers have been around since the 70's. The most common
optimization is for branch encoding on processors that support different
branch style (e.g., long, absolute, relative, etc.) Most often, the
"best" (shortest/fastest) opcode has limitations on how "far" the
supported reach. You don't want to have to PICK a particular opcode
based on the layout of the code, *now*... and, after inserting/moving
a few instructions, have to go back to choose a *different* opcode
because the target is now beyond the reach of the opcode you
previously chose!

The UNIX assembler has done this... forever. You can find tools that
will do this on VAX, 68K, 6809, Z80, SPARC, etc.

It's an NP-complete problem so expecting an "optimal" solution isn't
possible. However, the alternative -- MANUALLY trying to determine the
distance between branch opcode and targeted location -- is silly to
expect programmers to do with any degree of success (can you remember
how many bytes *each* instruction between "here" and "there" occupy?
Do you WANT to????)

[If the target of a branch lies in another module, then the linkage editor
has to sort out the required displacement.]

Other tools are smart enough to know that, for example, a "register load
of #0" is equivalent to XORing the register with itself, subtracting itself
from itself, etc. Or, may have an alternate form for "small" constants
than "larger" constants. The cost (time and space) of each approach
vary so deciding how you want the code to be optimized is important
(if at all).

Is subtracting 1 faster/smaller than decrementing a register?

Is shifting a register left cheaper than adding a register to itself?

Considering that most programmers (in ASM) use symbols instead of absolute
values, it's not uncommon for you to see code like:
LD A,SOME_VALUE
and, discover (at compile time), that SOME_VALUE is actually 0. Or,
some very small (e.g., 4 bit) integer. So, taking the instruction as
written, literally, is more costly than it needs to be! Should the
developer HAVE to know all of this? (Why?)

Should the developer have to know how to keep the pipeline from stalling?
Why not let the assembler reorder opcodes to ensure it doesn't?!

The assembler has to guarantee that the same *functionality* is provided
as defined in the ASM source; if it can do this more effectively than
the nominal instruction sequence presented by the programmer, more power
to it! (If you don't want it to dick with your code, then disable the
optimizations!)

Consider accessing the Nth element (where N is a variable) in an array
of structures.

STRUCT_SIZE equ <something>

LD A,N
LD B,#STRUCT_SIZE
MUL
LDA B,X (assumes product < 256)

Imagine if STRUCT_SIZE was 2. Or 4. Or 16. Or *1*!

Or, 3, 5, 9, etc.

This could easily be reduced in time and/or space! The developer
wouldn't want to have to go through and examine every symbolic
reference to see how the associated code MIGHT be tweeked given
the *current* numeric bindings (i.e., the STRUCT_SIZE may change
as the code evolves so this could potentially need to be revisited
each time the code is compiled!) -- the *tool* should do this,
instead!

Nowadays, we rely on HLLs to do the optimization *before* generating
their ASM "output". But, who (what!) optimizes ASM itself?

On Sunday, February 18, 2024 at 9:13:40 PM UTC+11, Cursitor Doom wrote:
> On Sat, 17 Feb 2024 17:16:14 -0700, Don Y <blocked...@foo.invalid> wrote:
> >On 2/17/2024 3:49 AM, alb...@spenarnc.xs4all.nl wrote:
> >> In article <uqivkh$2ontb$2...@dont-email.me>,
> >> Don Y <blocked...@foo.invalid> wrote:
> >>> On 2/14/2024 6:05 AM, alb...@spenarnc.xs4all.nl wrote:

> >[I have an "atomic clock" that is supposed to keep correct
> >time/date. Except, twice a year, it diddles the time for
> >DST start end. *But*, we don't observe DST! So, while
> >all of the DUMB clocks in the house correctly track the REAL
> >time all year round, this one has to be "fixed", twice
> >a year, to get it to IGNORE the DST changes! So, twice
> >a year I look at the clock and wonder why *my* notion of
> >the current time differs from it's -- and then tell
> >it to move me to the next time zone, east or west, as
> >appropriate]
>
> Atomic clocks don't do that. Sounds like you have one of those
> radio-controlled jobs that's works off a time signal.

And the time signal is usually local.

Our English radio-controlled clock didn't work in the Netherlands, and we had to buy a Dutch/German version that relied on the German broad-cast timing signal.
There's no Australian equivalent, but my mobile phone gets its - very accurate - clock signal from the much more local near-by cell tower.

<snip>

> >Here is a trivial, ubiquitous, algorithm written in machine code:
> >
> >DD217A00DD7E01FE323805DD3401185FDD360100DD7E02FE3C3805DD3402184F
> >DD360200DD7E03FE3C3805DD3403183FDD360300DD7E04FE183805DD3404182F
> >DD360400216F000600DD4E0609DD7E05BE3805DD34051817DD360500DD7E06FE
> >0C3805DD34061807DD360600DD34071F1F1C1F1E1F1E1F1F1E1F1E1F
>
> That's hex, not MC.
>
> >No comments -- machines don't read comments! And, machines don't
> >need the code to be formatted to show instruction breaks -- it's
> >just a large array of bytes!

The PDP-8 used 12-bit words, which are neither octal (bytes) nor hexadecimal. Byte's used to be just the memory cell size , and if you meant meant you would say "octets", but the language changes with time.

<snip>

--
Bill Sloman, Sydney

On February 18, skrev Lasse Langwadt Christensen:
>>>> Given these considerations, does anybody write assembly code for
>>>> modern RISC processors?
>
>>> ASM or machine code? The two differ by the presence of a compiler
>>> in the former that is absent in the latter.
>
>> Technically speaking, the software that converts assembly code into machine code is an assembler,
>> not a compiler.
>> There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code.
>
> usually but not always

?
Exceptions?

--
Rich

On 2/18/2024 12:42 PM, RichD wrote:
> On February 18, skrev Lasse Langwadt Christensen:
>>>>> Given these considerations, does anybody write assembly code for
>>>>> modern RISC processors?
>>
>>>> ASM or machine code? The two differ by the presence of a compiler
>>>> in the former that is absent in the latter.
>>
>>> Technically speaking, the software that converts assembly code into machine code is an assembler,
>>> not a compiler.
>>> There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code.
>>
>> usually but not always
>
> ?
> Exceptions?

<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)

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

søndag den 18. februar 2024 kl. 20.42.54 UTC+1 skrev RichD:
> On February 18, skrev Lasse Langwadt Christensen:
> >>>> Given these considerations, does anybody write assembly code for
> >>>> modern RISC processors?
> >
> >>> ASM or machine code? The two differ by the presence of a compiler
> >>> in the former that is absent in the latter.
> >
> >> Technically speaking, the software that converts assembly code into machine code is an assembler,
> >> not a compiler.
> >> There's a one-to-one relationship between assembler mnemonics and numbers that constitute the machine code.
> >
> > usually but not always
> ?
> Exceptions?

for example LDR in an ARM, it loads a constant into a register
depending on the value of the constant the assembler decides if is possible to do directly with the constant embedded in the instruction or if it needs to do a load from a pool of constants somewhere in memory

In article <815fc7fb-5b54-4493-9651-ec4a5e96d6f5n@googlegroups.com>,
Anthony William Sloman <bill.sloman@ieee.org> wrote:
>On Sunday, February 18, 2024 at 11:29:27 AM UTC+11, Don Y wrote:
>> On 2/17/2024 1:18 PM, RichD wrote:
>> > On February 11, Don Y wrote:
>
><snip>
>
>> > Given these considerations, does anybody write assembly code for
>> > modern RISC processors?
>>
>> ASM or machine code? The two differ by the presence of a compiler
>> in the former that is absent in the latter.
>
>Technically speaking, the software that converts assembly code into
>machine code is an assembler, not a compiler.
>
>There's a one-to-one relationship between assembler mnemonics and numbers
>that constitute the machine code. Compilers can generate strings of
>machine code from a higher-level language command, so it is a real
>distinction. I wasn't conscious of this when I first learned Fortran
>coding, but I was taught how the Fortran compiler expanded single lines of
>code into strings of assembler when I did a year's course on "Theory of
>Computation" the following year (1966).

One-to-one relationship between assembler mnemonics and numbers?
This is a myth.
You seem oblivious that Intel's
MOV AX,BX
chooses between two instructions to the discretion of the assembler at hand?
(not to speak of shorter forms that involves AX only.)

I've made a reverse engineering assembler that allows disassembled code
to assemble to a copy of the original, obliged to differentiate between
the two.
See https://github.com/albertvanderhorst/ciasdis

The two forms are
MOV, X| T| BX'| R| AX|
MOV, X| F| AX'| R| BX|

Move primary register AX to secondary register BX using default size (X).
Move primary register BX from secondary register AX

It is hard to analyse viruses without those finesse.

>
>--
>Bill Sloman. Sydney

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

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.

Just like:
X = X - X
X = 0 * (whatever)
X = 0
all achieve the same results, so can:
LD A,0
SUB A,A
XOR A
in "assembly language".

The author/designer of the "assembler" states the rules that *he* will
apply and observe in his selection of MACHINE LANGUAGE instructions.
If the programmer wants to force a particular bit of generated code,
then the assembler writer provides a mechanism for doing this.
Most programmers wouldn't care as long as the code DID what they
wanted.

Hysterically, the most common "optimization" was branch reduction
because it's foolish to require an ASM programmer to have to KNOW
"how far" a destination is from the current instruction (he would
have to know the space required by each instruction between there
and here AND what the "actual" PC value was at the time of the branch
(i.e., it likely points to the NEXT instruction, not to the current
instruction, and branch ranges are usually relative to this)

[I've posted several examples of this dating back to the late 70's
and early versions of as(1). So, it's not like tool makers
"suddenly" realized that optimizations could be applied to ASM
code. OTOH, there were lots of schlock assemblers written that
were little more than lexical/syntactic analyzers and easily
confused:
LD HL,(256*HI_BYTE+LOW_BYTE)
was an obvious flaw in the parse for some Z80 assemblers -- should
it be treated as:
VALUE EQU (256*HI_BYTE+LOW_BYTE)
LD HL,VALUE
or:
LD HL,(VALUE)
the two being semantically very different!]

Also, programmers want (and are encouraged) to code symbolically
and avoid "magic constants". So, the previous ASM example could
have been:
LD A,OFFSET
which will be arithmetically applied to (perhaps) an address
computation AT RUNTIME. If the assembler knows OFFSET is "0"
(as a manifest constant), then it can replace the instruction
with one that is more economical (in space AND time!) and,
further, recognize stanzas of code that it can replace with
simpler code sequences (e.g., DIRECTLY use the address that
the code is trying to offset and elide the instructions that
would have done so).

There are also global (most commonly peephole) optimizations
that can be applied by the linkage editor that are outside
the scope of the assembler, itself.

> You seem oblivious that Intel's
> MOV AX,BX
> chooses between two instructions to the discretion of the assembler at hand?
> (not to speak of shorter forms that involves AX only.)
>
> I've made a reverse engineering assembler that allows disassembled code
> to assemble to a copy of the original, obliged to differentiate between
> the two.
> See https://github.com/albertvanderhorst/ciasdis
>
> The two forms are
> MOV, X| T| BX'| R| AX|
> MOV, X| F| AX'| R| BX|
>
> Move primary register AX to secondary register BX using default size (X).
> Move primary register BX from secondary register AX
>
> It is hard to analyse viruses without those finesse.

Viruses deal with machine code. Their authors want to know EXACTLY what
the processor will be executing. Most *programmers* just want the processor
to "achieve a desired result".

Tool makers want their users to find VALUE in their tools, not more
opportunities to introduce bugs!

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.

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.
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

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.
>
> 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.

What term do you apply to tools that take "assembly language"
mnemonics and DON'T generate one-to-one correspondences?
Are these NOT "assemblers"?

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".

On 8/03/2024 9:01 pm, 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.
>>
>> 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.
>
> What term do you apply to tools that take "assembly language"
> mnemonics and DON'T generate one-to-one correspondences?
> Are these NOT "assemblers"?
>
> 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".

It's not an "imagined requirement" of an assembler. It's a description
of the way the original assemblers worked. Compilers came later, and
some of their features got grafted into assemblers that were still being
used to convert low level code into machine code.

The technology changed and the language changed to reflect that. No
imagination involved - except in the design of the up-graded assemblers.

--
Bill Sloman, Sydney