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

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.

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

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.

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

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
> 

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.

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

DennisB wrote:
>>>Thanks for the suggestions Jim, but I tried them all....
>>>and spent another hour trying 'dummy' command line options.
>>
>>You could try using the "strings" command (available under Cygwin) to see
>>what text messages are in the executable.
>>
>>    Andrew
> 
> 
> Thanks
> 
> I've tried that and even did a quick disassemble with IDA. 
> 
> The program was written in assembler, using MASM 6 or 7. 
> 
> The options are single letter and are combined with + - @ and
> possibly with * and &. ie /ru-s @3200 -test.h
> 
> I've tried MANY combinations, but still no symbol table.....
> which makes debugging a 10000 line file, a challange.
> 
> At any rate, I was hoping somebody had an old manual, with the command line 
> options hanging around. 

  You could also search for .MAP ( or whatever the HC11 convention is 
for link symbol/map output - do you know if this SW is able to do this.
  Also, if you have full archived project directories, you might find
an example symbol file, and if lucky, the linker command line will be
reported in the top...
  Failing that, another pathway would to be find a HC11 simulator that 
can read the absolute files, and report the symbols.

-jg

On 2005-05-19, Scott Moore <samiamsansspam@Sun.COM> wrote:

> 6811 Assemblers can't be rare.

Indeed not. Gnu binutils supports the 6811/6812 architecture.
It's free (libre and gratis), and it's better supported than
anything other assembler I've ever used.  Gcc supports the
architecture as well, and does a far better job of code
generation that the (admittedly old) commercial compiler I used
to use.

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

Yup.  It'll always be "just one more small change before we EOL
the project."

> I did quick search on "68hc11 assembler", it lit up like a
> Chrismas tree. Including free ones.

-- 
Grant Edwards                   grante             Yow!  I've got to get
                                  at               these SNACK CAKES to NEWARK
                               visi.com            by DAWN!!