Help, need help with an old 68hc11 assembler !!

no-one@dont-mail-me.com (Robert Scott) wrote in
news:428ce025.28535634@news.provide.net: 

> On Thu, 19 May 2005 12:00:37 -0700, Scott Moore
> <samiamsansspam@Sun.COM> wrote:
> 
>>6811 Assemblers can't be rare. If you're not supported, sounds like
>>time to move to another assembler. You are simply going to relive this
>>pain over and over again until you move.
> 
> The OP said that it was a 10000 line program.  It is likely that
> porting such a program to a different compiler is not likely to be
> trivial.
> 
> 
> -Robert Scott
>  Ypsilanti, Michigan

Howdy,

Well, I ended up spending a few more hours with IDA (the disassembler)
and I'm on track to cracking the secerts of the linker. 

I was hoping to not have to spend the time (and customers money), but
that's the way it goes. We are going to port the whole mess over to new
hardware/processor later this year, but some fast fixes need to be
incorporated. 

BTW, the 68HC11 project is hugh, poorly written, maintained by many and
loaded with pot holes that I hope to not re-visit. The idea of switching
compiler is totally out of the question. 

Some of the early coders had misconceptions about the use of DB and DS
so varaibles sit on top of each other. Later coders found ways to work
around these issues, without fixing the root cause... 

Multiple ring buffers that don't check for space avaliable before
dropping data into it..... and the list goes on..... 

And, it's all stuffed into a medical product that's been around for a
long time...... so don't get sick !!! 

Thanks for the help and suggestions....

DennisB

Robert Scott wrote:
> On Thu, 19 May 2005 12:00:37 -0700, Scott Moore
> <samiamsansspam@Sun.COM> wrote:
> 
> 
>>6811 Assemblers can't be rare. If you're not supported, sounds like time
>>to move to another assembler. You are simply going to relive this
>>pain over and over again until you move.
> 
> 
> The OP said that it was a 10000 line program.  It is likely that
> porting such a program to a different compiler is not likely to be
> trivial.
> 
> 
> -Robert Scott
>  Ypsilanti, Michigan

"assembler", in case that addresses your concern. In case it does not,
yes, I have moved that much assembler code from one assembler to another.
The only thing that should be different is the pseudo-ops, and those
can be searched-replaced by a decent editor.

DennisB wrote:
> no-one@dont-mail-me.com (Robert Scott) wrote in
> news:428ce025.28535634@news.provide.net: 
> 
> 
>>On Thu, 19 May 2005 12:00:37 -0700, Scott Moore
>><samiamsansspam@Sun.COM> wrote:
>>
>>
>>>6811 Assemblers can't be rare. If you're not supported, sounds like
>>>time to move to another assembler. You are simply going to relive this
>>>pain over and over again until you move.
>>
>>The OP said that it was a 10000 line program.  It is likely that
>>porting such a program to a different compiler is not likely to be
>>trivial.
>>
>>
>>-Robert Scott
>> Ypsilanti, Michigan
> 
> 
> Howdy,
> 
> Well, I ended up spending a few more hours with IDA (the disassembler)
> and I'm on track to cracking the secerts of the linker. 
> 
> I was hoping to not have to spend the time (and customers money), but
> that's the way it goes. We are going to port the whole mess over to new
> hardware/processor later this year, but some fast fixes need to be
> incorporated. 
> 
> BTW, the 68HC11 project is hugh, poorly written, maintained by many and
> loaded with pot holes that I hope to not re-visit. The idea of switching
> compiler is totally out of the question. 

Is it assembler, or a compiler ? Please don't call an assembler a compiler.
I have created several of both, and I assure you, there is a big
difference.

I'll assume you are talking about an assembler. These are easy to move.
Since you must eventually end up with a binary load file, you can move
it to a new assembler, then compare the two files for equality, old
and new assembler. The only difference should be the pseudo-ops, which
can be changed easily with a decent editor that has search and replace,
and preferably RE.

> 
> Some of the early coders had misconceptions about the use of DB and DS
> so varaibles sit on top of each other. Later coders found ways to work
> around these issues, without fixing the root cause... 
> 
> Multiple ring buffers that don't check for space avaliable before
> dropping data into it..... and the list goes on..... 

Thats nothing. I once worked at a place where they decided that the "call"
instruction took too much execution time, so forbade all subroutines
in the code.

> 
> And, it's all stuffed into a medical product that's been around for a
> long time...... so don't get sick !!! 
> 
> Thanks for the help and suggestions....
> 
> DennisB
> 

On Thu, 19 May 2005 18:20:43 -0700, Scott Moore
<samiamsansspam@Sun.COM> wrote:

>Robert Scott wrote:
>> On Thu, 19 May 2005 12:00:37 -0700, Scott Moore
>> <samiamsansspam@Sun.COM> wrote:
>> 
>> 
>>>6811 Assemblers can't be rare. If you're not supported, sounds like time
>>>to move to another assembler. You are simply going to relive this
>>>pain over and over again until you move.
>> 
>> 
>> The OP said that it was a 10000 line program.  It is likely that
>> porting such a program to a different compiler is not likely to be
>> trivial.
>> 
>> 
>> -Robert Scott
>>  Ypsilanti, Michigan
>
>"assembler", in case that addresses your concern. In case it does not,
>yes, I have moved that much assembler code from one assembler to another.
>The only thing that should be different is the pseudo-ops, and those
>can be searched-replaced by a decent editor.

   Sometimes (perhaps often) you get lucky like that, but I don't
remeber the 'easy' conversions. I was once given 6805 source code
(maybe only 2k lines, horrible code but the company made money selling
the product) and the assembler for it that ran on an older Macintosh.
I was able to run a Mac simulator in Windows and assemble it, but that
was a lot to go through. I converted it to 2500AD assembler, which
required substantial movement of things from the single-source-file
Mac version. I made separate sections of zero-page variables
(neccesary, else 2500AD would create code with two-byte addressing),
other ram variables, and code, as opposed to wherever they were in the
original. It's been a few years, I forgot doing this until reading
this thread. It took maybe a few days, including reading all the
sections about 'sections' or whatever they were in the 2500AD manual,
but I did get it to assemble to a binary that verified with the
original binary. It's not always trivial.

-----
http://mindspring.com/~benbradley

The OP said the program was old, large, and encrusted with errors and 
workarounds.  It probably relies on bugs or undocumented behavior of the 
assembler too.

DennisB wrote:
> 
... snip ...
> 
> BTW, the 68HC11 project is hugh, poorly written, maintained by
> many and loaded with pot holes that I hope to not re-visit. The
> idea of switching compiler is totally out of the question.
> 
> Some of the early coders had misconceptions about the use of DB
> and DS so varaibles sit on top of each other. Later coders found
> ways to work around these issues, without fixing the root cause...
> 
> Multiple ring buffers that don't check for space avaliable before
> dropping data into it..... and the list goes on.....
> 
> And, it's all stuffed into a medical product that's been around
> for a long time...... so don't get sick !!!

I have seen commercial equipment with hidden hard and software
replace the thoroughly characterized homegrown systems I built in
the 70s and 80s.  My software generally ran with all run-time
checks enabled, including such things as arithmetic overflow, index
ranges, etc.  The replacements also had the advantage of requiring
expensive reagent packages from the vendors.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Ben Bradley wrote:
>>
>>"assembler", in case that addresses your concern. In case it does not,
>>yes, I have moved that much assembler code from one assembler to another.
>>The only thing that should be different is the pseudo-ops, and those
>>can be searched-replaced by a decent editor.
> 
> 
>    Sometimes (perhaps often) you get lucky like that, but I don't
> remeber the 'easy' conversions. I was once given 6805 source code
> (maybe only 2k lines, horrible code but the company made money selling
> the product) and the assembler for it that ran on an older Macintosh.
> I was able to run a Mac simulator in Windows and assemble it, but that
> was a lot to go through. I converted it to 2500AD assembler, which
> required substantial movement of things from the single-source-file
> Mac version. I made separate sections of zero-page variables
> (neccesary, else 2500AD would create code with two-byte addressing),
> other ram variables, and code, as opposed to wherever they were in the
> original. It's been a few years, I forgot doing this until reading
> this thread. It took maybe a few days, including reading all the
> sections about 'sections' or whatever they were in the 2500AD manual,
> but I did get it to assemble to a binary that verified with the
> original binary. It's not always trivial.
> 
> -----
> http://mindspring.com/~benbradley

I'll believe that someone can write an assembly program so bad that
it cannot be ported.

Scott Moore wrote:
> Ben Bradley wrote:
>>>
>>> "assembler", in case that addresses your concern. In case it
>>> does not, yes, I have moved that much assembler code from one
>>> assembler to another. The only thing that should be different
>>> is the pseudo-ops, and those can be searched-replaced by a
>>> decent editor.
>>
>> Sometimes (perhaps often) you get lucky like that, but I don't
>> remeber the 'easy' conversions. I was once given 6805 source
>> code (maybe only 2k lines, horrible code but the company made
>> money selling the product) and the assembler for it that ran on
>> an older Macintosh. I was able to run a Mac simulator in Windows
>> and assemble it, but that was a lot to go through. I converted
>> it to 2500AD assembler, which required substantial movement of
>> things from the single-source-file Mac version. I made separate
>> sections of zero-page variables (neccesary, else 2500AD would
>> create code with two-byte addressing), other ram variables, and
>> code, as opposed to wherever they were in the original. It's
>> been a few years, I forgot doing this until reading this thread.
>> It took maybe a few days, including reading all the sections
>> about 'sections' or whatever they were in the 2500AD manual, but
>> I did get it to assemble to a binary that verified with the
>> original binary. It's not always trivial.
> 
> I'll believe that someone can write an assembly program so bad
> that it cannot be ported.

If you have both the original source and the binary, to prepare to
modify and assemble on another assembler, simply disassemble with a
suitable disassembler and edit the result.  Most of the editing
will be replacing identifiers, such as "L0123" -> "foofaw".  My
id2id-20 package will be very useful for this.  You have an
absolute check by comparing the original binary with the
regenerated binary.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson