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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Andy Burns <usenet@andyburns.uk> |
|---|---|
| Date | 2021-01-06 21:34 +0000 |
| Message-ID | <i5mompFbsfmU1@mid.individual.net> |
| In reply to | #25562 |
The Natural Philosopher wrote: > Andy Burns wrote: > >> The Natural Philosopher wrote: >> >>> Sadly javaScript is all you get in a browser >> >> or wasm, which can run compiled code > > How can you run code compiled for *86 on a ARM based browser? It's compiled to something like p-code
[toc] | [prev] | [next] | [standalone]
| From | druck <news@druck.org.uk> |
|---|---|
| Date | 2021-01-06 18:37 +0000 |
| Message-ID | <rt501k$8o5$1@dont-email.me> |
| In reply to | #25557 |
On 06/01/2021 18:09, The Natural Philosopher wrote: > On 06/01/2021 10:43, Martin Gregorie wrote: >> ... well, if you use crappy interpreted languages with untyped variables >> then you've chosen to accept that sort of thing as normal. >> > Sadly javaScript is all you get in a browser Typescript has stronger typing and executes as standard javascript in the Browser. ---druck
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-08 21:09 -0500 |
| Message-ID | <cv3ivf53fap2rinfs8cec9e2pediqln1sv@4ax.com> |
| In reply to | #25499 |
On Tue, 5 Jan 2021 20:20:27 +0000, gareth evans <headstone255@yahoo.com> declaimed the following: >Why any coder would want a procname with different calling lists is >beyond me. > You haven't looked at Ada, which uses the return type and the argument types to determine which variant of a procedure is to be invoked. And may OOP languages may also support such when overloading/overriding a parent's method. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2021-01-06 09:32 +0000 |
| Message-ID | <rt4032$p43$2@dont-email.me> |
| In reply to | #25497 |
On 05/01/2021 20:12, Charlie Gibbs wrote: > On 2021-01-05, Martin Gregorie <martin@mydomain.invalid> wrote: > >> On Tue, 05 Jan 2021 15:30:06 +0000, gareth evans wrote: >> >>> That it warrants such an involved explanation is very good reason why >>> such techniques should be avoided today! :-) >> >> Agreed. >> >> That sort of thing is so much easier in Java or Algol 68, which both >> recognise that methods/procedures with the same name but different >> parameter lists are indeed different pieces of code rather than a stupid >> mistake. > > I avoid that technique - it invites other stupid mistakes. > +1. The smarter the language the stupider the coder in my experience. Same goes for smart phones. -- A lie can travel halfway around the world while the truth is putting on its shoes.
[toc] | [prev] | [next] | [standalone]
| From | Björn Lundin <b.f.lundin@gmail.com> |
|---|---|
| Date | 2021-01-08 14:56 +0100 |
| Message-ID | <rt9ob3$bke$1@dont-email.me> |
| In reply to | #25521 |
Den 2021-01-06 kl. 10:32, skrev The Natural Philosopher: >>> >> >> I avoid that technique - it invites other stupid mistakes. >> > +1. The smarter the language the stupider the coder in my experience. > Same goes for smart phones. Most coder are not smart. They do cut & paste with all error that comes from it. Having a language that compiles everything but fails at run-time is a sure way to the debugger and maintenance hell and high costs. Some say a good coder get by in any language - I say bullshit. The language is the coders tool -nothing else. A truck is the truck drivers tool. And If I want to move 50 tons of sand efficiently I use a truck - not a tuk-tuk. Even though I recognize that a tuk.tuk can be used. But it is the wrong tool for the job. And the job _most_ coders have is maintenance. And a stupid language is the wrong tool for that. Instead - a strongly typed langue is the right tool, since it gives _compile-time-errors_ that are cheap to fix, instead of run-time errors that are more expensive to fix. And deployed at customer - and crash ? downtime is very expensive - at least if the code does something significant for the customer. One of our customer says €150_000/hr for downtime. -- Björn
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-05 14:25 -0700 |
| Message-ID | <1340975602.631574107.754356.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25474 |
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]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2021-01-06 14:17 +0200 |
| Message-ID | <rt49or$osp$1@dont-email.me> |
| In reply to | #25474 |
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]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2021-01-06 12:42 +0000 |
| Message-ID | <20210106124205.4d5bafa6e192332dbd5ea6a5@eircom.net> |
| In reply to | #25537 |
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]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2021-01-06 16:42 +0200 |
| Message-ID | <rt4i9d$k28$1@dont-email.me> |
| In reply to | #25540 |
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]
| From | "Kerr-Mudd,John" <notsaying@127.0.0.1> |
|---|---|
| Date | 2021-01-08 09:48 +0000 |
| Message-ID | <XnsACAC63D1DB366admin127001@144.76.35.252> |
| In reply to | #25540 |
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]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2021-01-08 10:27 +0000 |
| Message-ID | <20210108102751.e398876beda0dbe798f09532@eircom.net> |
| In reply to | #25599 |
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]
| From | usenet@only.tnx (Questor) |
|---|---|
| Date | 2021-01-08 21:40 +0000 |
| Message-ID | <5ff8d140.8997117@news.dslextreme.com> |
| In reply to | #25537 |
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]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-05 14:06 -0700 |
| Message-ID | <555950032.631567792.766124.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25460 |
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]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-05 22:27 +0000 |
| Message-ID | <rt2p4e$r81$2@dont-email.me> |
| In reply to | #25502 |
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]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-01-06 00:14 +0000 |
| Message-ID | <rt2vd71214r@news3.newsguy.com> |
| In reply to | #25508 |
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]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-06 08:25 +0000 |
| Message-ID | <rt3s5t$t3t$1@dont-email.me> |
| In reply to | #25514 |
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]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-08 21:52 -0500 |
| Message-ID | <p46ivfdjq3rd6c14de1f6plhb28787vhi7@4ax.com> |
| In reply to | #25520 |
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]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-09 15:37 +0000 |
| Message-ID | <rtcijc$563$3@dont-email.me> |
| In reply to | #25632 |
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]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-10 06:40 -0700 |
| Message-ID | <1358352147.631978548.007137.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25632 |
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-01-06 15:15 +0000 |
| Message-ID | <sukJH.98122$x92.32141@fx48.iad> |
| In reply to | #25508 |
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]
Page 6 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