Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8821 > unrolled thread

13 year old C source code

Back to article view | Back to comp.lang.c

Contents

  13 year old C source code buck <buck@private.mil> - 2011-07-28 19:04 +0000
    Re: 13 year old C source code jacob navia <jacob@spamsink.net> - 2011-07-28 21:30 +0200
      Re: 13 year old C source code Francois Grieu <fgrieu@gmail.com> - 2011-07-28 21:35 +0200
        Re: 13 year old C source code jacob navia <jacob@spamsink.net> - 2011-07-28 21:48 +0200
          Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 13:37 -0700
      Re: 13 year old C source code buck <buck@private.mil> - 2011-07-28 20:28 +0000
    Re: 13 year old C source code Francois Grieu <fgrieu@gmail.com> - 2011-07-28 21:31 +0200
    Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 13:00 -0700
      Re: 13 year old C source code "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-07-28 18:10 -0400
        Re: 13 year old C source code Keith Thompson <kst-u@mib.org> - 2011-07-28 15:27 -0700
    Re: 13 year old C source code Rich Webb <bbew.ar@mapson.nozirev.ten> - 2011-07-28 15:53 -0400
    Re: 13 year old C source code Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 16:18 -0400
      Re: 13 year old C source code Roberto Waltman <usenet@rwaltman.com> - 2011-07-28 16:34 -0400
    Re: 13 year old C source code Ben Pfaff <blp@cs.stanford.edu> - 2011-07-28 13:36 -0700
    Re: 13 year old C source code gordonb.mgm25@burditt.org (Gordon Burditt) - 2011-07-28 15:37 -0500
      Re: 13 year old C source code Robert Wessel <robertwessel2@yahoo.com> - 2011-07-28 17:33 -0500
        Re: 13 year old C source code gordonb.2omx0@burditt.org (Gordon Burditt) - 2011-07-28 18:48 -0500
          Re: 13 year old C source code Robert Wessel <robertwessel2@yahoo.com> - 2011-07-28 19:26 -0500
      Re: 13 year old C source code BGB <cr88192@hotmail.com> - 2011-07-28 16:09 -0700
    Re: 13 year old C source code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-03 08:17 +0000

#8821 — 13 year old C source code

I haven't programmed in a VERY long time and I never was much good at 
it anyway.  From this you can accurately imply that I'm the wrong 
person to be doing this.  However:

I have been tasked to determine the feasibility of updating 13 year 
old (pre ANSI) ASM and C source code for the purpose of compiling a 
64-bit executable.

The source code was last modified in November of 1998 and was compiled 
using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
and 1986 respectively.

Are there any utilities that examine old C code and suggest how to 
make it compliant with current compilers?  I tried splint v3.1.2, but 
it crashes on line 110 of 824 lines and does not tell me how to 
correct the errors and warnings it does find.

Are there any utilities that examine 8086 ASM code and explain what to 
change to make it compile for a 64-bit CPU?  I type 'debug' in a CMD 
prompt in Vista in order to see the register names, but (of course) 
Vista has no DEBUG...

One of the things I'm completely stuck on is the difference in char.  
In the existing source code and with C88,

'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'

works, but the values obviously violate current char (and unsigned 
char) rules.  If char is changed to long, the values seem to be 
accepted, but the function is called with a char variable.

Any suggested resources other than utilities would be appreciated, 
too.  Google hasn't been much help, so the above includes a request 
for suggested search phrases.
--
buck

[toc] | [next] | [standalone]

#8822

Le 28/07/11 21:04, buck a écrit :
> I haven't programmed in a VERY long time and I never was much good at
> it anyway.  From this you can accurately imply that I'm the wrong
> person to be doing this.  However:
>
> I have been tasked to determine the feasibility of updating 13 year
> old (pre ANSI) ASM and C source code for the purpose of compiling a
> 64-bit executable.
>
> The source code was last modified in November of 1998 and was compiled
> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987
> and 1986 respectively.
>

All this doesn't look very fresh...


> Are there any utilities that examine old C code and suggest how to
> make it compliant with current compilers?

No, you need a human to do that. And you have to pay gim/her a
significant amount of money since it is a significant effort.

>  I tried splint v3.1.2, but
> it crashes on line 110 of 824 lines and does not tell me how to
> correct the errors and warnings it does find.
>

Well, you need someone that knows C and assembly.


> Are there any utilities that examine 8086 ASM code and explain what to
> change to make it compile for a 64-bit CPU?


 From this question I understand that you have really no clue...

:-)

Compiling/Assembling is not really that difficult. But I suppose that
you want that it RUNS correctly afterwards isn't it?


> I type 'debug' in a CMD
> prompt in Vista in order to see the register names, but (of course)
> Vista has no DEBUG...
>

Vista has very good debugger though... But you will need a 16 bit
debugger and those beasts disappeared something like 15 years or more
ago.

> One of the things I'm completely stuck on is the difference in char.
> In the existing source code and with C88,
>
> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>
> works, but the values obviously violate current char (and unsigned
> char) rules.

No, this is valid code. Why should be wrong? You are probably compiling
with char defaulting to unsigned char. Change that.


   If char is changed to long, the values seem to be
> accepted, but the function is called with a char variable.
>

Normally, a char variable is changed to int when passed to a function
that receives a char anyway since in modern CPUs you never push a
single char into the stack.


> Any suggested resources other than utilities would be appreciated,
> too.  Google hasn't been much help, so the above includes a request
> for suggested search phrases.
> --
> buck


Look buck, the only real solution is to get somebody that knows the
stuff and pay him $$$ to do the job. You can't do it, I fear, you would
need months of work just to get started into it.

[toc] | [prev] | [next] | [standalone]

#8824

On 2011/07/28 21:30, jacob navia wrote:
> Le 28/07/11 21:04, buck a écrit :
>> One of the things I'm completely stuck on is the difference in char.
>> In the existing source code and with C88,
>>
>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>
>> works, but the values obviously violate current char (and unsigned
>> char) rules.
>
> No, this is valid code. Why should it be wrong?

-180 -146 and -179 are less than CHAR_MIN is on anything that
I ever used.

   Francois Grieu

[toc] | [prev] | [next] | [standalone]

#8825

Le 28/07/11 21:35, Francois Grieu a écrit :
> On 2011/07/28 21:30, jacob navia wrote:
>> Le 28/07/11 21:04, buck a écrit :
>>> One of the things I'm completely stuck on is the difference in char.
>>> In the existing source code and with C88,
>>>
>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>>
>>> works, but the values obviously violate current char (and unsigned
>>> char) rules.
>>
>> No, this is valid code. Why should it be wrong?
>
> -180 -146 and -179 are less than CHAR_MIN is on anything that
> I ever used.
>
> Francois Grieu

So what? The compiler should take the lower 8 bits...

For instance -180 should be 0x4c.

[toc] | [prev] | [next] | [standalone]

#8834

jacob navia <jacob@spamsink.net> writes:
> Le 28/07/11 21:35, Francois Grieu a écrit :
>> On 2011/07/28 21:30, jacob navia wrote:
>>> Le 28/07/11 21:04, buck a écrit :
>>>> One of the things I'm completely stuck on is the difference in char.
>>>> In the existing source code and with C88,
>>>>
>>>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>>>
>>>> works, but the values obviously violate current char (and unsigned
>>>> char) rules.
>>>
>>> No, this is valid code. Why should it be wrong?
>>
>> -180 -146 and -179 are less than CHAR_MIN is on anything that
>> I ever used.
>>
>> Francois Grieu
>
> So what? The compiler should take the lower 8 bits...
>
> For instance -180 should be 0x4c.

Chances are it will do so (though the standard doesn't require it,
unless plain char is unsigned).  But the unanswered question is,
why did the original code use -180 in the first place?

It could well indicate a bug in the original code, having nothing
to do with K&R vs. ANSI C (perhaps it was missed because the older
compiler didn't bother to warn about it).

We really don't have enough information to do more that guess,
but if I were working on this I'd certainly try to find out.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8830

jacob navia <jacob@spamsink.net> wrote in news:j0sdco$6lr$1
@speranza.aioe.org:

> Le 28/07/11 21:04, buck a écrit :
>> Are there any utilities that examine 8086 ASM code and explain what 
to
>> change to make it compile for a 64-bit CPU?
> 
> 
>  From this question I understand that you have really no clue...
> 
>:-)

Correct.  I thought I said that :)
--
buck

[toc] | [prev] | [next] | [standalone]

#8823

On 2011/07/28 21:04, buck wrote:

 > One of the things I'm completely stuck on is the difference in char.
 > In the existing source code and with C88,
 >
 > 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
 >
 > works, but the values obviously violate current char (and unsigned
 > char) rules.

Try

#include <limits.h>
#define CHARIZE(x) (CHAR_MIN+255&((x)-CHAR_MIN))
static char v[]={CHARIZE(-20),CHARIZE(-124),CHARIZE(-180) ...

However, if that's obfuscated x86 code, you might be out of luck.

   Francois Grieu

[toc] | [prev] | [next] | [standalone]

#8827

buck <buck@private.mil> writes:
> I haven't programmed in a VERY long time and I never was much good at 
> it anyway.  From this you can accurately imply that I'm the wrong 
> person to be doing this.  However:
>
> I have been tasked to determine the feasibility of updating 13 year 
> old (pre ANSI) ASM and C source code for the purpose of compiling a 
> 64-bit executable.

If it's only 13 years old (1998), I'm a bit surprised that it's
pre-ANSI; the ANSI standard was published 9 years before that
(and re-published as ISO C90 a year later).

> The source code was last modified in November of 1998 and was compiled 
> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
> and 1986 respectively.

Ok, those would be pre-ANSI compilers -- but at least some compilers
back then probably supported prototypes, which are probably the
most significant change ANSI introduced.

On the other hand, K&R-style (non-prototype) function declarations are
still legal, even in C99; I don't think even the C201X draft gets rid of
them.  (A pity, IMHO, but that's beside the point.)

> Are there any utilities that examine old C code and suggest how to 
> make it compliant with current compilers?  I tried splint v3.1.2, but 
> it crashes on line 110 of 824 lines and does not tell me how to 
> correct the errors and warnings it does find.

Personally, I'd just compile the code with whatever modern compiler
I want to use, and go through and fix any errors it reports.
That requires a fairly good knowledge of C, but I can't think of
any approach that doesn't.

Be sure to use a good source control system so you can keep track
of just what changes you've made.

> Are there any utilities that examine 8086 ASM code and explain what to 
> change to make it compile for a 64-bit CPU?  I type 'debug' in a CMD 
> prompt in Vista in order to see the register names, but (of course) 
> Vista has no DEBUG...

Can't help you with that.  It has nothing to do with C, so you'll get
better help elsewhere.

> One of the things I'm completely stuck on is the difference in char.  
> In the existing source code and with C88,
>
> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>
> works, but the values obviously violate current char (and unsigned 
> char) rules.  If char is changed to long, the values seem to be 
> accepted, but the function is called with a char variable.

That's not a K&R-vs-ANSI issue.  Unless C88 targets some exotic
system with char bigger than 8 bits (unlikely), that code was wrong
to begin with.  As Francois Grieu points out, the values -180,
-146, and -179 are almost certainly outside the range of char.
In practice, they'll most likely be implicitly converted to 76, 110,
and 77, respectively (though that's not guaranteed by the language).
Possibly the only difference is that the older compiler might not
have warned about it.

char probably isn't the right type for the array; given the values,
and assuming you change the out-of-range values as described, it
should prboably be signed char.  Or perhaps unsigned char would
make more sense; then you should change all the negative values as
well (add 256 to each of them).  It depends very much on what it's
being used for.  (Arrays of unsigned char are usually the best way
to represent arbitrary byte sequences.)

> Any suggested resources other than utilities would be appreciated, 
> too.  Google hasn't been much help, so the above includes a request 
> for suggested search phrases.

Most valid pre-ANSI C code should still compile with a modern
compiler, though warnings are likely.  You'll probably have more
problems with (a) use of extensions supported by the old compiler
but not by the newer one, and (b) bad code that the old compiler
didn't diagnose properly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8840

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnk4b2fa62.fsf@nuthaus.mib.org...
> buck <buck@private.mil> writes:
>> I haven't programmed in a VERY long time and I never was much good at
>> it anyway.  From this you can accurately imply that I'm the wrong
>> person to be doing this.  However:
>>
>> I have been tasked to determine the feasibility of updating 13 year
>> old (pre ANSI) ASM and C source code for the purpose of compiling a
>> 64-bit executable.
>
> If it's only 13 years old (1998), I'm a bit surprised that it's
> pre-ANSI; the ANSI standard was published 9 years before that
> (and re-published as ISO C90 a year later).
>
>> The source code was last modified in November of 1998 and was compiled
>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987
>> and 1986 respectively.
>
> Ok, those would be pre-ANSI compilers -- but at least some compilers
> back then probably supported prototypes, which are probably the
> most significant change ANSI introduced.


The DeSmet compiler most certainly did support prototypes; on the other 
hand, if the code he's porting doesn't use them, whether they were supported 
is irrelevent.

>
> On the other hand, K&R-style (non-prototype) function declarations are
> still legal, even in C99; I don't think even the C201X draft gets rid of
> them.  (A pity, IMHO, but that's beside the point.)
>
>> Are there any utilities that examine old C code and suggest how to
>> make it compliant with current compilers?  I tried splint v3.1.2, but
>> it crashes on line 110 of 824 lines and does not tell me how to
>> correct the errors and warnings it does find.
>
> Personally, I'd just compile the code with whatever modern compiler
> I want to use, and go through and fix any errors it reports.
> That requires a fairly good knowledge of C, but I can't think of
> any approach that doesn't.
>
> Be sure to use a good source control system so you can keep track
> of just what changes you've made.

One thing that the OP may need to be careful is if there are any explicit 
'near' and 'far' pointers; if the code tried to do anything fancy with them, 
well, you may end up having to figure out what they're doing, and rewriting 
that section.

>
>> Are there any utilities that examine 8086 ASM code and explain what to
>> change to make it compile for a 64-bit CPU?  I type 'debug' in a CMD
>> prompt in Vista in order to see the register names, but (of course)
>> Vista has no DEBUG...
>
> Can't help you with that.  It has nothing to do with C, so you'll get
> better help elsewhere.

One thing that comes into play here is the ABI (that is, the interface 
between a caller and the called routine, things like how parameters are 
passed, how return values are returned, what registers need to be preserved, 
etc).  The DeSmet compiler used one specific ABI (which was actually pretty 
popular at the time; they didn't invent it); I'm sure a C compiler running 
in 64 bit mode uses a significantly different ABI.  One of the things the 
rewrite will need to account for is retargetting the code to the new ABI.

This is looking less and less like a project that a newbie could handle...

>
> Most valid pre-ANSI C code should still compile with a modern
> compiler, though warnings are likely.  You'll probably have more
> problems with (a) use of extensions supported by the old compiler
> but not by the newer one, and (b) bad code that the old compiler
> didn't diagnose properly.

One thing I remember DeSmet not catching:

    char c;
    c = "T";    /* Yup; c got set to the lower 8 bits of the address, 
without even a warning from the compiler! */

-- 
poncho

[toc] | [prev] | [next] | [standalone]

#8841

"Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:
[...]
> One thing I remember DeSmet not catching:
>
>     char c;
>     c = "T";    /* Yup; c got set to the lower 8 bits of the address, 
> without even a warning from the compiler! */

Ok, that could explain why the code initializing a char to -180 never
got fixed (the compiler wouldn't have warned about it).  It wouldn't
explain why it was written that way in the first place, but assuming the
code actually worked, either leaving it alone and ignoring the warnings,
or changing the value from -180 to 76, might be ok.

But we still have no clue what the char array is actually used for,
and the OP hasn't given us much feedback.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8828

On 28 Jul 2011 19:04:29 GMT, buck <buck@private.mil> wrote:

>I haven't programmed in a VERY long time and I never was much good at 
>it anyway.  From this you can accurately imply that I'm the wrong 
>person to be doing this.  However:
>
>I have been tasked to determine the feasibility of updating 13 year 
>old (pre ANSI) ASM and C source code for the purpose of compiling a 
>64-bit executable.
>
>The source code was last modified in November of 1998 and was compiled 
>using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
>and 1986 respectively.
>
>Are there any utilities that examine old C code and suggest how to 
>make it compliant with current compilers?  I tried splint v3.1.2, but 
>it crashes on line 110 of 824 lines and does not tell me how to 
>correct the errors and warnings it does find.

splint was an academic exercise and never really a very good tool in
production (although there are certainly folks who use it that way). If
you need linting, then Gimpel lint is the way to go. Be aware that code
that wasn't linted during development can throw so many warnings and
errors that fixing everything can be like cleaning King Augeas' stables.
"So much shit! Where to start?" The answer is probably the same one that
Herc used: wash it all away and start over rather than try to go at it a
line at a time.

>Are there any utilities that examine 8086 ASM code and explain what to 
>change to make it compile for a 64-bit CPU?  I type 'debug' in a CMD 
>prompt in Vista in order to see the register names, but (of course) 
>Vista has no DEBUG...

Machines are much faster nowadays and have lots more resources, so
whatever prompted the original requirement for embedded assembly may no
longer be important. You'll need to understand what the original
assembly was doing, whether you leave it as assembly or use C, so first
thing would be to replace it with functionally equivalent C code and
that may be good enough.

>One of the things I'm completely stuck on is the difference in char.  
>In the existing source code and with C88,
>
>'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'

Change to "static signed char ..." Check other places where the
signedness of char may matter.

>
>works, but the values obviously violate current char (and unsigned 
>char) rules.  If char is changed to long, the values seem to be 
>accepted, but the function is called with a char variable.
>
>Any suggested resources other than utilities would be appreciated, 
>too.  Google hasn't been much help, so the above includes a request 
>for suggested search phrases.

-- 
Rich Webb     Norfolk, VA

[toc] | [prev] | [next] | [standalone]

#8829

buck wrote:
>I have been tasked to determine the feasibility of updating 13 year 
>old (pre ANSI) ASM and C source code for the purpose of compiling a 
>64-bit executable.
>
>The source code was last modified in November of 1998 and was compiled 
>using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
>and 1986 respectively.
>
>Are there any utilities that examine old C code and suggest how to 
>make it compliant with current compilers?  I tried splint ...

I would recommend Gimpel's PC-Lint  (
http://www.gimpel.com/html/index.htm ), but to really take advantage
of it you need  a level of knowledge that, from your post, you do not
have.

You could create a Visual Studio or Eclipse project based on the
sources you have, and start modifying the code until it compiles
cleanly with whatever options you choose.
Even if it does not run, the navigation, search, code completion, etc.
features of these environments can save you some time and effort.

>Are there any utilities that examine 8086 ASM code and explain what to 
>change to make it compile for a 64-bit CPU?

Don't know, probably not. But, why do you want to preserve the ASM
code?  Why was there any ASM code to begin with?
Probable reasons:
a) To interface with libraries with different calling conventions
(FORTRAN, Pascal)
b) To access system calls that were not available via the language's
run time library.
c) To directly access hardware.
d) For speed.
f) The ASM code already existed, and was being reused.

Those reasons probably are not relevant today. You may be  better off
rewriting the ASM code in C instead of porting it to a 64 bit
environment.

> I type 'debug' in a CMD 
>prompt in Vista in order to see the register names, but (of course) 
>Vista has no DEBUG...

There isn't a DEBUG program as in the good old MS-DOS days, but Visual
Studio comes with a symbolic debugger so much powerful than DEBUG that
any comparison is meaningless. Also check Hewart and Pravat "Advanced
Windows Debugging"

>Any suggested resources other than utilities would be appreciated, 
>too.  Google hasn't been much help, so the above includes a request 
>for suggested search phrases.

I agree with Jacob Navia's suggestion to farm out the job to somebody
with current experience.
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#8831

 Roberto Waltman wrote:
>...
>There isn't a DEBUG program as in the good old MS-DOS days, but Visual
>Studio comes with a symbolic debugger ...

Check "Download and Install Debugging Tools for Windows"
http://msdn.microsoft.com/en-us/windows/hardware/gg463009

--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#8832

buck <buck@private.mil> writes:

> I have been tasked to determine the feasibility of updating 13 year 
> old (pre ANSI) ASM and C source code for the purpose of compiling a 
> 64-bit executable.

How big is it?  What does it do?  Based on the answers, you might
decide that rewriting it or using a modern equivalent is less
work and more satisfying than trying to port it to a modern OS
and toolchain.

By the way, if it's only 13 years old then it was written in an
old style: in 1998, the ANSI C standard had already been out for
9 years.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#8833

> I have been tasked to determine the feasibility of updating 13 year 
> old (pre ANSI) ASM and C source code for the purpose of compiling a 
> 64-bit executable.
> 
> The source code was last modified in November of 1998 and was compiled 
> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
> and 1986 respectively.

What CPU is this?  8088?  8080?  8008?

One way to run a program like this is, especially when there's
assembly involved, is to write a full emulator, with the binary
of the program as the data.  This is a large job, and it won't
easily let you modify the code involved even after you're finished.

If you do a good job writing the emulator, the code can be portable
to many different CPUs, even though it still has ASM in it.

Do you have a working version of the compiler that will compile it?
(on any system you have access to?) It may well come down to figuring
out what that compiler did (by examining the generated code) and
figuring out how to do that in a portable way.

> Are there any utilities that examine old C code and suggest how to 
> make it compliant with current compilers?  I tried splint v3.1.2, but 
> it crashes on line 110 of 824 lines and does not tell me how to 
> correct the errors and warnings it does find.

Running slint on the program *crashes* slint?  This is distinct
from just giving an error message and giving up on further analysis.
I hope you report the bug to the vendor.

A lint-like program is a good tool, but it may overwhelm you with
warnings.  For syntax problems, generally the first error message
is the one to look at, as the rest may be caused by faulty assumptions
trying to recover from the first error.

Don't expect a program to be able to guess how to fix it.  If there
are several things that are inconsitent, you need to make them
consistent by changing all but one of them, but knowing which one
requires a lot of knowledge of what the program is supposed to be
doing.  It's like going to a junk yard and trying to put stuff
together, not realizing that the parts you have are half a car,
half an airplane, half a vacuum cleaner, and half a TV set.

One of the worst examples of this was a program entered into the
obfuscated C contest that consisted of one array initialization
(that's the entire program!):

short main [] = { ...bunch of numbers in here ... };

It's portable between the VAX and PDP-11.


> Are there any utilities that examine 8086 ASM code and explain what to 
> change to make it compile for a 64-bit CPU?  

In one context I think they are called 'grad students'.

> I type 'debug' in a CMD 
> prompt in Vista in order to see the register names, but (of course) 
> Vista has no DEBUG...
> 
> One of the things I'm completely stuck on is the difference in char.  
> In the existing source code and with C88,
> 
> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
> 
> works, but the values obviously violate current char (and unsigned 
> char) rules.  

I'm going to make an assumption that it took the bottom 8 bits of
each value and stuffed them into a char/unsigned char.

> If char is changed to long, the values seem to be 
> accepted, but the function is called with a char variable.

If you change the definition so v[] is an array of long, you have to
deal with changing everything that uses that array.  Things may not
go so well if a pointer into v gets fed to string-handling functions.

> Any suggested resources other than utilities would be appreciated, 
> too.  Google hasn't been much help, so the above includes a request 
> for suggested search phrases.

You may find a lot of problems by carefully analyzing the type of
every parameter passed to a function (particularly library and
system functions) and make sure that it is correct.  long is not
necessarily the same size as int.  int is not necessarily the same
size as short.  Also, keep an eye out for mis-use of pointers that
depends on the byte-order of the CPU.

[toc] | [prev] | [next] | [standalone]

#8842

On Thu, 28 Jul 2011 15:37:15 -0500, gordonb.mgm25@burditt.org (Gordon
Burditt) wrote:

>> I have been tasked to determine the feasibility of updating 13 year 
>> old (pre ANSI) ASM and C source code for the purpose of compiling a 
>> 64-bit executable.
>> 
>> The source code was last modified in November of 1998 and was compiled 
>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
>> and 1986 respectively.
>
>What CPU is this?  8088?  8080?  8008?
>
>One way to run a program like this is, especially when there's
>assembly involved, is to write a full emulator, with the binary
>of the program as the data.  This is a large job, and it won't
>easily let you modify the code involved even after you're finished.
>
>If you do a good job writing the emulator, the code can be portable
>to many different CPUs, even though it still has ASM in it.


I believe those versions are all 16-bit x86, and are probably MS-DOS
based.  The emulator idea is a good one, but no need to reinvent the
wheel.  DOSBox already does most of that:

http://www.dosbox.com/

And if the canned version is not up to snuff, it's FOSS.

[toc] | [prev] | [next] | [standalone]

#8848

>>> The source code was last modified in November of 1998 and was compiled 
>>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
>>> and 1986 respectively.

Just because it was last modified in 1998 does not mean it wasn't originally
written 10-15 years earlier and patched until they couldn't any more.

>>What CPU is this?  8088?  8080?  8008?
>>
>>One way to run a program like this is, especially when there's
>>assembly involved, is to write a full emulator, with the binary
>>of the program as the data.  This is a large job, and it won't
>>easily let you modify the code involved even after you're finished.
>>
>>If you do a good job writing the emulator, the code can be portable
>>to many different CPUs, even though it still has ASM in it.
> 
> 
> I believe those versions are all 16-bit x86, and are probably MS-DOS
> based.  

No.  The 8008 was an early 8-bit CPU, could address 16K bytes, ran
at a top speed of 0.8 MHz, had a built-in small call/return address
stack (8 levels? and you could NOT put it in general RAM), and you
couldn't save all registers on an interrupt.  It made a nice
microcontroller for terminals, but as a general-purpose computer
it was pretty lame.

The 8080 was a better 8-bit CPU, could address 64K bytes, ran at
2.0 MHz, and ran CP/M 80.  The Z80 was an extension of this, used
in the Radio Shack TRS-80 Model 1 running TRSDOS and other systems
running CP/M.

The 8088 was an 8-bit CPU from the hardware point of view (8-bit
data bus for transferring data to/from memory), could address 1MB,
but from the point of view of the instruction set, was 16-bit and
almost identical to the 8086.  It was used in the IBM PC running
MS-DOS, although there were other OSs like CP/M 86.

I presume the 8088/8086 under MS-DOS is what your program runs on.
Watch out if the program uses "near" or "far" in pointer declarations.
You'll probably have to remove those keywords.  If fancy manipulation
knowing the structure of a pointer is done, you may have more problems.
At least it's easier taking these out than putting them in.

If your program uses "extended" or "expanded" memory, you may have
problems.  One of those used bank-switching hardware which may not
be present on a modern CPU.


> The emulator idea is a good one, but no need to reinvent the
> wheel.  DOSBox already does most of that:
> 
> http://www.dosbox.com/
> 
> And if the canned version is not up to snuff, it's FOSS.

Ok, but at the time it wasn't obvious what CPU you were using.  There are
probably 8080 / Z80 emulators out there also.  

Incidentally, one thing to also watch out for even with emulators
is differences in timing.  In games and some peripherals, faster
is not better.  The aliens might move so fast they eat you before
you can react.  A peripheral might get fed commands so fast it can't
handle them all.  Usually, though, this becomes an issue only when
you've almost got it working and are ironing out the last few bugs.

What does this program *DO*?

[toc] | [prev] | [next] | [standalone]

#8851

On Thu, 28 Jul 2011 18:48:05 -0500, gordonb.2omx0@burditt.org (Gordon
Burditt) wrote:

>>>> The source code was last modified in November of 1998 and was compiled 
>>>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
>>>> and 1986 respectively.
>
>Just because it was last modified in 1998 does not mean it wasn't originally
>written 10-15 years earlier and patched until they couldn't any more.
>
>>>What CPU is this?  8088?  8080?  8008?
>>>
>>>One way to run a program like this is, especially when there's
>>>assembly involved, is to write a full emulator, with the binary
>>>of the program as the data.  This is a large job, and it won't
>>>easily let you modify the code involved even after you're finished.
>>>
>>>If you do a good job writing the emulator, the code can be portable
>>>to many different CPUs, even though it still has ASM in it.
>> 
>> 
>> I believe those versions are all 16-bit x86, and are probably MS-DOS
>> based.  
>
>No.  The 8008 was an early 8-bit CPU, could address 16K bytes, ran
>at a top speed of 0.8 MHz, had a built-in small call/return address
>stack (8 levels? and you could NOT put it in general RAM), and you
>couldn't save all registers on an interrupt.  It made a nice
>microcontroller for terminals, but as a general-purpose computer
>it was pretty lame.
>
>The 8080 was a better 8-bit CPU, could address 64K bytes, ran at
>2.0 MHz, and ran CP/M 80.  The Z80 was an extension of this, used
>in the Radio Shack TRS-80 Model 1 running TRSDOS and other systems
>running CP/M.
>
>The 8088 was an 8-bit CPU from the hardware point of view (8-bit
>data bus for transferring data to/from memory), could address 1MB,
>but from the point of view of the instruction set, was 16-bit and
>almost identical to the 8086.  It was used in the IBM PC running
>MS-DOS, although there were other OSs like CP/M 86.
>
>I presume the 8088/8086 under MS-DOS is what your program runs on.
>Watch out if the program uses "near" or "far" in pointer declarations.
>You'll probably have to remove those keywords.  If fancy manipulation
>knowing the structure of a pointer is done, you may have more problems.
>At least it's easier taking these out than putting them in.
>
>If your program uses "extended" or "expanded" memory, you may have
>problems.  One of those used bank-switching hardware which may not
>be present on a modern CPU.
>
>
>> The emulator idea is a good one, but no need to reinvent the
>> wheel.  DOSBox already does most of that:
>> 
>> http://www.dosbox.com/
>> 
>> And if the canned version is not up to snuff, it's FOSS.
>
>Ok, but at the time it wasn't obvious what CPU you were using.  There are
>probably 8080 / Z80 emulators out there also.  
>
>Incidentally, one thing to also watch out for even with emulators
>is differences in timing.  In games and some peripherals, faster
>is not better.  The aliens might move so fast they eat you before
>you can react.  A peripheral might get fed commands so fast it can't
>handle them all.  Usually, though, this becomes an issue only when
>you've almost got it working and are ironing out the last few bugs.
>
>What does this program *DO*?


I was referring to the compiler/assembler versions, and I'm not the
OP.

[toc] | [prev] | [next] | [standalone]

#8846

On 7/28/2011 1:37 PM, Gordon Burditt wrote:
>> I have been tasked to determine the feasibility of updating 13 year
>> old (pre ANSI) ASM and C source code for the purpose of compiling a
>> 64-bit executable.
>>
>> The source code was last modified in November of 1998 and was compiled
>> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987
>> and 1986 respectively.
>
> What CPU is this?  8088?  8080?  8008?
>

I think elsewhere 8086 was mentioned.
most likely it was an MS-DOS app.

> One way to run a program like this is, especially when there's
> assembly involved, is to write a full emulator, with the binary
> of the program as the data.  This is a large job, and it won't
> easily let you modify the code involved even after you're finished.
>
> If you do a good job writing the emulator, the code can be portable
> to many different CPUs, even though it still has ASM in it.
>

or maybe use DOSBox...

DOSBox can run DOS apps on modern Windows, and one can also get Win3.11 
to work in it (albeit XPMode or VMware+WinXP are better for running 
Win3.x apps, as then the OS is less prone to breaking...).


> Do you have a working version of the compiler that will compile it?
> (on any system you have access to?) It may well come down to figuring
> out what that compiler did (by examining the generated code) and
> figuring out how to do that in a portable way.
>
>> Are there any utilities that examine old C code and suggest how to
>> make it compliant with current compilers?  I tried splint v3.1.2, but
>> it crashes on line 110 of 824 lines and does not tell me how to
>> correct the errors and warnings it does find.
>
> Running slint on the program *crashes* slint?  This is distinct
> from just giving an error message and giving up on further analysis.
> I hope you report the bug to the vendor.
>
> A lint-like program is a good tool, but it may overwhelm you with
> warnings.  For syntax problems, generally the first error message
> is the one to look at, as the rest may be caused by faulty assumptions
> trying to recover from the first error.
>
> Don't expect a program to be able to guess how to fix it.  If there
> are several things that are inconsitent, you need to make them
> consistent by changing all but one of them, but knowing which one
> requires a lot of knowledge of what the program is supposed to be
> doing.  It's like going to a junk yard and trying to put stuff
> together, not realizing that the parts you have are half a car,
> half an airplane, half a vacuum cleaner, and half a TV set.
>
> One of the worst examples of this was a program entered into the
> obfuscated C contest that consisted of one array initialization
> (that's the entire program!):
>
> short main [] = { ...bunch of numbers in here ... };
>
> It's portable between the VAX and PDP-11.
>

yep...


>
>> Are there any utilities that examine 8086 ASM code and explain what to
>> change to make it compile for a 64-bit CPU?
>
> In one context I think they are called 'grad students'.
>
>> I type 'debug' in a CMD
>> prompt in Vista in order to see the register names, but (of course)
>> Vista has no DEBUG...
>>
>> One of the things I'm completely stuck on is the difference in char.
>> In the existing source code and with C88,
>>
>> 'static char v[]={-20,-124,-180,-93,-88,-73,-27,-146,9,-38,-179 ...'
>>
>> works, but the values obviously violate current char (and unsigned
>> char) rules.
>
> I'm going to make an assumption that it took the bottom 8 bits of
> each value and stuffed them into a char/unsigned char.
>
>> If char is changed to long, the values seem to be
>> accepted, but the function is called with a char variable.
>
> If you change the definition so v[] is an array of long, you have to
> deal with changing everything that uses that array.  Things may not
> go so well if a pointer into v gets fed to string-handling functions.
>
>> Any suggested resources other than utilities would be appreciated,
>> too.  Google hasn't been much help, so the above includes a request
>> for suggested search phrases.
>
> You may find a lot of problems by carefully analyzing the type of
> every parameter passed to a function (particularly library and
> system functions) and make sure that it is correct.  long is not
> necessarily the same size as int.  int is not necessarily the same
> size as short.  Also, keep an eye out for mis-use of pointers that
> depends on the byte-order of the CPU.
>

long ago (back when I was much younger), I had some code like this (the 
Wolfenstein 3D source), which at the time I had no idea how to build 
into a form I could run on more modern systems at the time (Windows and 
Linux). at the time I did use it some as a read-only learning aide.

later on (after I learned programming a bit better), I could probably 
have done it, but by this point there was no longer much point (as I was 
off messing with the Quake source and OpenGL).

kind of funny how things are sometimes...

[toc] | [prev] | [next] | [standalone]

#9000

On Thu, 2011-07-28, buck wrote:
> I haven't programmed in a VERY long time and I never was much good at 
> it anyway.  From this you can accurately imply that I'm the wrong 
> person to be doing this.  However:
>
> I have been tasked to determine the feasibility of updating 13 year 
> old (pre ANSI) ASM and C source code for the purpose of compiling a 
> 64-bit executable.
>
> The source code was last modified in November of 1998 and was compiled 
> using C88 v3.03 and ASM88 v1.5, which are copyright Mark DeSmet 1987 
> and 1986 respectively.

The code may be 13 years old on the surface, but I get the feeling
it's soul is more like 30 years old ...

> Are there any utilities that examine old C code and suggest how to 
> make it compliant with current compilers?

Like Jacob said, what you need is a C programmer. The compiler, the
build system and other normal tools should be enough as far as tools
are concerned.

Depending on the coding style of the original code, you may have lots
of work, or not so much. Much depends on how well the code used the
type checking (which IIRC was optional before ANSI C, and of course is
often disabled using casts etc even today).

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web