Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.raspberry-pi > #25425 > unrolled thread
| Started by | gareth evans <headstone255@yahoo.com> |
|---|---|
| First post | 2021-01-04 11:00 +0000 |
| Last post | 2021-02-12 15:40 +0000 |
| Articles | 20 on this page of 157 — 28 participants |
Back to article view | Back to comp.sys.raspberry-pi
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? 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? gareth evans <headstone255@yahoo.com> - 2021-01-05 20:20 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 22:23 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-06 00:14 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-06 02:17 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:39 +0100
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-08 15:07 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-08 15:56 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 15:35 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-08 20:02 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-10 15:12 +0100
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 09:36 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 10:43 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:09 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 18:29 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:37 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 21:03 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:45 +0100
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-08 18:06 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 18:44 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-09 03:02 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-09 02:58 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-06 18:35 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:39 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-06 19:03 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 19:08 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-06 19:19 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-07 04:07 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-07 12:59 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:41 -0500
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-09 12:25 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-09 12:46 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 15:49 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-09 18:33 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 19:20 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-09 21:05 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 23:19 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 12:17 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-09 16:54 -0500
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 23:48 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-10 02:00 +0000
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-09 18:36 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 19:28 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 12:15 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 12:33 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 13:18 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 14:01 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 15:14 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 13:59 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 14:46 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 15:34 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 15:05 +0000
Re: AI and decompilation? Axel Berger <Spam@Berger-Odenthal.De> - 2021-01-10 17:28 +0100
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-11 17:25 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 15:13 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 15:35 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 15:35 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 17:23 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 18:17 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-11 03:44 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-11 11:00 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-11 03:36 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-06 21:34 +0000
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-06 18:37 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:09 -0500
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 09:32 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:56 +0100
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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-06 16:09 +0000 |
| Message-ID | <rt4nc4$f8a$2@dont-email.me> |
| In reply to | #25546 |
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-01-06 17:07 +0000 |
| Message-ID | <r7mJH.9680$cj2.60@fx29.iad> |
| In reply to | #25549 |
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]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-06 17:38 +0000 |
| Message-ID | <rt4sj7$f8a$4@dont-email.me> |
| In reply to | #25553 |
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]
| From | druck <news@druck.org.uk> |
|---|---|
| Date | 2021-01-05 21:20 +0000 |
| Message-ID | <rt2l7m$cll$1@dont-email.me> |
| In reply to | #25460 |
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]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-04 17:47 +0000 |
| Message-ID | <rsvkb2$2s5$1@dont-email.me> |
| In reply to | #25436 |
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]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2021-01-04 14:18 -0500 |
| Message-ID | <rsvpmo$bfb$1@dont-email.me> |
| In reply to | #25436 |
Dennis Lee Bieber <wlfraed@ix.netcom.com> writes: > 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. Well, in my last job I often used disassemblers. IBM z/OS. Very useful for understanding IBM code. I can't see what out of order execution has to do with a disassembler. You disassemble executables. Since I understand Assembler, I certainly got meaning out of it even if the original was an optimized HLL. You can see what services are being called. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-04 16:54 -0700 |
| Message-ID | <189325689.631496758.708516.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25443 |
Dan Espen <dan1espen@gmail.com> wrote: > Dennis Lee Bieber <wlfraed@ix.netcom.com> writes: > >> 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. > > Well, in my last job I often used disassemblers. > IBM z/OS. > Very useful for understanding IBM code. I was going to say that disassemblers for IBM seem to work fairly well. I’ve used them a few times. > > I can't see what out of order execution has to do with a disassembler. > You disassemble executables. > > Since I understand Assembler, I certainly got meaning out of it > even if the original was an optimized HLL. You can see what services > are being called. > I think, for example, that one disassembler might recognize the SVC number.i think it put the macro name in as a comment (LINK, GETMAIN, etc.) -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2021-01-04 23:01 +0000 |
| Message-ID | <Xjr*mEo-x@news.chiark.greenend.org.uk> |
| In reply to | #25436 |
Dennis Lee Bieber <wlfraed@ix.netcom.com> 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. Apple essentially do this for their Rosetta 2 x86-to-ARM converter. They take existing x86 executables, which are likely generated by their Xcode LLVM compiler. They convert the assembly back into LLVM's intermediate representation, which is the idealised-assembly representation most of the compiler stages work on. Then they push that IR through the regular ARM LLVM backend, including optimiser stages, to produce 64-bit ARM executables. It's not a language intended for humans to read, but it's high enough for the compiler stages to work on. Doing it this way avoids having to emulate any ARM instructions. Theo
[toc] | [prev] | [next] | [standalone]
| From | Eli the Bearded <*@eli.users.panix.com> |
|---|---|
| Date | 2021-01-04 20:11 +0000 |
| Message-ID | <eli$2101041456@qaz.wtf> |
| In reply to | #25425 |
In comp.sys.raspberry-pi, gareth evans <headstone255@yahoo.com> wrote: > But I wonder if Artificial Intelligence could, after > being fed with numerous instruction sets, take a > block of binary, and analyse its source without > any prior knowledge of the instruction set? I suspect AI could be trained to do that, perhaps better than being trained to read English. Not sure if anyone has ever tried. > I am particularly interested in the Binary Blob > provided for Raspberry Pi computers, with a view to > getting detailed knowledge of the video processors > employed therein. The info-sec people use disassemblers all the time, and don't limit themselves to compiled from C and intended for Windows binaries. They try to extract passwords and locate flaws in firmware for all sorts of internet-connected things. I recall Cybergibbons creating some tutorials in November or December. It was linked from his twitter account, but I didn't pay that close attention to where it was. A quick look at his blog and youtube didn't find them, but he's got a robust web presence. Elijah ------ have you searched if anyone else has reversed engineered it already?
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2021-01-05 09:07 +0000 |
| Message-ID | <87k0srah12.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #25425 |
gareth evans <headstone255@yahoo.com> writes: > 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? > > But I wonder if Artificial Intelligence could, after > being fed with numerous instruction sets, take a > block of binary, and analyse its source without > any prior knowledge of the instruction set? > > I am particularly interested in the Binary Blob > provided for Raspberry Pi computers, with a view to > getting detailed knowledge of the video processors > employed therein. Why would you do that instead of reading a reference manual for the target architecture? -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2021-01-05 09:47 +0000 |
| Message-ID | <20210105094747.a0b43d4f7d1719b1e7cb7869@eircom.net> |
| In reply to | #25458 |
On Tue, 05 Jan 2021 09:07:21 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote: > gareth evans <headstone255@yahoo.com> writes: > > I am particularly interested in the Binary Blob > > provided for Raspberry Pi computers, with a view to > > getting detailed knowledge of the video processors > > employed therein. > > Why would you do that instead of reading a reference manual for the > target architecture? The documentation for the GPU on the RPi has not been published, he seeks to reverse engineer it from the binary code that implements a published API on it. -- 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]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2021-01-05 11:13 +0000 |
| Message-ID | <87eeizab7k.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #25459 |
Ahem A Rivet's Shot <steveo@eircom.net> writes: > Richard Kettlewell <invalid@invalid.invalid> wrote: >> gareth evans <headstone255@yahoo.com> writes: >>> I am particularly interested in the Binary Blob >>> provided for Raspberry Pi computers, with a view to >>> getting detailed knowledge of the video processors >>> employed therein. >> >> Why would you do that instead of reading a reference manual for the >> target architecture? > > The documentation for the GPU on the RPi has not been published, > he seeks to reverse engineer it from the binary code that implements a > published API on it. I was under the impression it was a VideoCore IV, which appears to be sufficiently documented for GNU toolchain port. https://docs.broadcom.com/doc/12358545 https://github.com/itszor/vc4-toolchain -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 12:12 +0000 |
| Message-ID | <rt1l2u$o0a$1@dont-email.me> |
| In reply to | #25464 |
On 05/01/2021 11:13, Richard Kettlewell wrote: > Ahem A Rivet's Shot <steveo@eircom.net> writes: >> Richard Kettlewell <invalid@invalid.invalid> wrote: >>> gareth evans <headstone255@yahoo.com> writes: >>>> I am particularly interested in the Binary Blob >>>> provided for Raspberry Pi computers, with a view to >>>> getting detailed knowledge of the video processors >>>> employed therein. >>> >>> Why would you do that instead of reading a reference manual for the >>> target architecture? >> >> The documentation for the GPU on the RPi has not been published, >> he seeks to reverse engineer it from the binary code that implements a >> published API on it. > > I was under the impression it was a VideoCore IV, which appears to be > sufficiently documented for GNU toolchain port. > > https://docs.broadcom.com/doc/12358545 > https://github.com/itszor/vc4-toolchain > The first of those does not produce anything. Does the second describe the GPU in some detail and describe the instruction set such that I might produce my own binary blob to do something completely different? Also, AIUI, a different GPU has been incorporated into the 64-bit RPis. Anyway, thanks for your input.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2021-01-05 13:39 +0000 |
| Message-ID | <878s97a4g4.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #25471 |
gareth evans <headstone255@yahoo.com> writes: > On 05/01/2021 11:13, Richard Kettlewell wrote: >> Ahem A Rivet's Shot <steveo@eircom.net> writes: >>> The documentation for the GPU on the RPi has not been published, >>> he seeks to reverse engineer it from the binary code that implements a >>> published API on it. >> >> I was under the impression it was a VideoCore IV, which appears to be >> sufficiently documented for GNU toolchain port. >> >> https://docs.broadcom.com/doc/12358545 >> https://github.com/itszor/vc4-toolchain > > The first of those does not produce anything. It’s the VideoCore IV 3D Architecture Reference Guide. > Does the second describe the GPU in some detail and describe > the instruction set such that I might produce my own binary blob > to do something completely different? It’s a toolchain port. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 15:32 +0000 |
| Message-ID | <rt20pq$b2q$2@dont-email.me> |
| In reply to | #25476 |
On 05/01/2021 13:39, Richard Kettlewell wrote: > gareth evans <headstone255@yahoo.com> writes: >> On 05/01/2021 11:13, Richard Kettlewell wrote: >>> Ahem A Rivet's Shot <steveo@eircom.net> writes: >>>> The documentation for the GPU on the RPi has not been published, >>>> he seeks to reverse engineer it from the binary code that implements a >>>> published API on it. >>> >>> I was under the impression it was a VideoCore IV, which appears to be >>> sufficiently documented for GNU toolchain port. >>> >>> https://docs.broadcom.com/doc/12358545 >>> https://github.com/itszor/vc4-toolchain >> >> The first of those does not produce anything. > > It’s the VideoCore IV 3D Architecture Reference Guide. Perhaps not available to the Man On The Clapham Omnibus. Are you in a privileged position with Broadcom to have such access?
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 15:40 +0000 |
| Message-ID | <rt219c$di9$2@dont-email.me> |
| In reply to | #25487 |
On 05/01/2021 15:32, gareth evans wrote: > On 05/01/2021 13:39, Richard Kettlewell wrote: >> gareth evans <headstone255@yahoo.com> writes: >>> On 05/01/2021 11:13, Richard Kettlewell wrote: >>>> Ahem A Rivet's Shot <steveo@eircom.net> writes: >>>>> The documentation for the GPU on the RPi has not been published, >>>>> he seeks to reverse engineer it from the binary code that implements a >>>>> published API on it. >>>> >>>> I was under the impression it was a VideoCore IV, which appears to be >>>> sufficiently documented for GNU toolchain port. >>>> >>>> https://docs.broadcom.com/doc/12358545 >>>> https://github.com/itszor/vc4-toolchain >>> >>> The first of those does not produce anything. >> >> It’s the VideoCore IV 3D Architecture Reference Guide. > > Perhaps not available to the Man On The Clapham Omnibus. > > Are you in a privileged position with Broadcom to have > such access? > > Mea Culpa !!!!!!!! Firefox did not display anything but was quietly downloading the PDF in the background without me realising!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-01-05 16:02 +0000 |
| Message-ID | <140JH.47697$li2.31337@fx22.iad> |
| In reply to | #25471 |
gareth evans <headstone255@yahoo.com> writes: >On 05/01/2021 11:13, Richard Kettlewell wrote: >> Ahem A Rivet's Shot <steveo@eircom.net> writes: >>> Richard Kettlewell <invalid@invalid.invalid> wrote: >>>> gareth evans <headstone255@yahoo.com> writes: >>>>> I am particularly interested in the Binary Blob >>>>> provided for Raspberry Pi computers, with a view to >>>>> getting detailed knowledge of the video processors >>>>> employed therein. >>>> >>>> Why would you do that instead of reading a reference manual for the >>>> target architecture? >>> >>> The documentation for the GPU on the RPi has not been published, >>> he seeks to reverse engineer it from the binary code that implements a >>> published API on it. >> >> I was under the impression it was a VideoCore IV, which appears to be >> sufficiently documented for GNU toolchain port. >> >> https://docs.broadcom.com/doc/12358545 >> https://github.com/itszor/vc4-toolchain >> > >The first of those does not produce anything. Except a PDF entitled "VideoCore IV 3d Architecture Reference Guide". Check your downloads directory. e.g. Fragment shaders are started automatically each time the FEP accumulates a vector of up to four quads (16 pixels) to shade together. The quad input data from the FEP is automatically written into per-thread QPU registers when the fragment shader is started. The following data is written to these QPU registers, in addition to the normal PC address, uniforms base address, and uniforms size:
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2021-01-05 18:27 +0000 |
| Message-ID | <20210105182745.1cd73b52cf71f605f8f29d81@eircom.net> |
| In reply to | #25464 |
On Tue, 05 Jan 2021 11:13:03 +0000 Richard Kettlewell <invalid@invalid.invalid> wrote: > I was under the impression it was a VideoCore IV, which appears to be > sufficiently documented for GNU toolchain port. > > https://docs.broadcom.com/doc/12358545 Whoah there, that was proprietary and NDS only last time I looked. Seems Broadcom have been decent while I wasn't looking - good news! -- 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]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2021-01-05 21:15 +0000 |
| Message-ID | <rt2kto$7s1$1@dont-email.me> |
| In reply to | #25464 |
On 05/01/2021 11:13, Richard Kettlewell wrote: > I was under the impression it was a VideoCore IV, which appears to be > sufficiently documented for GNU toolchain port. > > https://docs.broadcom.com/doc/12358545 > https://github.com/itszor/vc4-toolchain I understand that the latest Pi is indeed a VC4. Be aware that as a SIMD processor it's ... odd. Very odd. That documentation ties up with what I remember about the device, and I wish I'd had it when I was working on it. Andy
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 22:54 +0000 |
| Message-ID | <rt2qn1$h9p$3@dont-email.me> |
| In reply to | #25503 |
On 05/01/2021 21:15, Vir Campestris wrote: > On 05/01/2021 11:13, Richard Kettlewell wrote: >> I was under the impression it was a VideoCore IV, which appears to be >> sufficiently documented for GNU toolchain port. >> >> https://docs.broadcom.com/doc/12358545 >> https://github.com/itszor/vc4-toolchain > > I understand that the latest Pi is indeed a VC4. > > Be aware that as a SIMD processor it's ... odd. Very odd. > > That documentation ties up with what I remember about the device, and I > wish I'd had it when I was working on it. > You were working on it? What can you tell us?
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.sys.raspberry-pi
csiph-web