Anyone know where on the internet files of programs, or portions
of such, written an Arm assembley can be found? I'm in need
of examples of arm assembly to serve as test code for a just
written assembler.

Hul

torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
> Anyone know where on the internet files of programs, or portions
> of such, written an Arm assembley can be found? I'm in need
> of examples of arm assembly to serve as test code for a just
> written assembler.
>

a google search for "github arm assembly" is probably going to give you plenty of code

On 5/8/2021 6:20 AM, Hul Tytus wrote:
> Anyone know where on the internet files of programs, or portions
> of such, written an Arm assembley can be found? I'm in need
> of examples of arm assembly to serve as test code for a just
> written assembler.

If you're looking for something to exhaustively test your tool,
you'll probably have to write it (inspecting anything you find
will effectively take as much time as creating from scratch)

You might look at some of the FOSS kernels that run under ARM.
It might be a bit of work to extract the code from any (e.g., C)
wrappers (unless you can handle that). E.g., you might DL the
"source" ISO for a recent netBSD and dig through the "arm"-related
kernel sections.

And, if your goal is to be a drop-in replacement for a particular
vendor's ARM toolchain, you'd also need to look at support for
directives, macros, pseudo-ops, etc.

Thanks Lasse. I'll give it a try.

Hul

Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
> > Anyone know where on the internet files of programs, or portions
> > of such, written an Arm assembley can be found? I'm in need
> > of examples of arm assembly to serve as test code for a just
> > written assembler.
> >

> a google search for "github arm assembly" is probably going to give you plenty of code

Don - has netbsd an arm version? I'm writing this from panix.com's
netbsd shell account so your mention of netbsd caught my eye.

Hul

Don Y <blockedofcourse@foo.invalid> wrote:
> On 5/8/2021 6:20 AM, Hul Tytus wrote:
> > Anyone know where on the internet files of programs, or portions
> > of such, written an Arm assembley can be found? I'm in need
> > of examples of arm assembly to serve as test code for a just
> > written assembler.

> If you're looking for something to exhaustively test your tool,
> you'll probably have to write it (inspecting anything you find
> will effectively take as much time as creating from scratch)

> You might look at some of the FOSS kernels that run under ARM.
> It might be a bit of work to extract the code from any (e.g., C)
> wrappers (unless you can handle that). E.g., you might DL the
> "source" ISO for a recent netBSD and dig through the "arm"-related
> kernel sections.

> And, if your goal is to be a drop-in replacement for a particular
> vendor's ARM toolchain, you'd also need to look at support for
> directives, macros, pseudo-ops, etc.

On 5/13/2021 3:30 PM, Hul Tytus wrote:
> Don - has netbsd an arm version? I'm writing this from panix.com's
> netbsd shell account so your mention of netbsd caught my eye.

<http://wiki.netbsd.org/ports/evbarm/> among other references.

I have no idea about running it on "mainstream" (non evaluation board)
hardware your interest is just in the *sources*, right?

If the evbarm port is anything like the others, the sources will NOT
be on the evbarm ISO but, rather, in the "sources":

<http://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/source/sets/>

You're likely only going to find ASM in the "syssrc.tgz" tarball
(the others are userland sources)

[But, if you have a fast enough link, you can check both places]

Can I inquire as to the motivation for building such a tool?

In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>> Anyone know where on the internet files of programs, or portions
>> of such, written an Arm assembley can be found? I'm in need
>> of examples of arm assembly to serve as test code for a just
>> written assembler.
>>
>
>a google search for "github arm assembly" is probably going to give you plenty of code

(I can't answer to the original article.)
This doesn't sound very professional. Random test code doesn't cut it.
You have to make comprehensive tests for your assembler.
If you have tests where your assembler generate binary code,
you only have to disassemble that binary code using a different tool,
e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
Differences have to be investigated. Do not assume GNU has no defects.

See also
https://github.com/albertvanderhorst/ciasdis

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 5/14/2021 5:39 AM, albert wrote:
> In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>>> Anyone know where on the internet files of programs, or portions
>>> of such, written an Arm assembley can be found? I'm in need
>>> of examples of arm assembly to serve as test code for a just
>>> written assembler.
>>>
>>
>> a google search for "github arm assembly" is probably going to give you plenty of code
>
> (I can't answer to the original article.)
> This doesn't sound very professional. Random test code doesn't cut it.
> You have to make comprehensive tests for your assembler.
> If you have tests where your assembler generate binary code,
> you only have to disassemble that binary code using a different tool,
> e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
> Differences have to be investigated. Do not assume GNU has no defects.

Given his stated use, I would imagine a simple comparison of binaries
from <whatever> tool was used, previously, against the output of the
new tool would give a high degree of confidence for the sort of code
that he's encountering.

It's unclear how reliant he/they will be on the tool; if "learned eyes"
will be available to analyze any unexpected behaviors from the execution
of the code, then "close enough" (for a subsequent revision) may be good
enough.

We developed an ASL for a project (early in my career) that leveraged
COTS tools but in user-friendlier ways. It was not uncommon to discover
shortcomings in the "code" generated. But, rather easy to spot those
problems and "fix" our tool, accordingly (within hours of discovering
the problem).

While this *felt* like a huge kluge, the end users were tickled to
have the programmability as the problems tended to be corner cases
that they seldom encountered (and, thus, could pretend didn't exist).

Of course, our rapid turn-around on support made even THOSE tolerable
(it got to be more a case of "Hey! You won't believe what I discovered,
today!" instead of "What a frigging piece of crap!")
tool

In article <s7mh22$e4o$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 5/14/2021 5:39 AM, albert wrote:
>> In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
>> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>>> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>>>> Anyone know where on the internet files of programs, or portions
>>>> of such, written an Arm assembley can be found? I'm in need
>>>> of examples of arm assembly to serve as test code for a just
>>>> written assembler.
>>>>
>>>
>>> a google search for "github arm assembly" is probably going to give you plenty of code
>>
>> (I can't answer to the original article.)
>> This doesn't sound very professional. Random test code doesn't cut it.
>> You have to make comprehensive tests for your assembler.
>> If you have tests where your assembler generate binary code,
>> you only have to disassemble that binary code using a different tool,
>> e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
>> Differences have to be investigated. Do not assume GNU has no defects.
>
>Given his stated use, I would imagine a simple comparison of binaries
>from <whatever> tool was used, previously, against the output of the
>new tool would give a high degree of confidence for the sort of code
>that he's encountering.

I can tell you that comparing binaries where there is a byte inserted
here and there is much more unpleasant than comparing disassemblies.
So I don't thing that will work, because contrary to popular believe
very few assemblers determine exactly how the binary looks. In fact I
believe the one I've written is the only one.
Assemblers generate different outputs nowadays deciding whether a
jump is short or long, or whether an offset can be in a byte,
what opcode to use as a nop, or even more "clever" things.
A case in point, the 8086 and successors contains some 50 instructions
that are one byte duplicates of longer regular instructions.
AMD succesfully hijacked 16 of those to provide a 64 bit i86.
This added even more ambiguity, because a 0x48+## prefix (or 0x40+## prefix for
32 bits code) will be routinely used by compiler writers, and it may not
(will not) be removed if unnecessary.

For the arm the situation is maybe not that extreme, however built-in
shifting and built-in conditionals may make it difficult to assess
ARM instructions.

>
>It's unclear how reliant he/they will be on the tool; if "learned eyes"
>will be available to analyze any unexpected behaviors from the execution
>of the code, then "close enough" (for a subsequent revision) may be good
>enough.
>
>We developed an ASL for a project (early in my career) that leveraged
>COTS tools but in user-friendlier ways. It was not uncommon to discover
>shortcomings in the "code" generated. But, rather easy to spot those
>problems and "fix" our tool, accordingly (within hours of discovering
>the problem).
>
>While this *felt* like a huge kluge, the end users were tickled to
>have the programmability as the problems tended to be corner cases
>that they seldom encountered (and, thus, could pretend didn't exist).
>
>Of course, our rapid turn-around on support made even THOSE tolerable
>(it got to be more a case of "Hey! You won't believe what I discovered,
>today!" instead of "What a frigging piece of crap!")
>tool

I hope your customers are not into mission critical, life critical
applications, but hay.
It is pretty "easy to spot those problems" like airplanes falling
from the sky.

>

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 5/15/2021 6:15 AM, albert wrote:
> In article <s7mh22$e4o$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/14/2021 5:39 AM, albert wrote:
>>> In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
>>> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>>>> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>>>>> Anyone know where on the internet files of programs, or portions
>>>>> of such, written an Arm assembley can be found? I'm in need
>>>>> of examples of arm assembly to serve as test code for a just
>>>>> written assembler.
>>>>>
>>>>
>>>> a google search for "github arm assembly" is probably going to give you plenty of code
>>>
>>> (I can't answer to the original article.)
>>> This doesn't sound very professional. Random test code doesn't cut it.
>>> You have to make comprehensive tests for your assembler.
>>> If you have tests where your assembler generate binary code,
>>> you only have to disassemble that binary code using a different tool,
>>> e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
>>> Differences have to be investigated. Do not assume GNU has no defects.
>>
>> Given his stated use, I would imagine a simple comparison of binaries
>>from <whatever> tool was used, previously, against the output of the
>> new tool would give a high degree of confidence for the sort of code
>> that he's encountering.
>
> I can tell you that comparing binaries where there is a byte inserted
> here and there is much more unpleasant than comparing disassemblies.

You have to ensure the disassembled output generates the same INPUT
format of the *other* assembler. If not, you can't mechanically do
the comparison.

> So I don't thing that will work, because contrary to popular believe
> very few assemblers determine exactly how the binary looks. In fact I
> believe the one I've written is the only one.

If you can't predict what the output will be for a given input,
then you can't ensure any two runs would produce identical outputs.

> Assemblers generate different outputs nowadays deciding whether a
> jump is short or long, or whether an offset can be in a byte,

Yes, but the decisions they make aren't arbitrary. I know the ASM
that I write *relies* on my knowing what the actual output will look
like. I can't ensure a phrase will fit in a cache line if the assembler
has the liberty to "distort" what I've written because it wants to
use a long offset for a jump instead of a short one.

> what opcode to use as a nop, or even more "clever" things.
> A case in point, the 8086 and successors contains some 50 instructions
> that are one byte duplicates of longer regular instructions.
> AMD succesfully hijacked 16 of those to provide a 64 bit i86.
> This added even more ambiguity, because a 0x48+## prefix (or 0x40+## prefix for
> 32 bits code) will be routinely used by compiler writers, and it may not
> (will not) be removed if unnecessary.
>
> For the arm the situation is maybe not that extreme, however built-in
> shifting and built-in conditionals may make it difficult to assess
> ARM instructions.
>
>> It's unclear how reliant he/they will be on the tool; if "learned eyes"
>> will be available to analyze any unexpected behaviors from the execution
>> of the code, then "close enough" (for a subsequent revision) may be good
>> enough.
>>
>> We developed an ASL for a project (early in my career) that leveraged
>> COTS tools but in user-friendlier ways. It was not uncommon to discover
>> shortcomings in the "code" generated. But, rather easy to spot those
>> problems and "fix" our tool, accordingly (within hours of discovering
>> the problem).
>>
>> While this *felt* like a huge kluge, the end users were tickled to
>> have the programmability as the problems tended to be corner cases
>> that they seldom encountered (and, thus, could pretend didn't exist).
>>
>> Of course, our rapid turn-around on support made even THOSE tolerable
>> (it got to be more a case of "Hey! You won't believe what I discovered,
>> today!" instead of "What a frigging piece of crap!")
>> tool
>
> I hope your customers are not into mission critical, life critical
> applications, but hay.

Actually, it was a medical diagnostic instrument. But, you don't
need to put the ASL in the critical data (or processing/control)
path in order for it to offer utility to the technicians using it.

E.g., if I let you programmatically format "reports", a bug might
cause the result to not appear in exactly the format that you'd
intended -- yet doesn't have to alter any of the data reported.
And, it wouldn't bring "production" to a halt as you could still
extract the information of interest.

As with any product, KNOWING your application domain's requirements
is the most important issue.

I worked on a piece of test equipment that had some fairly obvious
implementation flaws (e.g., "Trigger after one second delay"
NEVER triggering!). Yet, folks managed to work around those
fairly easily -- without any "dire consequences" (like airplanes
falling out of the sky).

> It is pretty "easy to spot those problems" like airplanes falling
> from the sky.
>
>>
>
> Groetjes Albert
>

On 5/15/2021 21:31, Don Y wrote:
> On 5/15/2021 6:15 AM, albert wrote:
> .........
>>
>> I can tell you that comparing binaries where there is a byte inserted
>> here and there is much more unpleasant than comparing disassemblies.
>
> You have to ensure the disassembled output generates the same INPUT
> format of the *other* assembler.  If not, you can't mechanically do
> the comparison.

Hi Don,
his approach has an advantage: the binary code is unambiguous, i.e.
the disassembler has no choice but to write the correct opcode.
If the "other" assembler does not understand it it will produce
some error etc., gives you another level of verification.

Could be handy in some cases.

Dimiter

On 5/15/2021 2:03 PM, Dimiter_Popoff wrote:
> On 5/15/2021 21:31, Don Y wrote:
>> On 5/15/2021 6:15 AM, albert wrote:
>> .........
>>>
>>> I can tell you that comparing binaries where there is a byte inserted
>>> here and there is much more unpleasant than comparing disassemblies.
>>
>> You have to ensure the disassembled output generates the same INPUT
>> format of the *other* assembler. If not, you can't mechanically do
>> the comparison.
>
> Hi Don,
> his approach has an advantage: the binary code is unambiguous, i.e.
> the disassembler has no choice but to write the correct opcode.
> If the "other" assembler does not understand it it will produce
> some error etc., gives you another level of verification.
>
> Could be handy in some cases.

The binary is unambiguous. But, can map to many different
syntactic expressions in the *source*.

Letting each assembler interpret the sources in their own
specific context removes this ambiguity.

I recall an early Z80 assembler that would choke on
certain types of expressions as arguments. Specifically,
it saw parentheses as indicative of a *different* opcode.

So, if you wrote:
LD BC,(256*FOO)+BAR
it wouldn't see that as
LD BC,BAR+(256*FOO)
or
BAZ EQU (256*FOO)+BAR
LD BC,BAZ
but, instead, as a "load from memory" reference instead
of "load from immediate data".

If you want to rely on a disassembler, then you have to
disassemble BOTH compiled sources to a (potentially) THIRD syntax
to avoid biasing the result.

You'd not care to recover *either* source as much would
be lost by the compile/decompile processes. E.g., the
above code would disassemble to something like
LD BC,0x2188

Hul apparently *has* working sources for at least a product
or two. It seems logical that he would first try to compile
those with his "new" assembler. And, look into any differences
that appear in the binary -- as the "new" binary might not
execute in the same way as the old.

And, if his goal is:
"Don, the objective is a small assembler for in-house use and
to be included with some equipment with arm processors. Some
list files for checking the immediate and branching calculations
and placements would be handy."
then those things that will likely use the tool seem ideal candidates!

On 5/16/2021 0:54, Don Y wrote:
> On 5/15/2021 2:03 PM, Dimiter_Popoff wrote:
>> On 5/15/2021 21:31, Don Y wrote:
>>> On 5/15/2021 6:15 AM, albert wrote:
>>> .........
>>>>
>>>> I can tell you that comparing binaries where there is a byte inserted
>>>> here and there is much more unpleasant than comparing disassemblies.
>>>
>>> You have to ensure the disassembled output generates the same INPUT
>>> format of the *other* assembler.  If not, you can't mechanically do
>>> the comparison.
>>
>> Hi Don,
>> his approach has an advantage: the binary code is unambiguous, i.e.
>> the disassembler has no choice but to write the correct opcode.
>> If the "other" assembler does not understand it it will produce
>> some error etc., gives you another level of verification.
>>
>> Could be handy in some cases.
>
> The binary is unambiguous.  But, can map to many different
> syntactic expressions in the *source*.
>
> Letting each assembler interpret the sources in their own
> specific context removes this ambiguity.
>
> I recall an early Z80 assembler that would choke on
> certain types of expressions as arguments.  Specifically,
> it saw parentheses as indicative of a *different* opcode.
>
> So, if you wrote:
>     LD BC,(256*FOO)+BAR
> it wouldn't see that as
>     LD BC,BAR+(256*FOO)
> or
>     BAZ  EQU (256*FOO)+BAR
>     LD BC,BAZ
> but, instead, as a "load from memory" reference instead
> of "load from immediate data".
>
> If you want to rely on a disassembler, then you have to
> disassemble BOTH compiled sources to a (potentially) THIRD syntax
> to avoid biasing the result.
>
> You'd not care to recover *either* source as much would
> be lost by the compile/decompile processes.  E.g., the
> above code would disassemble to something like
>     LD BC,0x2188
>
> Hul apparently *has* working sources for at least a product
> or two.  It seems logical that he would first try to compile
> those with his "new" assembler.  And, look into any differences
> that appear in the binary -- as the "new" binary might not
> execute in the same way as the old.
>
> And, if his goal is:
>    "Don, the objective is a small assembler for in-house use and
>     to be included with some equipment with arm processors. Some
>     list files for checking the immediate and branching calculations
>     and placements would be handy."
> then those things that will likely use the tool seem ideal candidates!

Don,
of course I am aware of all that, I just thought the unambiguous
nature of the binary could be exploited at times. Probably because
I am not really into checking other people's tools, you know I
use exclusively my own ones, and it had not occurred to me as
a potential use.
Not that I have not written a disassembler for power and, earlier,
for cpu32.
Try to feed the output of my power disassembler to vpa,
LOL. With the same success you can try to feed it to a fortran
compiler or something... :-). The cpu32 was pretty close though,
guess it would have worked mostly (never been tried) with my a32
assembler for cpu32.

On 5/15/2021 3:06 PM, Dimiter_Popoff wrote:
> of course I am aware of all that, I just thought the unambiguous
> nature of the binary could be exploited at times. Probably because
> I am not really into checking other people's tools, you know I
> use exclusively my own ones, and it had not occurred to me as
> a potential use.

You are likely lucky, in that regard. On the one hand, you are
reliant on having (or making) each tool that you need. On the other,
you KNOW how the tool works and can fix/alter it, as required.
(this isn't always possible with other folks' tools)

> Not that I have not written a disassembler for power and, earlier,
> for cpu32.
> Try to feed the output of my power disassembler to vpa,
> LOL. With the same success you can try to feed it to a fortran
> compiler or something... :-). The cpu32 was pretty close though,
> guess it would have worked mostly (never been tried) with my a32
> assembler for cpu32.

The "problem" with ASM source is that it's not really constrained/defined
for any particular processor. Unlike HLLs that *tend* to adhere to
some "published standard", ASMs can support all sorts of syntactic
variations. (this is why I prefer to code in HLLs and AVOID any
specific "extensions" that the vendor may think will "help" me)

[And, your VPA is an entirely different "beast"!]

"Porting" ASM from one tool to another is boring and ripe for
careless errors. Do I build a tool to assist with the port?
Or, is this small enough that I can just plow through it and finish
with less total effort expended?

I've had to work with disassembled code (client "lost" his sources).
It was a dreadful experience. There's so much information in the
source that isn't in the binary. And, even small differences
in "original ASM" vs. "disassembled ASM" can be... "tedious" to
deal with.

Additionally, *decompiled* code often has a more consistent
structure; the compiler does things in largely the same way
from instance to instance. By contrast, assembled code can
take an entirely different approach from one statement to the
next. So, you can't assume you know "what's coming"... until
it's past! :<

On 5/16/2021 1:19, Don Y wrote:
> On 5/15/2021 3:06 PM, Dimiter_Popoff wrote:
>> of course I am aware of all that, I just thought the unambiguous
>> nature of the binary could be exploited at times. Probably because
>> I am not really into checking other people's tools, you know I
>> use exclusively my own ones, and it had not occurred to me as
>> a potential use.
>
> You are likely lucky, in that regard.  On the one hand, you are
> reliant on having (or making) each tool that you need.  On the other,
> you KNOW how the tool works and can fix/alter it, as required.
> (this isn't always possible with other folks' tools)
>

I think I have been lucky to go this way indeed. Has been a
huge productivity boost for me and has helped me stay on course.
Now where this course has got me to is another matter but
the closer to the end of life we get the more we realize it
is has been about the course, not the end goal :-).

On 5/15/2021 5:21 PM, Dimiter_Popoff wrote:
> On 5/16/2021 1:19, Don Y wrote:
>> On 5/15/2021 3:06 PM, Dimiter_Popoff wrote:
>>> of course I am aware of all that, I just thought the unambiguous
>>> nature of the binary could be exploited at times. Probably because
>>> I am not really into checking other people's tools, you know I
>>> use exclusively my own ones, and it had not occurred to me as
>>> a potential use.
>>
>> You are likely lucky, in that regard. On the one hand, you are
>> reliant on having (or making) each tool that you need. On the other,
>> you KNOW how the tool works and can fix/alter it, as required.
>> (this isn't always possible with other folks' tools)
>
> I think I have been lucky to go this way indeed. Has been a
> huge productivity boost for me and has helped me stay on course.

I think the fact that *you* make the decisions as to how YOUR work
is done is the biggest win -- even if you adopted COTS tools.
You're not subject to the "whims" of your peers, bosses, etc.

Here, one of the drains on efficiency is software upgrades,
OS upgrades, etc. In addition to taking time away from
"productive" activities, they also introduce the potential for
having to relearn something (that now works slightly differently).

Way back in the early "visual C++" days, (maybe even just prior?)
I had purchased <whatever> tool from MS. In the course of my
work, I stumbled on a bug in the compiler (something like calling
a member function through a pointer).

The MS droid verified the bug was real. Informed me that there was no
patch available. *But*, gleefully informed me that I could upgrade
to the NEWER product at no charge (or, maybe some nominal charge).

That was the end of my MS experiences. I have no desire to
be someone's UNPAID "test department"!

> Now where this course has got me to is another matter but
> the closer to the end of life we get the more we realize it
> is has been about the course, not the end goal :-).

You and I are lucky in that we can choose how to spend our days.
And, appear to enjoy the choices we've made.

This isn't the case for many who either have financial pressures,
family issues, skillset constraints, etc.

In article <s7p41q$2jl$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 5/15/2021 6:15 AM, albert wrote:
>> In article <s7mh22$e4o$1@dont-email.me>,
>> Don Y <blockedofcourse@foo.invalid> wrote:
>>> On 5/14/2021 5:39 AM, albert wrote:
>>>> In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
>>>> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>>>>> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>>>>>> Anyone know where on the internet files of programs, or portions
>>>>>> of such, written an Arm assembley can be found? I'm in need
>>>>>> of examples of arm assembly to serve as test code for a just
>>>>>> written assembler.
>>>>>>
>>>>>
>>>>> a google search for "github arm assembly" is probably going to give you plenty of code
>>>>
>>>> (I can't answer to the original article.)
>>>> This doesn't sound very professional. Random test code doesn't cut it.
>>>> You have to make comprehensive tests for your assembler.
>>>> If you have tests where your assembler generate binary code,
>>>> you only have to disassemble that binary code using a different tool,
>>>> e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
>>>> Differences have to be investigated. Do not assume GNU has no defects.
>>>
>>> Given his stated use, I would imagine a simple comparison of binaries
>>>from <whatever> tool was used, previously, against the output of the
>>> new tool would give a high degree of confidence for the sort of code
>>> that he's encountering.
>>
>> I can tell you that comparing binaries where there is a byte inserted
>> here and there is much more unpleasant than comparing disassemblies.
>
>You have to ensure the disassembled output generates the same INPUT
>format of the *other* assembler. If not, you can't mechanically do
>the comparison.

You can't do a mechanical comparison, full stop.
You can't ensure the disassembled output for two assemblers are the
same, at least not for 8086.

>
>> So I don't thing that will work, because contrary to popular believe
>> very few assemblers determine exactly how the binary looks. In fact I
>> believe the one I've written is the only one.
>
>If you can't predict what the output will be for a given input,
>then you can't ensure any two runs would produce identical outputs.

So you should not rely on that.

<SNIP>

>> Groetjes Albert
>>
>
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <s7pfv8$q7r$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 5/15/2021 2:03 PM, Dimiter_Popoff wrote:
>> On 5/15/2021 21:31, Don Y wrote:
>>> On 5/15/2021 6:15 AM, albert wrote:
>>> .........
>>>>
>>>> I can tell you that comparing binaries where there is a byte inserted
>>>> here and there is much more unpleasant than comparing disassemblies.
>>>
>>> You have to ensure the disassembled output generates the same INPUT
>>> format of the *other* assembler. If not, you can't mechanically do
>>> the comparison.
>>
>> Hi Don,
>> his approach has an advantage: the binary code is unambiguous, i.e.
>> the disassembler has no choice but to write the correct opcode.
>> If the "other" assembler does not understand it it will produce
>> some error etc., gives you another level of verification.
>>
>> Could be handy in some cases.
>
>The binary is unambiguous. But, can map to many different
>syntactic expressions in the *source*.
>
>Letting each assembler interpret the sources in their own
>specific context removes this ambiguity.
>
>I recall an early Z80 assembler that would choke on
>certain types of expressions as arguments. Specifically,
>it saw parentheses as indicative of a *different* opcode.
>
>So, if you wrote:
> LD BC,(256*FOO)+BAR
>it wouldn't see that as
> LD BC,BAR+(256*FOO)
>or
> BAZ EQU (256*FOO)+BAR
> LD BC,BAZ
>but, instead, as a "load from memory" reference instead
>of "load from immediate data".
>
>If you want to rely on a disassembler, then you have to
>disassemble BOTH compiled sources to a (potentially) THIRD syntax
>to avoid biasing the result.
>
>You'd not care to recover *either* source as much would
>be lost by the compile/decompile processes. E.g., the
>above code would disassemble to something like
> LD BC,0x2188
>
>Hul apparently *has* working sources for at least a product
>or two. It seems logical that he would first try to compile
>those with his "new" assembler. And, look into any differences
>that appear in the binary -- as the "new" binary might not
>execute in the same way as the old.
>
>And, if his goal is:
> "Don, the objective is a small assembler for in-house use and
> to be included with some equipment with arm processors. Some
> list files for checking the immediate and branching calculations
> and placements would be handy."
>then those things that will likely use the tool seem ideal candidates!

Reality check. Assembler representations of the same program depend
wildly on the assembler used.

The site
https://github.com/albertvanderhorst/ciforth
contains a generating system for different compilers (MS windows,linux,
MSDOS, 16/32/64). The system can accommodate different assemblers,
..asm is nasm
..msm is microsoft
..s is gas
..fas is fasm

nasm is closest to the official Intel syntax.

I will report only on the source for the 64 bit linux version.
So I did my utmost to have the sources equivalent over different
assemblers.

Check as per
wc -l $s.asm
diff -b -B $s.s $s.asm |wc -l
diff -b -B $s.msm $s.asm |wc -l
diff -b -B $s.fas $s.asm |wc -l
with output
11064 ci86.lina64.asm
21709
5343
1095

Even if discounted for the dramatic differences if the comment symbol
is not the same, the differences are substantial.

Of course I did not introduce gratuitous differences. I would love
to have the comment, allocation, equates etc. work the same in all sources.

P.S.
(There was a time that gas had src,dst (gnu compatible) instead of
dst,src (intel compatible). If anything that should be a convincing example.)

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 5/16/2021 4:45 AM, albert wrote:
> In article <s7p41q$2jl$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/15/2021 6:15 AM, albert wrote:
>>> In article <s7mh22$e4o$1@dont-email.me>,
>>> Don Y <blockedofcourse@foo.invalid> wrote:
>>>> On 5/14/2021 5:39 AM, albert wrote:
>>>>> In article <9c663ab9-64d6-48ae-a9d7-db8ad66d0d34n@googlegroups.com>,
>>>>> Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
>>>>>> torsdag den 13. maj 2021 kl. 03.16.06 UTC+2 skrev Hul Tytus:
>>>>>>> Anyone know where on the internet files of programs, or portions
>>>>>>> of such, written an Arm assembley can be found? I'm in need
>>>>>>> of examples of arm assembly to serve as test code for a just
>>>>>>> written assembler.
>>>>>>>
>>>>>>
>>>>>> a google search for "github arm assembly" is probably going to give you plenty of code
>>>>>
>>>>> (I can't answer to the original article.)
>>>>> This doesn't sound very professional. Random test code doesn't cut it.
>>>>> You have to make comprehensive tests for your assembler.
>>>>> If you have tests where your assembler generate binary code,
>>>>> you only have to disassemble that binary code using a different tool,
>>>>> e.g. the disassembler of the ubiquitous GNU arm toolchain, and compare.
>>>>> Differences have to be investigated. Do not assume GNU has no defects.
>>>>
>>>> Given his stated use, I would imagine a simple comparison of binaries
>>> >from <whatever> tool was used, previously, against the output of the
>>>> new tool would give a high degree of confidence for the sort of code
>>>> that he's encountering.
>>>
>>> I can tell you that comparing binaries where there is a byte inserted
>>> here and there is much more unpleasant than comparing disassemblies.
>>
>> You have to ensure the disassembled output generates the same INPUT
>> format of the *other* assembler. If not, you can't mechanically do
>> the comparison.
>
> You can't do a mechanical comparison, full stop.
> You can't ensure the disassembled output for two assemblers are the
> same, at least not for 8086.

I don't see "8086" mentioned in the subject line. Is there something
wrong with the copy of his post that my news server provided to me?

In article <s7pq06$n75$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 5/15/2021 5:21 PM, Dimiter_Popoff wrote:
>> On 5/16/2021 1:19, Don Y wrote:
>>> On 5/15/2021 3:06 PM, Dimiter_Popoff wrote:
>>>> of course I am aware of all that, I just thought the unambiguous
>>>> nature of the binary could be exploited at times. Probably because
>>>> I am not really into checking other people's tools, you know I
>>>> use exclusively my own ones, and it had not occurred to me as
>>>> a potential use.
>>>
>>> You are likely lucky, in that regard. On the one hand, you are
>>> reliant on having (or making) each tool that you need. On the other,
>>> you KNOW how the tool works and can fix/alter it, as required.
>>> (this isn't always possible with other folks' tools)
>>
>> I think I have been lucky to go this way indeed. Has been a
>> huge productivity boost for me and has helped me stay on course.
>
>I think the fact that *you* make the decisions as to how YOUR work
>is done is the biggest win -- even if you adopted COTS tools.
>You're not subject to the "whims" of your peers, bosses, etc.
>
>Here, one of the drains on efficiency is software upgrades,
>OS upgrades, etc. In addition to taking time away from
>"productive" activities, they also introduce the potential for
>having to relearn something (that now works slightly differently).

My primary concern is the introduction of new defects ("bugs").

>Way back in the early "visual C++" days, (maybe even just prior?)
>I had purchased <whatever> tool from MS. In the course of my
>work, I stumbled on a bug in the compiler (something like calling
>a member function through a pointer).
>
>The MS droid verified the bug was real. Informed me that there was no
>patch available. *But*, gleefully informed me that I could upgrade
>to the NEWER product at no charge (or, maybe some nominal charge).

This is the reason for having minor upgrades on top of stable
versions.

groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 5/16/2021 6:26 AM, albert wrote:
> In article <s7pfv8$q7r$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/15/2021 2:03 PM, Dimiter_Popoff wrote:
>>> On 5/15/2021 21:31, Don Y wrote:
>>>> On 5/15/2021 6:15 AM, albert wrote:
>>>> .........
>>>>>
>>>>> I can tell you that comparing binaries where there is a byte inserted
>>>>> here and there is much more unpleasant than comparing disassemblies.
>>>>
>>>> You have to ensure the disassembled output generates the same INPUT
>>>> format of the *other* assembler. If not, you can't mechanically do
>>>> the comparison.
>>>
>>> Hi Don,
>>> his approach has an advantage: the binary code is unambiguous, i.e.
>>> the disassembler has no choice but to write the correct opcode.
>>> If the "other" assembler does not understand it it will produce
>>> some error etc., gives you another level of verification.
>>>
>>> Could be handy in some cases.
>>
>> The binary is unambiguous. But, can map to many different
>> syntactic expressions in the *source*.
>>
>> Letting each assembler interpret the sources in their own
>> specific context removes this ambiguity.
>>
>> I recall an early Z80 assembler that would choke on
>> certain types of expressions as arguments. Specifically,
>> it saw parentheses as indicative of a *different* opcode.
>>
>> So, if you wrote:
>> LD BC,(256*FOO)+BAR
>> it wouldn't see that as
>> LD BC,BAR+(256*FOO)
>> or
>> BAZ EQU (256*FOO)+BAR
>> LD BC,BAZ
>> but, instead, as a "load from memory" reference instead
>> of "load from immediate data".
>>
>> If you want to rely on a disassembler, then you have to
>> disassemble BOTH compiled sources to a (potentially) THIRD syntax
>> to avoid biasing the result.
>>
>> You'd not care to recover *either* source as much would
>> be lost by the compile/decompile processes. E.g., the
>> above code would disassemble to something like
>> LD BC,0x2188
>>
>> Hul apparently *has* working sources for at least a product
>> or two. It seems logical that he would first try to compile
>> those with his "new" assembler. And, look into any differences
>> that appear in the binary -- as the "new" binary might not
>> execute in the same way as the old.
>>
>> And, if his goal is:
>> "Don, the objective is a small assembler for in-house use and
>> to be included with some equipment with arm processors. Some
>> list files for checking the immediate and branching calculations
>> and placements would be handy."
>> then those things that will likely use the tool seem ideal candidates!
>
> Reality check. Assembler representations of the same program depend
> wildly on the assembler used.

Did you not hear me when *I* made that very same statement to Dimiter?
My comment regarding "porting" between assemblers for the same processor?

> The site
> https://github.com/albertvanderhorst/ciforth
> contains a generating system for different compilers (MS windows,linux,
> MSDOS, 16/32/64). The system can accommodate different assemblers,
> .asm is nasm
> .msm is microsoft
> .s is gas
> .fas is fasm
>
> nasm is closest to the official Intel syntax.
>
> I will report only on the source for the 64 bit linux version.
> So I did my utmost to have the sources equivalent over different
> assemblers.
>
> Check as per
> wc -l $s.asm
> diff -b -B $s.s $s.asm |wc -l
> diff -b -B $s.msm $s.asm |wc -l
> diff -b -B $s.fas $s.asm |wc -l
> with output
> 11064 ci86.lina64.asm
> 21709
> 5343
> 1095
>
> Even if discounted for the dramatic differences if the comment symbol
> is not the same, the differences are substantial.
>
> Of course I did not introduce gratuitous differences. I would love
> to have the comment, allocation, equates etc. work the same in all sources.
>
> P.S.
> (There was a time that gas had src,dst (gnu compatible) instead of
> dst,src (intel compatible). If anything that should be a convincing example.)
>
> Groetjes Albert
>

On 5/16/2021 6:30 AM, albert wrote:
> In article <s7pq06$n75$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/15/2021 5:21 PM, Dimiter_Popoff wrote:
>>> On 5/16/2021 1:19, Don Y wrote:
>>>> On 5/15/2021 3:06 PM, Dimiter_Popoff wrote:
>>>>> of course I am aware of all that, I just thought the unambiguous
>>>>> nature of the binary could be exploited at times. Probably because
>>>>> I am not really into checking other people's tools, you know I
>>>>> use exclusively my own ones, and it had not occurred to me as
>>>>> a potential use.
>>>>
>>>> You are likely lucky, in that regard. On the one hand, you are
>>>> reliant on having (or making) each tool that you need. On the other,
>>>> you KNOW how the tool works and can fix/alter it, as required.
>>>> (this isn't always possible with other folks' tools)
>>>
>>> I think I have been lucky to go this way indeed. Has been a
>>> huge productivity boost for me and has helped me stay on course.
>>
>> I think the fact that *you* make the decisions as to how YOUR work
>> is done is the biggest win -- even if you adopted COTS tools.
>> You're not subject to the "whims" of your peers, bosses, etc.
>>
>> Here, one of the drains on efficiency is software upgrades,
>> OS upgrades, etc. In addition to taking time away from
>> "productive" activities, they also introduce the potential for
>> having to relearn something (that now works slightly differently).
>
> My primary concern is the introduction of new defects ("bugs").
>
>> Way back in the early "visual C++" days, (maybe even just prior?)
>> I had purchased <whatever> tool from MS. In the course of my
>> work, I stumbled on a bug in the compiler (something like calling
>> a member function through a pointer).
>>
>> The MS droid verified the bug was real. Informed me that there was no
>> patch available. *But*, gleefully informed me that I could upgrade
>> to the NEWER product at no charge (or, maybe some nominal charge).
>
> This is the reason for having minor upgrades on top of stable
> versions.

If the vendor won't provide an upgrade to the version you have
(as was the case in the example I provided, above), then you
are forced to either:
- live with what you have
- update to the new version/product
- pick a new vendor/product

If I am developing something new (hardware, software, documentation),
then I *might* be able to tolerate a "change" -- what I have at the
time isn't final and, presumably, I can notice any deviation in performance
over *my* working set.

A DTP product changed how it would layout the page from one version to
the next. With several hundred pages of finished documentation behind
me, I wasn't keen on having to manually *tweek* each of those pages to
ensure page-breaks, paragraph breaks, flows, illustrations, etc. would
all end up "where they used to".

So, I simply chose to live with the (now known) problems in the previous
version -- at least until the project was complete (and make a note
not to use the upgraded tool on any future work on it)

If, OTOH, I am supporting some existing "product" (hardware, software,
documentation), then there is usually too much risk to making such a change
*if* I can work-around any existing problems in the old tool.

I maintain VMs of each required guest OS with these apps preinstalled.
So, if client X needs some work done on a project I designed for him,
I can start up the VM that hosts the toolchain that I was using when
I last worked on his product. Because I will have made a commitment
to make the changes in a certain time/money budget and can't factor
in the potential cost of some newer version of "his" toolchain not
working as memory suggests it would.

[I've had clients update their tools and then want me to make
some changes with their new tools -- only to accept the job by using
their *old* tools ("But, those ran on W98!" "Yeah? And I've got a
W98 machine, here, with them installed.") This is both a blessing
and a curse -- as it allows them to drop stuff in my lap solely
because they didn't maintain a proper development environment]

On Sun, 16 May 2021 00:03:17 +0300, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 5/15/2021 21:31, Don Y wrote:
>> On 5/15/2021 6:15 AM, albert wrote:
>> .........
>>>
>>> I can tell you that comparing binaries where there is a byte inserted
>>> here and there is much more unpleasant than comparing disassemblies.
>>
>> You have to ensure the disassembled output generates the same INPUT
>> format of the *other* assembler.  If not, you can't mechanically do
>> the comparison.
>
>Hi Don,
>his approach has an advantage: the binary code is unambiguous, i.e.
>the disassembler has no choice but to write the correct opcode.
>If the "other" assembler does not understand it it will produce
>some error etc., gives you another level of verification.
>
>Could be handy in some cases.
>
>Dimiter
>

I remember porting some substantial code to a new assembler (there
were a *lot* of syntactical differences. It also spit out somewhat
different hex code even when it was working perfectly, something about
the way gaps in memory were dealt with differed, so I had to write a
simple program to do a meaningful comparison. The name Dunfield comes
to mind.

--
Best regards,
Spehro Pefhany

On 5/16/2021 9:10 AM, Spehro Pefhany wrote:
> On Sun, 16 May 2021 00:03:17 +0300, Dimiter_Popoff <dp@tgi-sci.com>
> wrote:
>
>> On 5/15/2021 21:31, Don Y wrote:
>>> On 5/15/2021 6:15 AM, albert wrote:
>>> .........
>>>>
>>>> I can tell you that comparing binaries where there is a byte inserted
>>>> here and there is much more unpleasant than comparing disassemblies.
>>>
>>> You have to ensure the disassembled output generates the same INPUT
>>> format of the *other* assembler. If not, you can't mechanically do
>>> the comparison.
>>
>> Hi Don,
>> his approach has an advantage: the binary code is unambiguous, i.e.
>> the disassembler has no choice but to write the correct opcode.
>> If the "other" assembler does not understand it it will produce
>> some error etc., gives you another level of verification.
>>
>> Could be handy in some cases.
>>
>> Dimiter
>
> I remember porting some substantial code to a new assembler (there
> were a *lot* of syntactical differences. It also spit out somewhat
> different hex code even when it was working perfectly, something about
> the way gaps in memory were dealt with differed, so I had to write a
> simple program to do a meaningful comparison. The name Dunfield comes
> to mind.

Then you either didn't have the code residing in the same places
*or* your mapping of instructions was faulty and possibly neglected
some assembler directive that changed the assembler's context.
(or, the "new"/old assembler was broken in some way)

A port should yield the same binary. If you don't have the same
binary, you don't have the same *product*. I.e., all of the
assumptions/verifications you made on the preported version are
now suspect. In a regulated industry, you would have to repeat the
validation effort. Tell the guys at the FAA that this is the
exact same SOURCE code as the previous validated version -- even
though the binary is visibly different -- and see how accommodating
they'll be!

MAME tries to recreate various different hardware environments
to host legacy video game code by emulating the various processors
that were used (decades ago) on modern, faster commodity systems.
There are similar "emulators".

But, they only emulate the functionality of the code -- the EXACT timing
of those instruction sequences isn't faithfully reproduced. (actually,
I don't know if this is still true, today; making a cycle-accurate emulator
is considerably harder than just reproducing basic functionality in a
particular LARGE slice of time so the effort and MIPS required is
higher)

<https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/>

(see ~paragraph 5)

Clearly, the emulated game (mentioned above) is *different* from the
original game. A useful feature (for the player) has been lost due to the
variation in timing between emulated instruction sequences and REAL
instructions (on the original hardware).

"<shrug> It's just a game..."

This sort of problem is actually MORE acute in modern hardware -- because
of all of the "acceleration" built into that hardware. If a source code
sequence translates into a binary that takes a different amount of time
to execute -- or, alters the physical positions of instructions/data -- then
the code will execute differently.

In a real-time system, timing differences can change scheduling decisions
to favor one "task" over a task that may have been previously favored.
A race that previously never manifested can suddenly "fail" every time!

Changes in instruction/data placement can cause differences in cache
utilization -- an "extra" line may be needed to hold something that
previously "fit" into one fewer cache line. So, the time required to
execute code changes because the cache's contents are no longer faithfully
reproduced from their original form. Shifting a location across a
page boundary can cause an extra page miss -- or, even thrashing if the
code hops back and forth across that page boundary (which previously
wasn't a factor in execution). Or, extra TLB misses to access "other"
resources that had previously fit into the same page set.

Note that we're not talking about *one* such mismatch but, rather,
the potential for *many*. And, in many different (unexpected?)
places. (if comparing binaries is hard, imagine how hard it would be
to figure out where the "new" performance would have to be revalidated!

If you're writing single-threaded desktop code, you'll likely never
see a problem. But, if you're writing code that will run in an
embedded/RT environment, all bets are off. Call it "version 2" and
repeat the entire regression/testing suite.

On Sun, 16 May 2021 13:24:51 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 5/16/2021 9:10 AM, Spehro Pefhany wrote:
>> On Sun, 16 May 2021 00:03:17 +0300, Dimiter_Popoff <dp@tgi-sci.com>
>> wrote:
>>
>>> On 5/15/2021 21:31, Don Y wrote:
>>>> On 5/15/2021 6:15 AM, albert wrote:
>>>> .........
>>>>>
>>>>> I can tell you that comparing binaries where there is a byte inserted
>>>>> here and there is much more unpleasant than comparing disassemblies.
>>>>
>>>> You have to ensure the disassembled output generates the same INPUT
>>>> format of the *other* assembler. If not, you can't mechanically do
>>>> the comparison.
>>>
>>> Hi Don,
>>> his approach has an advantage: the binary code is unambiguous, i.e.
>>> the disassembler has no choice but to write the correct opcode.
>>> If the "other" assembler does not understand it it will produce
>>> some error etc., gives you another level of verification.
>>>
>>> Could be handy in some cases.
>>>
>>> Dimiter
>>
>> I remember porting some substantial code to a new assembler (there
>> were a *lot* of syntactical differences. It also spit out somewhat
>> different hex code even when it was working perfectly, something about
>> the way gaps in memory were dealt with differed, so I had to write a
>> simple program to do a meaningful comparison. The name Dunfield comes
>> to mind.
>
>Then you either didn't have the code residing in the same places
>*or* your mapping of instructions was faulty and possibly neglected
>some assembler directive that changed the assembler's context.
>(or, the "new"/old assembler was broken in some way)
>
>A port should yield the same binary. If you don't have the same
>binary, you don't have the same *product*.

How do you define the "same binary"? Is the gap between interrupt
vectors and program start filled with 0x00, 0xFF or left undefined?

>I.e., all of the
>assumptions/verifications you made on the preported version are
>now suspect. In a regulated industry, you would have to repeat the
>validation effort. Tell the guys at the FAA that this is the
>exact same SOURCE code as the previous validated version -- even
>though the binary is visibly different -- and see how accommodating
>they'll be!

>MAME tries to recreate various different hardware environments
>to host legacy video game code by emulating the various processors
>that were used (decades ago) on modern, faster commodity systems.
>There are similar "emulators".
>
>But, they only emulate the functionality of the code -- the EXACT timing
>of those instruction sequences isn't faithfully reproduced. (actually,
>I don't know if this is still true, today; making a cycle-accurate emulator
>is considerably harder than just reproducing basic functionality in a
>particular LARGE slice of time so the effort and MIPS required is
>higher)
>
><https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/>
>
>(see ~paragraph 5)
>
>Clearly, the emulated game (mentioned above) is *different* from the
>original game. A useful feature (for the player) has been lost due to the
>variation in timing between emulated instruction sequences and REAL
>instructions (on the original hardware).
>
>"<shrug> It's just a game..."
>
>This sort of problem is actually MORE acute in modern hardware -- because
>of all of the "acceleration" built into that hardware. If a source code
>sequence translates into a binary that takes a different amount of time
>to execute -- or, alters the physical positions of instructions/data -- then
>the code will execute differently.
>
>In a real-time system, timing differences can change scheduling decisions
>to favor one "task" over a task that may have been previously favored.
>A race that previously never manifested can suddenly "fail" every time!
>
>Changes in instruction/data placement can cause differences in cache
>utilization -- an "extra" line may be needed to hold something that
>previously "fit" into one fewer cache line. So, the time required to
>execute code changes because the cache's contents are no longer faithfully
>reproduced from their original form. Shifting a location across a
>page boundary can cause an extra page miss -- or, even thrashing if the
>code hops back and forth across that page boundary (which previously
>wasn't a factor in execution). Or, extra TLB misses to access "other"
>resources that had previously fit into the same page set.
>
>Note that we're not talking about *one* such mismatch but, rather,
>the potential for *many*. And, in many different (unexpected?)
>places. (if comparing binaries is hard, imagine how hard it would be
>to figure out where the "new" performance would have to be revalidated!
>
>If you're writing single-threaded desktop code, you'll likely never
>see a problem. But, if you're writing code that will run in an
>embedded/RT environment, all bets are off. Call it "version 2" and
>repeat the entire regression/testing suite.
--
Best regards,
Spehro Pefhany