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

Groups > alt.folklore.computers > #215939 > unrolled thread

AI and decompilation?

Back to article view | Back to alt.folklore.computers

Contents

  AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 11:00 +0000
    Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-04 11:42 +0000
    Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 13:08 +0000
      Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 17:51 +0000
        Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 21:57 +0000
          Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 22:23 +0000
            Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 23:09 +0000
          Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 17:50 -0500
            Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 23:00 +0000
              Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-04 16:59 -0700
              Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-04 20:42 -0500
                Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 20:59 -0500
              Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 20:55 -0500
                Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-05 10:38 +0000
                  Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 12:46 +0000
                    Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-05 13:43 +0000
                      Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 14:23 +0000
                    Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:22 +0000
                  Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-05 09:05 -0500
              Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:51 +0000
                Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 11:52 +0000
                Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 12:06 +0000
                Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:12 +0000
                Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:12 +0000
            Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:45 +0000
              Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:25 -0700
          Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-04 20:38 -0500
            Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:54 +0000
            Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:06 -0700
              Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:52 +0000
          Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:29 +0000
    Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-04 11:05 -0500
      Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 17:07 +0000
        Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-04 17:52 +0000
          Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:28 +0000
            Re: AI and decompilation? Thomas Koenig <tkoenig@netcologne.de> - 2021-01-05 13:06 +0000
              Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 13:41 +0000
              Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:30 +0000
                Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 16:42 +0000
                  Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:12 +0000
              Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:25 -0700
              Re: AI and decompilation? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-01-06 14:17 +0200
                Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-06 12:42 +0000
                  Re: AI and decompilation? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-01-06 16:42 +0200
                  Re: AI and decompilation? "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2021-01-08 09:48 +0000
                    Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 10:27 +0000
                Re: AI and decompilation? usenet@only.tnx (Questor) - 2021-01-08 21:40 +0000
            Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:06 -0700
              Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 22:27 +0000
                Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-06 00:14 +0000
                  Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 08:25 +0000
                    Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:52 -0500
                      Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 15:37 +0000
                      Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-10 06:40 -0700
                Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-06 15:15 +0000
                  Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 16:09 +0000
                    Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-06 17:07 +0000
                      Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 17:38 +0000
            Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-05 21:20 +0000
      Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 17:47 +0000
      Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 14:18 -0500
        Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-04 16:54 -0700
      Re: AI and decompilation? Theo <theom+news@chiark.greenend.org.uk> - 2021-01-04 23:01 +0000
    Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-04 20:11 +0000
    Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 09:07 +0000
      Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 09:47 +0000
        Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 11:13 +0000
          Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 12:12 +0000
            Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 13:39 +0000
              Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:32 +0000
                Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:40 +0000
            Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-05 16:02 +0000
          Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 18:27 +0000
          Re: AI and decompilation? Vir Campestris <vir.campestris@invalid.invalid> - 2021-01-05 21:15 +0000
            Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:54 +0000
      Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:56 +0000
        Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-05 14:11 +0000
          Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 14:22 +0000
          Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:35 +0000
            Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 18:47 +0000
              Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:15 +0000
      Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-05 07:32 -0500
      Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-05 16:00 +0000
    Re: AI and decompilation? Adrian Caspersz <email@here.invalid> - 2021-01-05 11:26 +0000
      Re: AI and decompilation? Thomas Koenig <tkoenig@netcologne.de> - 2021-01-05 13:07 +0000
        Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 13:42 +0000
        Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-05 18:31 +0000
    Re: AI and decompilation? "K. Krause" <klemens.krause@gmx.net> - 2021-01-05 16:01 +0100
    Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-05 20:51 +0000
      Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:51 +0000
        Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 22:23 -0500
    Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-02-12 15:40 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#216061

Thomas Koenig <tkoenig@netcologne.de> wrote:
> The Natural Philosopher <tnp@invalid.invalid> schrieb:
>> The C. Some things that are 
>> neat in assembler are ugly as sin in C.
> 
> One thing that is hard to do with C is to have different entries
> to the same function, something like:
> 
> bar:
>         .cfi_startproc
>       ... do something
> foo:
>       ... do something else
> 
>       ret
> 
> and then either call foo or bar.
> 

Simple in PL/I, although it turns out there is more overhead than you’d
think, particularly if foo and bar have different return types. I used
multiple entries extensively in the Iron Spring PL/I compiler, but it turns
out the “package” construct (once I implemented it) is much cleaner.
Multiple entries is also error-prone if the entries have different
parameters.

-- 
Pete

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

#216081

On 5.1.21 15.06, Thomas Koenig wrote:
> The Natural Philosopher <tnp@invalid.invalid> schrieb:
>> The C. Some things that are
>> neat in assembler are ugly as sin in C.
> 
> One thing that is hard to do with C is to have different entries
> to the same function, something like:
> 
> bar:
>          .cfi_startproc
>        ... do something
> foo:
>        ... do something else
> 
>        ret
> 
> and then either call foo or bar.
> 

This is a common construction in compiler-generated
machine code, if the first function calls another
just before return.

bar:    .cfi_startproc
         ... do something
         call foo
         ret

foo:    .. do more ..
         ret

If the functions have different stacks, there may be
a need to adjust the stack first before entering the ¨
second function.

-- 

-TV

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

#216085

On Wed, 6 Jan 2021 14:17:30 +0200
Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:

> This is a common construction in compiler-generated
> machine code, if the first function calls another
> just before return.
> 
> bar:    .cfi_startproc
>          ... do something
>          call foo
>          ret

	I recall optimising things like that by changing the last two lines
to:
	jmp foo

> foo:    .. do more ..
>          ret

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

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

#216091

On 6.1.21 14.42, Ahem A Rivet's Shot wrote:
> On Wed, 6 Jan 2021 14:17:30 +0200
> Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> 
>> This is a common construction in compiler-generated
>> machine code, if the first function calls another
>> just before return.
>>
>> bar:    .cfi_startproc
>>           ... do something
>>           call foo
>>           ret
> 
> 	I recall optimising things like that by changing the last two lines
> to:
> 	jmp foo
> 
>> foo:    .. do more ..
>>           ret
> 

That's what I intended to say. Try the current release of
GCC for ARM Cortex.

There may be a register pop before the jump, to keep the
stack correct.

-- 

-TV

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

#216141

On Wed, 06 Jan 2021 12:42:05 GMT, Ahem A Rivet's Shot <steveo@eircom.net> 
wrote:

> On Wed, 6 Jan 2021 14:17:30 +0200
> Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> 
>> This is a common construction in compiler-generated
>> machine code, if the first function calls another
>> just before return.
>> 
>> bar:    .cfi_startproc
>>          ... do something
>>          call foo
>>          ret
> 
>      I recall optimising things like that by changing the last two 
lines
> to:
>      jmp foo
> 
>> foo:    .. do more ..
>>          ret
> 

I'm naive; what's the problem with:


bar:    .cfi_startproc
         ... do something

;;;          call foo
;;;         ret
; just fallthru to execute foo and exit.

foo:    .. do more ..
          ret
 

-- 
Bah, and indeed, Humbug.

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

#216142

On Fri, 8 Jan 2021 09:48:44 -0000 (UTC)
"Kerr-Mudd,John" <notsaying@127.0.0.1> wrote:

> On Wed, 06 Jan 2021 12:42:05 GMT, Ahem A Rivet's Shot <steveo@eircom.net> 
> wrote:
> 
> > On Wed, 6 Jan 2021 14:17:30 +0200
> > Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> > 
> >> This is a common construction in compiler-generated
> >> machine code, if the first function calls another
> >> just before return.
> >> 
> >> bar:    .cfi_startproc
> >>          ... do something
> >>          call foo
> >>          ret
> > 
> >      I recall optimising things like that by changing the last two 
> lines
> > to:
> >      jmp foo
> > 
> >> foo:    .. do more ..
> >>          ret
> > 
> 
> I'm naive; what's the problem with:
> 
> 
> bar:    .cfi_startproc
>          ... do something
> 
> ;;;          call foo
> ;;;         ret
> ; just fallthru to execute foo and exit.
> 
> foo:    .. do more ..
>           ret

	Nothing as long as you only have one bar for your foo, often foo
was common finishing for several bars.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

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

#216152

On Wed, 6 Jan 2021 14:17:30 +0200, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:
>This is a common construction in compiler-generated
>machine code, if the first function calls another
>just before return.
>
>bar:    .cfi_startproc
>         ... do something
>         call foo
>         ret
>
>foo:    .. do more ..
>         ret

It's a common construction in human-generated assembly as well, at least on the
PDP10.

Instead of

BAR:	[do bar stuff]
	PUSHJ	P, FOO
	POPJ, P

One writes

BAR:	[do bar stuff]
	JRST	FOO

and lets the POPJ at the end of FOO return from the call to BAR.  Saves an
instruction.  In PDP10 land, the mnemonic PJRST is defined to be the JRST
instruction in order to alert the reader of this intention, so one would write

BAR:	[do bar stuff]
	PJRST	FOO


Similarly, routines will often pop (restore) saved registers off the stack
before returning.  Rather than duplicate that code, one uses a PJRST to a label
in another routine that does the same thing.

BAR:	PUSH	P, T1
	PUSH	P, T2
	[do bar stuff]
TPOPJ2:	POP	P, T2
TPOPJ1:	POP	P, T1
	POPJ	P,

FOO:	PUSH P, T1
	PUSH P, T2
	[do foo stuff]
	PJRST	TPOPJ2

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

#216056

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 04/01/2021 17:52, Scott Lurndal wrote:
>> Martin Gregorie <martin@mydomain.invalid> writes:
>>> On Mon, 04 Jan 2021 11:05:55 -0500, Dennis Lee Bieber wrote:
>>> 
>>>> On Mon, 4 Jan 2021 11:00:29 +0000, gareth evans <headstone255@yahoo.com>
>>>> declaimed the following:
>>>> 
>>>>> Thinking back to my first job, nearly 50 years ago now,
>>>>> when I had to dis-assemble DEC's paper tape BASIC interpreter in order
>>>>> to enhance it, I guess that dis-assemblers and decompilers must now be
>>>>> ten-a-penny,
>>>>> especially for programs running under Windows where the structure of
>>>>> Windows programs is well-known with an assumption that C was the source
>>>>> language?
>>>>> 
>>>> Actually, I think the use of disassemblers et al has fallen away.
>>>> Modern processors have so many peephole optimizations and out-of-order
>>>> execution streams that converting an executable back to assembly source
>>>> is almost meaningless -- and getting back to a high-level language is
>>>> near impossible. One would have to be an expert at the assembly for a
>>>> processor to have any chance of understanding the result.
>>> 
>>> The retro-computing guys - those who are fans of the MC6800 and MC6809
>>> microprocessors anyway, anyway, seem to be getting a rather good semi-
>>> interactive disassembler up and running.
>> 
>> Security experts have several very powerful disassemblers and decompilers
>> they use for Intel/AMD/ARM processors.
>> 
>> https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
>> 
> Yes. I am certain that certain compilers and certain languages leave a 
> fingerprint, Always THAT resister, used to do THAT job, always that 
> particular sequence of assembly to mimic that high level construct.
> I cut my teeth on microprocessor assembly. The C. Some things that are 
> neat in assembler are ugly as sin in C. Take a call table. In assembler, 
>  you set up a range of memory whose contents contain the addresses of 
> subroutines. You load the accumulator with a number, left shift it once, 
> add it to the content of a register set to point to the base of that 
> memory block,  and use that register as pointing to an address whose 
> contents are the address you want to 'call' Simple, efficient and 
> provided you ensure nothing out of bounds is in the accumulator, bomb proof.
> 
> Now try that in C, you need an array of pointers to functions, and a 
> simple check on the index you engage, followed by a declaration to call 
> the function whose address is in the array of pointers to functions. I 
> never ever managed to get an 8 bit compiler to actually do that. People 
> just don't call the contents of an array of pointers to functions.

You still have to set up the arguments for each in assembler, unless they
all take the same arguments (or a pointer to an argument list)

You shouldn’t need declarations in C unless you’re using one of those
new-fangled compilers that requires them. Old code should still be
supported, though.

-- 
Pete

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

#216064

On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:

> You shouldn’t need declarations in C unless you’re using one of those
> new-fangled compilers that requires them. Old code should still be
> supported, though.
>
Last time I tried it, (about 2 months ago), the current GNU C compiler 
accepts the old K&R C first edition procedure declaration syntax. I wish 
more compilers worked this way.


-- 
--  
Martin    | martin at
Gregorie  | gregorie dot org

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

#216068

On 2021-01-05, Martin Gregorie <martin@mydomain.invalid> wrote:

> On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>
>> You shouldn’t need declarations in C unless you’re using one of those
>> new-fangled compilers that requires them. Old code should still be
>> supported, though.
>
> Last time I tried it, (about 2 months ago), the current GNU C compiler 
> accepts the old K&R C first edition procedure declaration syntax. I wish 
> more compilers worked this way.

I write functions this way:

#ifdef PROTOTYPE
char *foo(char *bar, int baz)
#else
char *foo(bar, baz) char *bar; int baz;
#endif

One #define in a header file adapts it to any old or new compiler.
It works for declarations too.

-- 
/~\  Charlie Gibbs                  |  "Some of you may die,
\ /  <cgibbs@kltpzyxm.invalid>      |  but it's a sacrifice
 X   I'm really at ac.dekanfrus     |  I'm willing to make."
/ \  if you read it the right way.  |    -- Lord Farquaad (Shrek)

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

#216078

On Wed, 06 Jan 2021 00:14:31 +0000, Charlie Gibbs wrote:

> On 2021-01-05, Martin Gregorie <martin@mydomain.invalid> wrote:
> 
>> On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>>
>>> You shouldn’t need declarations in C unless you’re using one of those
>>> new-fangled compilers that requires them. Old code should still be
>>> supported, though.
>>
>> Last time I tried it, (about 2 months ago), the current GNU C compiler
>> accepts the old K&R C first edition procedure declaration syntax. I
>> wish more compilers worked this way.
> 
> I write functions this way:
> 
> #ifdef PROTOTYPE char *foo(char *bar, int baz)
> #else char *foo(bar, baz) char *bar; int baz;
> #endif
> 
> One #define in a header file adapts it to any old or new compiler.
> It works for declarations too.

That's safe but not necessary, for GNU C anyway. 

The GNU C compiler series maintains backward compatibility to the year 
dot. Dunno about other brands of C compiler, though. Just as well since I 
have some sources that were written under OS/9 v2.4, so use the syntax 
defined in the original K&R edition and I hate having to edit a source 
file just because a new compiler version dropped support for everything 
except the latest syntax.

Thats one reason I don't like Python.

COBOL is another language that historically tended to support only the 
latest syntax, which is a pain since source files can be huge. I've 
worked on COBOL program modules that ran to over 5000 lines back in the 
day, i.e before 1978, when COBOL didn't yet support writing separately 
compiled subroutines (no LINKAGE SECTION), though AFAIK COBOL has always 
supported calling subroutines written in other languages).


-- 
--  
Martin    | martin at
Gregorie  | gregorie dot org

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

#216160

On Wed, 6 Jan 2021 08:25:33 -0000 (UTC), Martin Gregorie
<martin@mydomain.invalid> declaimed the following:


>
>COBOL is another language that historically tended to support only the 
>latest syntax, which is a pain since source files can be huge. I've 
>worked on COBOL program modules that ran to over 5000 lines back in the 
>day, i.e before 1978, when COBOL didn't yet support writing separately 
>compiled subroutines (no LINKAGE SECTION), though AFAIK COBOL has always 
>supported calling subroutines written in other languages).

	LINKAGE SECTION was part of the COBOL-74 standard, and I recall it
existed on the Xerox Sigma-6 COBOL that was used at my college when I
attended (76-80). Our assignments may not have used it -- or we only had a
short intro to the concept.

	However, I'm fairly certain my college compiler did not support "copy
books"... And since that time-frame meant 24x80 text terminals, and line
mode text editors, one would have to manually duplicate the section from a
listing... Or write the program on the IBM 029 card punch -- feeding the
linkage section into it in duplicate mode, then inserting the copy into the
second file...



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

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

#216169

On Fri, 08 Jan 2021 21:52:39 -0500, Dennis Lee Bieber wrote:

> On Wed, 6 Jan 2021 08:25:33 -0000 (UTC), Martin Gregorie
> <martin@mydomain.invalid> declaimed the following:
> 
> 
> 
>>COBOL is another language that historically tended to support only the
>>latest syntax, which is a pain since source files can be huge. I've
>>worked on COBOL program modules that ran to over 5000 lines back in the
>>day, i.e before 1978, when COBOL didn't yet support writing separately
>>compiled subroutines (no LINKAGE SECTION), though AFAIK COBOL has always
>>supported calling subroutines written in other languages).
> 
> 	LINKAGE SECTION was part of the COBOL-74 standard, and I recall it
> existed on the Xerox Sigma-6 COBOL that was used at my college when I
> attended (76-80). Our assignments may not have used it -- or we only had
> a short intro to the concept.
> 
> 	However, I'm fairly certain my college compiler did not support 
"copy
> books"... And since that time-frame meant 24x80 text terminals, and line
> mode text editors, one would have to manually duplicate the section from
> a listing... Or write the program on the IBM 029 card punch -- feeding
> the linkage section into it in duplicate mode, then inserting the copy
> into the second file...

Compiler features do vary: I don't recall seeing LINKAGE section in any 
version of the ICL 1900 COBOL compilers, which I was using 1968-1977. If 
LINKAGE sections had been available I'm sure I would have used them and 
coded subroutines in COBOL, but though our COBOL code regularly called 
subroutines, these were all written in PLAN (assembler). From 1978 onward 
I was programming ICL 2900s: 2900 COBOL implemented LINKAGE sections and 
we made extensive use of them to split large COBOL programs into modules. 

After 1984 I wrote very little COBOL, and that was for DEC and MicroFocus  
compilers. None of these projects used COBOL subroutines: the DEC RDB 
interface module was language agnostic and so LINKAGE sections weren't 
needed. The MicroFocus COBOL projects called C functions.
  
COPY books were fairly common on ICL 1900 projects. 

The ICL 2900 world used COPY books too, though it implemented them as 
calls to the Advanced Data Dictionary) rather than as traditional copy 
libraries, and handled the IDMSX database interactions via a preprocessor 
that converted pseudo-COBOL statements COBOL programs into COBOL 
subroutine calls. The IDMSX schema processor converted schema definitions 
into the COBOL subroutines called by application programs. All quite 
neat, easy to use, and worked very well.
  


-- 
--  
Martin    | martin at
Gregorie  | gregorie dot org

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

#216184

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Wed, 6 Jan 2021 08:25:33 -0000 (UTC), Martin Gregorie
> <martin@mydomain.invalid> declaimed the following:
> 
> 
>> 
>> COBOL is another language that historically tended to support only the 
>> latest syntax, which is a pain since source files can be huge. I've 
>> worked on COBOL program modules that ran to over 5000 lines back in the 
>> day, i.e before 1978, when COBOL didn't yet support writing separately 
>> compiled subroutines (no LINKAGE SECTION), though AFAIK COBOL has always 
>> supported calling subroutines written in other languages).
> 
> 	LINKAGE SECTION was part of the COBOL-74 standard, and I recall it
> existed on the Xerox Sigma-6 COBOL that was used at my college when I
> attended (76-80). Our assignments may not have used it -- or we only had a
> short intro to the concept.
> 
> 	However, I'm fairly certain my college compiler did not support "copy
> books"... And since that time-frame meant 24x80 text terminals, and line
> mode text editors, one would have to manually duplicate the section from a
> listing... Or write the program on the IBM 029 card punch -- feeding the
> linkage section into it in duplicate mode, then inserting the copy into the
> second file...
> 

Either your memory is off or this was some site restriction. I did a lot of
COBOL on a Sigma 6, and I’m sure I would have remembered this. I’m trying
to recall the dates, but the numbers won’t come - mid 70s maybe? We started
using BPM/BTM and moved on to UTS when it was released.

-- 
Pete

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

#216092

Martin Gregorie <martin@mydomain.invalid> writes:
>On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>
>> You shouldn’t need declarations in C unless you’re using one of those
>> new-fangled compilers that requires them. Old code should still be
>> supported, though.
>>
>Last time I tried it, (about 2 months ago), the current GNU C compiler 
>accepts the old K&R C first edition procedure declaration syntax. I wish 
>more compilers worked this way.

It will not, however, accept the original V6 C "a =+ b" ambiguous syntax,
so older code may still need to be edited before compilation with a modern
compiler.

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

#216093

On Wed, 06 Jan 2021 15:15:36 +0000, Scott Lurndal wrote:

> Martin Gregorie <martin@mydomain.invalid> writes:
>>On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>>
>>> You shouldn’t need declarations in C unless you’re using one of those
>>> new-fangled compilers that requires them. Old code should still be
>>> supported, though.
>>>
>>Last time I tried it, (about 2 months ago), the current GNU C compiler
>>accepts the old K&R C first edition procedure declaration syntax. I wish
>>more compilers worked this way.
> 
> It will not, however, accept the original V6 C "a =+ b" ambiguous
> syntax, so older code may still need to be edited before compilation
> with a modern compiler.

I don't *think* I've ever written that or even seen it in valid code. 


-- 
--  
Martin    | martin at
Gregorie  | gregorie dot org

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

#216096

Martin Gregorie <martin@mydomain.invalid> writes:
>On Wed, 06 Jan 2021 15:15:36 +0000, Scott Lurndal wrote:
>
>> Martin Gregorie <martin@mydomain.invalid> writes:
>>>On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>>>
>>>> You shouldn’t need declarations in C unless you’re using one of those
>>>> new-fangled compilers that requires them. Old code should still be
>>>> supported, though.
>>>>
>>>Last time I tried it, (about 2 months ago), the current GNU C compiler
>>>accepts the old K&R C first edition procedure declaration syntax. I wish
>>>more compilers worked this way.
>> 
>> It will not, however, accept the original V6 C "a =+ b" ambiguous
>> syntax, so older code may still need to be edited before compilation
>> with a modern compiler.
>
>I don't *think* I've ever written that or even seen it in valid code. 
>

From the V6 C compiler source:

        /*
         * The hash table locations of the keywords
         * are marked; if an identifier hashes to one of
         * these locations, it is looked up in in the keyword
         * table first.
         */
        for (ip=kwtab; (sp = ip->kwname); ip++) {
                i = 0;
                while (*sp)
                        i =+ *sp++;
                hshtab[i%hshsiz].hflag = FKEYW;
        }

Note also that in that version of the compiler, MOS
(member of structure) names were global and could be
used with any pointer regardless of type.

https://github.com/mortdeus/legacy-cc/blob/master/last1120c/c00.c

This makes it difficult to build the original V6 c compiler using
a modern compiler :-)

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

#216099

On Wed, 06 Jan 2021 17:07:35 +0000, Scott Lurndal wrote:

> Martin Gregorie <martin@mydomain.invalid> writes:
>>On Wed, 06 Jan 2021 15:15:36 +0000, Scott Lurndal wrote:
>>
>>> Martin Gregorie <martin@mydomain.invalid> writes:
>>>>On Tue, 05 Jan 2021 14:06:57 -0700, Peter Flass wrote:
>>>>
>>>>> You shouldn’t need declarations in C unless you’re using one of
>>>>> those new-fangled compilers that requires them. Old code should
>>>>> still be supported, though.
>>>>>
>>>>Last time I tried it, (about 2 months ago), the current GNU C compiler
>>>>accepts the old K&R C first edition procedure declaration syntax. I
>>>>wish more compilers worked this way.
>>> 
>>> It will not, however, accept the original V6 C "a =+ b" ambiguous
>>> syntax, so older code may still need to be edited before compilation
>>> with a modern compiler.
>>
>>I don't *think* I've ever written that or even seen it in valid code.
>>
>>
> From the V6 C compiler source:
> 
>         /*
>          * The hash table locations of the keywords * are marked; if an
>          identifier hashes to one of * these locations, it is looked up
>          in in the keyword * table first.
>          */
>         for (ip=kwtab; (sp = ip->kwname); ip++) {
>                 i = 0;
>                 while (*sp)
>                         i =+ *sp++;
>                 hshtab[i%hshsiz].hflag = FKEYW;
>         }
> 
> Note also that in that version of the compiler, MOS (member of
> structure) names were global and could be used with any pointer
> regardless of type.
> 
> https://github.com/mortdeus/legacy-cc/blob/master/last1120c/c00.c
> 
> This makes it difficult to build the original V6 c compiler using a
> modern compiler :-)

Quite!




-- 
--  
Martin    | martin at
Gregorie  | gregorie dot org

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

#216058

On 05/01/2021 10:28, The Natural Philosopher wrote:
> Yes. I am certain that certain compilers and certain languages leave a 
> fingerprint, Always THAT resister, used to do THAT job, always that 
> particular sequence of assembly to mimic that high level construct.

They certainly do, I wrote !ARMalyser to analyse RISC OS executables and 
to aid the conversion from the old 26 bit ARM mode to modern Aarch32. It 
was very obvious if Norcroft C, GCC or handwritten assembly had been 
used by looking at any chunk of the code, not just the obvious file headers.

> I think it is up to a limited point entirely possible to make an AI that 
> could replace  machine code with editable and compilable  source code.
> But there will always be the Problem Of Induction. Many many possible 
> constructs in source using an infinite number of random variable and 
> function  names, could compile to the same object code. And there is no 
> way to reinstate the comments either, so it becomes an exercise 
> ultimately in hand editing and reinstating the comments manually - 
> almost as big a job as writing from scratch.

I was not attempting to turn the executable in to a high level language, 
but to give the user as much help understanding the assembler code as 
possible, to aid the conversion.

At the lowest level identifying what was code and what was data, easy in 
well defined executable formats produced by compilers, but hard in 
handwritten assembler, which had often used every trick in the book to 
squeeze out performance on a 8MHz ARM2 with 512MB of RAM.

The next step was using knowledge of the Standard C Library functions 
and SWI APIs to annotate the registers passed and returned from the APIs 
and where those registers contain static addresses, the data blocks they 
point to.

To allow code to be modified with additional instructions to recreate 
flag preserving behaviour of the 26 bit code (in the few cases it is 
actually necessary) and data added to make the larger 32 bit file 
headers, all code and data addresses are identified and converted in to 
labels.

ARMalyser outputs in the standard Object Assembler syntax so it can be 
reassembled to produce an identical executable, and subsequently 
modified. It can also add syntax colouring in various formats such as 
XML, HTML/CSS for viewing.

If you were in marketing you could say the code which does this is 'AI', 
but its really a huge chunk of tangled heuristics, which works well most 
of the time, but occasionally miss-identifies code or data. Its a bit 
too eager to identify code, due to the tricks assembler programmers 
used, if I ripped all that out and only worked on compiler generated 
executables, it would be a lot more reliable.

---druck

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

#215950

On 04/01/2021 16:05, Dennis Lee Bieber wrote:
> 	Actually, I think the use of disassemblers et al has fallen away.
> Modern processors have so many peephole optimizations and out-of-order
> execution streams that converting an executable back to assembly source is
> almost meaningless -- and getting back to a high-level language is near
> impossible. One would have to be an expert at the assembly for a processor
> to have any chance of understanding the result.
>
>

AF6VN DE G4SDW

But we Radio Hams thrive on such low level technicalities!  :-)

73.

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web