On 5/16/2021 11:12 PM, Spehro Pefhany wrote:
> 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?

*You* tell it.

How do you compute a checksum over a memory space if you don't know
how every location *in* that space will be defined?

Spehro - Dunfield's assembler (which was bought on your good recomendation)
would put nop's into the code before labels if needed to keep the positions
correct. If memory serves, multiple "1st passes" would trim the count of nops.
The # of "1st passes" could be set on the command line.

Hul

Spehro Pefhany <speffSNIP@interlogdotyou.knowwhat> 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.

> --
> Best regards,
> Spehro Pefhany

On Thu, 20 May 2021 20:37:59 +0000 (UTC), Hul Tytus <ht@panix.com>
wrote:

>Spehro - Dunfield's assembler (which was bought on your good recomendation)
>would put nop's into the code before labels if needed to keep the positions
>correct. If memory serves, multiple "1st passes" would trim the count of nops.
>The # of "1st passes" could be set on the command line.
>
>Hul

LOL how many decades ago was that?

--
Best regards,
Spehro Pefhany

On 5/20/2021 1:37 PM, Hul Tytus wrote:
> Spehro - Dunfield's assembler (which was bought on your good recomendation)
> would put nop's into the code before labels if needed to keep the positions
> correct. If memory serves, multiple "1st passes" would trim the count of nops.
> The # of "1st passes" could be set on the command line.

How does the position of the "label" NOT immediately abut the
code that immediately preceded it?

<code1>
<code2>
<code3>
label: <code4>
<code5>

What "magic" would cause a gap to manifest between <code3> and <code4>?

An assembler should only "generate code" (i.e., consume address space)
for sections that have been defined by the programmer.

section CODE
foo: <code1>
<code2>
baz: <code3>

section DATA
bar: <data1>
<data2>

E.g., <data1> has no defined relationship (location-wise) to <code3>.

Additionally, if another module has:

section CODE
phoo: <code11>
<code22>
<code33>

then <code11>'s relationship to <code1> and <code3> is defined in the linkage
editor (depending on how the modules are ordered, foo may precede/follow phoo.

If bar if located (by the linkage editor *or* loader) at an address 0x800000
greater than the end of the CODE section, you don't expect the assembler
to specify values for ANY of those 0x800000 locations in that gap.

Just like:

section VECTORS
vectortable: <vector1>
<vector2>
<vector3>

section CODE
reset: <code0>
...

would allow vectortable and reset to be placed at arbitrary
addresses (at link/load) with NOTHING specified for the
addresses between them.

The contents of that unspecified memory would depend on
something OTHER than the assembler/linker/loader.

[Some really old tools only supported a couple of predefined
sections/segments -- like "code" and "data" -- but the principle
is the same. Where those sections resided was dictated AFTER
the ASM stage]

If, for example, you were burning PROMS, then whatever was
IN those locations when you burned the PROM would remain
(unless your programmer decides to force something into them).

E.g., if your CPU expects a reset vector up near 0xFFFF and
then the lowest *used* address is 0x4000 for a total of 0x1234
bytes, then the range of addresses 0x4000-0x5233 will be
altered along with the few bytes up near 0xFFFF -- the rest of
the address space will be "unaltered". So, if you *want*
something at any of those addresses, you have to explicitly
*tell* the assembler/linker/loader.

If you were dynamically loading the "program" into RAM,
then however the RAM is initialized by (or before) the loader
would determine what resides in those addresses. (e.g.,
memory is often "cleared" prior to being used).

E.g., my "programs" (processes) run in a 64b address space.
But, if the actual code is only a "few KB", then only a
"few KB" of addresses (regardless of how sparsely they may
be located) get "altered" when a program loads (the loader
is told where in that address space each section needs
to reside).

In article <s7r7pu$n34$1@dont-email.me>,
Don Y <blockedofcourse@foo.invalid> wrote:
>On 5/16/2021 6:30 AM, albert wrote:
>> 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

- modify the tool using reverse engineering.

Case in point. One of my job assignments used an old c-compiler
where it was not even known who owned the copyright.
There was a problem though, the embedded software did not longer
fit in the ROMS. I fixed up the c-code but that only went so far.
It seemed impossible to use some other c-compiler because of
extensive libraries that had a different calling convention from the usual.
I managed to use the gnu c-compiler, after modifying said
compiler to use that particular calling convention.

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

Fixing a Microsoft product is probably not feasable, so you had
no choice.

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/21/2021 3:52 PM, albert wrote:
> In article <s7r7pu$n34$1@dont-email.me>,
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/16/2021 6:30 AM, albert wrote:
>>> 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
>
> - modify the tool using reverse engineering.
>
> Case in point. One of my job assignments used an old c-compiler
> where it was not even known who owned the copyright.
> There was a problem though, the embedded software did not longer
> fit in the ROMS. I fixed up the c-code but that only went so far.
> It seemed impossible to use some other c-compiler because of
> extensive libraries that had a different calling convention from the usual.
> I managed to use the gnu c-compiler, after modifying said
> compiler to use that particular calling convention.

But, that's not modifying "the tool"; it's creating a *new* tool
to provide the functionality needed (leveraging some preexisting tool).

E.g., I have added a syntax of:
object=>method(params...)
to my sources. This intentionally mimics the normal
struct->member(...)
syntax. But, handles the case where "object" isn't a pointer to
anything *in* your address space. Rather, it is an *identifier*
that references something in the kernel's address space which,
in turn, references some real code in yet another address space.

[A more banal imlementation would be something like:
method(object_id, params...)
but that means "method" can't easily be overloaded for different
TYPES of objects]

My point being that I can leverage the existing toolchain to
provide this functionality without having to create my own
compiler, etc.

>> 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]
>
> Fixing a Microsoft product is probably not feasable, so you had
> no choice.

Exactly. The 'realization" was that this would, forever, be a
game of wack-a-mole. "Sorry, I'm not keen on playing..."

Instead, identify the problems with a particular toolchain
(you likely already know these if you've used it extensively).
Then, come up with workarounds for those -- and use them
religiously!

Or, pick a new tool that you can *fix* if its maintainers
opt to "abandon" it.