Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #145830 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2019-08-28 16:11 -0500 |
| Last post | 2019-09-09 01:09 -0700 |
| Articles | 20 on this page of 144 — 32 participants |
Back to article view | Back to comp.lang.c
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-28 16:11 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-28 15:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 00:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Les Cargill <lcargill99@comcast.com> - 2019-09-01 17:31 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-29 02:36 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 11:02 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 22:21 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 13:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 13:29 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 23:11 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 10:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 07:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:54 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:07 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 05:14 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 15:00 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 10:39 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Thiago Adams <thiago.adams@gmail.com> - 2019-08-30 04:24 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-30 20:52 +0100
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:07 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-03 17:13 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:53 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" gazelle@shell.xmission.com (Kenny McCormack) - 2019-08-29 13:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 15:38 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:09 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-04 08:31 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:38 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 11:41 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 11:56 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 13:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 05:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 18:22 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-01 12:20 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:23 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 22:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-02 00:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 06:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 11:12 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 17:52 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-02 18:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 13:05 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 19:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 06:49 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 08:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 08:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 09:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 09:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 10:30 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-03 07:11 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 13:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 15:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-03 17:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 17:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 18:51 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:42 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:56 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 07:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-06 12:32 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:33 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:38 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" antispam@math.uni.wroc.pl - 2019-09-03 22:08 +0000
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:41 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:50 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 22:43 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-09-03 11:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 22:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Clifford Heath <no.spam@please.net> - 2019-09-04 10:47 +1000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-04 16:56 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-03 05:37 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Hans im Glück <hig68@gmx.at> - 2019-09-03 15:26 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-03 06:54 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 16:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:16 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 19:07 +0200
Re: Exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-04 06:12 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:14 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-09-05 22:02 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-31 13:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:45 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 14:08 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 13:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-08-30 05:01 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 15:18 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 14:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:23 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:40 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-30 07:56 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 15:08 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 19:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Anton Shepelev <anton.txt@gmail.com> - 2019-08-31 03:05 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 12:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-08-31 10:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 11:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-31 17:17 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 16:28 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 00:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-01 15:49 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:12 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-09-08 10:23 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-08 20:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-09 12:51 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:57 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:42 +0200
Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" Juha Nieminen <nospam@thanks.invalid> - 2019-08-30 21:03 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 09:42 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 23:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 06:24 -0500
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 13:51 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 22:03 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@hotmail.com> - 2019-09-07 10:57 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-09-07 18:09 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-07 15:32 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 18:39 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-09-04 01:07 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" William Ahern <william@25thandClement.com> - 2019-09-03 20:04 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-04 04:48 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com> - 2019-09-09 01:09 -0700
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 16:12 +0200 |
| Message-ID | <qkgjk7$tat$1@dont-email.me> |
| In reply to | #145894 |
On 01/09/2019 14:49, Paavo Helde wrote: > On 1.09.2019 1:06, David Brown wrote: >> On 31/08/2019 16:17, Paavo Helde wrote: >>> On 31.08.2019 3:05, Anton Shepelev wrote: >> >> RAII to protect resources is not remotely dependent on exceptions : > > Sure, but exceptions are dependent on RAII. Without RAII it is not > really feasible to use exceptions, as demonstrated by ugly, tedious and > error-prone 'finally' clauses in C# and elsewhere. > Agreed. You need RAII - or, more specifically, deterministic destructors - for exceptions to work well. My point is merely that you get the RAII advantages no matter how you handle errors or unusual situations, whether it be C++ exceptions, future "zero overhead" or "checked" exceptions, error return codes, or anything else. >>> > Code with exceptions is not >>>> local because its execution depends on any try blocks >>>> anywhere up the call stack. Code with exceptions is not >>>> transparent, because it hides the error-handling part of the >>>> algorithm, and incomplete information is akin to a lie. >>> >>> This might sound nice in theory, but in reality the error handling >>> part cannot be part of the actual code because more often than not >>> this code has no idea how to react to the error. >> >> And therein lies the problem, when you are concerned with being able to >> be sure your code is correct (both by design, and by testing). >> >>> Let's say an input data file cannot be opened by some number-crunching >>> library. How should it handle this error? Should it abort the whole >>> program, or should it pop up a dialog asking the user to correct the >>> problem and retry? What if it runs in a web server where there is no >>> user to click on the dialog? >> >> Separate the concerns. Don't make a function (or class, or unit, or >> whatever code size is appropriate) that reads data from a file and >> crunches it. Make a function that reads data from the file. Make >> another function that crunches data. > > There is no difference, the function reading the data still has no clue > how to "handle" an error. That can be true - but a key difference is that the reading function knows there can be errors. It might not handle those errors, but it does not ignore the possibility of their existence. > >> Or make a function that will attempt to read the data from the file and >> crunch it, returning the correct result or some sort of error indicator >> when a problem is found. That error indicator could be an error code, a >> std::optional nullopt, a tuple field in the result - or a thrown >> exception. > > Right, the function cannot handle the error by itself and reports it > back to the caller. Ergo, the error handling code resides somewhere else > than in this low-level function, ruining the dubious "transparency" > ideal advocated by GP. > > The distance between error detection and handling is different in > different kind of software. It might be that the error is handled 1 - 2 > call stack frames up, making the error code approach pretty > straightforward. In the code I usually work with this distance is > typically 10 - 20 call stack frames, making the exceptions approach much > more convenient. > Sure, if exceptions are right for your code, use exceptions. I am not suggesting that exceptions are bad - merely that they are not always the best choice.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-09-08 10:23 -0700 |
| Message-ID | <9e4faed0-78a5-41f1-93ef-bbd901d6d1b7@googlegroups.com> |
| In reply to | #145878 |
On Friday, August 30, 2019 at 8:19:25 PM UTC+3, Bonita Montero wrote: > >> press any key to continue or any other to quit... > >> U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec > >> Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi > >> bili naoruzani. -- Mladen Gogala > > > IMHO, you are barking up the wrong tree. > > EH is bad not because it's slow or costly, but because of its messy semantics. > > What's messy with the semantics? You like authorities, right? E.g. you professors? Here is an answer from pretty high authority. https://google.github.io/styleguide/cppguide.html#Exceptions Just one of many possible answers and not necessarily the one I agree with. For my taste the answer still contains too many pro-exceptions sentiments coming from academic propaganda rather than from deep development experience. But at least a bottom line (headline, it this case) is correct.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-08 20:29 +0200 |
| Message-ID | <ql3hap$r8f$1@news.albasani.net> |
| In reply to | #146094 |
> You like authorities, right? E.g. you professors?
> Here is an answer from pretty high authority.
> https://google.github.io/styleguide/cppguide.html#Exceptions
That are not academic statements but rather a matter of taste.
"When you add a throw statement to an existing function, you must
examine all of its transitive callers. Either they must make at
least the basic exception safety guarantee, or they must never
catch the exception and be happy with the program terminating
as a result. For instance, if f() calls g() calls h(), and h
throws an exception that f catches, g has to be careful or it
may not clean up properly.":
Simply either derive all exceptions from a single class (I derive
my exceptions from std::exception) and if you glue a secondary
library catch the base-class of that exception-hierarchy also in
a central point. But catching the exceptions more specifically
at a more appropropriate point and more specifically isn't hard
if you have a poper documentation.
"More generally, exceptions make the control flow of programs
difficult to evaluate by looking at code: functions may return
in places you don't expect. This causes maintainability and
debugging difficulties. You can minimize this cost via some
rules on how and where exceptions can be used, but at the cost
of more that a developer needs to know and understand."
That's´not a con, that's a pro in most cases. F.e. you usually
don't have to know where an operation failed; you simply have
to know that it failed.
"Exception safety requires both RAII and different coding practices.
Lots of supporting machinery is needed to make writing correct
exception-safe code easy. Further, to avoid requiring readers to
understand the entire call graph, exception-safe code must isolate
logic that writes to persistent state into a "commit" phase. This
will have both benefits and costs (perhaps where you're forced to
obfuscate code to isolate the commit). Allowing exceptions would
force us to always pay those costs even when they're not worth it."
You have to write wrapper-classes to maintain RAIIness. And in some
cases you have to do this for a single use; that's while i long for
something like finally in C++. I helped myself by having a class
called invoke_on_destruct which has a template-parameter of another
class that which is usually a lamda hose operator () is called when
the destructor of this class is called. This looks like this:
auto waitForThread = [&threadLock, pPT]()
{
threadLock.lock();
while( pPT->m_rsp == pool_thread::RSP_NONE )
pPT->m_sigResponse.wait( threadLock );
};
invoke_on_destruct<decltype(waitForThread)> autoWaitForThread(
waitForThread );
But of course a finally would look better because it would be
executed at the point where the code is placed.
"Turning on exceptions adds data to each binary produced,
increasing compile time (probably slightly) and possibly
increasing address space pressure."
Mostly doesn't matter.
"The availability of exceptions may encourage developers to throw
them when they are not appropriate or recover from them when it's
not safe to do so. For example, invalid user input should not cause
exceptions to be thrown. We would need to make the style guide even
longer to document these restrictions!"
You have to be a skilled developer for C++ anyay. A lot of language
-features could be misused.
> Just one of many possible answers and not necessarily the one I
> agree with.
"On their face, the benefits of using exceptions outweigh
the costs, especially in new projects"
> For my taste the answer still contains too many pro-exceptions
> sentiments coming from academic propaganda rather than from deep
> development experience. But at least a bottom line (headline, it
> this case) is correct.
You don't argue from experience but from tase.
[toc] | [prev] | [next] | [standalone]
| From | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-09-09 12:51 -0700 |
| Message-ID | <5d612350-5799-402f-b762-76ee8b997cd2@googlegroups.com> |
| In reply to | #146094 |
On Sunday, September 8, 2019 at 10:23:14 AM UTC-7, already...@yahoo.com wrote: > On Friday, August 30, 2019 at 8:19:25 PM UTC+3, Bonita Montero wrote: > > >> press any key to continue or any other to quit... > > >> U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec > > >> Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi > > >> bili naoruzani. -- Mladen Gogala > > > > > IMHO, you are barking up the wrong tree. > > > EH is bad not because it's slow or costly, but because of its messy semantics. > > > > What's messy with the semantics? > > You like authorities, right? E.g. you professors? Some like answers from professors. Some like having sex before the first date. And some like writing code while drunk.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 16:57 +0200 |
| Message-ID | <qkbdg8$uls$1@news.albasani.net> |
| In reply to | #145874 |
>> No, structured exception handling an the C++ Eh built on top of that >> installs unwind-handleres linked through the stack on each call-level >> that needs special unwind-semantics. >> With the x64-Windows SEH was re-defined table-driven so that both SEH >> and C++-EH have an almost-zero-overhead. > Zero *run time* overhead at the cost of *space* overhead. We're talking abot Windows-computers and not Ardino Unos.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 15:42 +0200 |
| Message-ID | <almarsoft.8871656568901274022@news.albasani.net> |
| In reply to | #145869 |
On Fri, 30 Aug 2019 15:18:21 +0300, Paavo Helde <myfirstname@osa.pri.ee> wrote: > On 30.08.2019 14:37, Mel wrote: > > On Fri, 30 Aug 2019 14:08:47 +0300, Paavo Helde <myfirstname@osa.pri.ee> > > wrote: > >> On 30.08.2019 11:43, Mel wrote: > >> > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero > >> >> The non-throw-case takes almost no or no performance. > >> > > >> > That's no true. You have to install handlers evrry time or > > prepare tbla > >> > for each function at program start... > > > > > >> >> Evaluating return-codes is simply a magnitude slower. > >> > > >> > This is especially not true. > > > > > >> Your information is out of date for a couple of decades. The > > current C++ > >> compilers have implemented zero cost exceptions (in the no-throw > > path) > >> already long time ago. > > > > That's simply impossible. > > > See e.g. http://www.ut.sco.com/developers/products/ehopt.pdf > From that paper: > "Most high-performance EH implementations use the commonly known > table-driven approach. The goal of this approach is to present zero > execution-time overhead, until and unless an exception is thrown." > The paper acknowledges some deficiencies with this goal, mainly missing > some optimization opportunities, then goes further to solve a part of them. > Note this paper is from 1998. The compiler technology has moved forward > meanwhile. > It might be there is some minimal machine code needed for EH like a > register load at function entrance. This does not make it non-zero cost > because the alternative is to use an error return, which would also be > at least a register load plus a branching instruction for checking it in > the caller. I already said 'space or time' -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2019-08-30 21:03 +0000 |
| Subject | Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" |
| Message-ID | <qkc2v5$jfd$1@adenine.netfront.net> |
| In reply to | #145865 |
In comp.lang.c++ Mel <mel@zzzzz.com> wrote: >> Your information is out of date for a couple of decades. The > current C++ >> compilers have implemented zero cost exceptions (in the no-throw > path) >> already long time ago. > > That's simply impossible. That's like saying that a longjmp() being zero-overhead (with respect to all the code that's executed when no jump is done) is "impossible". You can set up a long jump, and no other code that you call gets any slower or suffers from any overhead. It's only when something triggers that long jump that something special happens. Exceptions are not identical to that, but it's not that far off. But the end result is that if no exception is thrown, no code suffers from any overhead.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-08-31 09:42 +1200 |
| Message-ID | <gstji7FmknoU1@mid.individual.net> |
| In reply to | #145858 |
On 30/08/2019 20:43, Mel wrote: > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero > <Bonita.Montero@gmail.com> wrote: > >> The non-throw-case takes almost no or no performance. > > That's no true. You have to install handlers evrry time or prepare > tbla for each function at program start... Have you actually measured the difference? I have on several occasions and yes, the no-throw path with exceptions is faster (even if only slightly) than testing error returns. It is also foolproof.. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 23:53 +0200 |
| Message-ID | <qkc5te$rd5$1@news.albasani.net> |
| In reply to | #145881 |
> It is also foolproof.. It is not absolutely foolproof because there might be exceptions that will be uncaught. That's the reason I like checked exceptions in Java so much. But it is by magnitudes more convenient as to return and evaluate return-codes.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-09-06 06:24 -0500 |
| Message-ID | <qktfl0$dhe$1@dont-email.me> |
| In reply to | #145881 |
On 8/30/2019 4:42 PM, Ian Collins wrote: > On 30/08/2019 20:43, Mel wrote: >> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero >> <Bonita.Montero@gmail.com> wrote: >> >>> The non-throw-case takes almost no or no performance. >> >> That's no true. You have to install handlers evrry time or prepare >> tbla for each function at program start... > > Have you actually measured the difference? I have on several occasions > and yes, the no-throw path with exceptions is faster (even if only > slightly) than testing error returns. It is also foolproof.. > I agree, in this case. A sane implementation of exceptions can use a lookup table for PC/EIP/RIP/whatever, and so only involves significant time overhead when actually throwing an exception. Though, this does work under the assumption that exceptions are used primarily or solely for error handling, and not as a part of the normal control-flow. In most cases, the overhead is primarily in terms of space, namely the cost of storing the lookup tables and the unwind-related logic. Depending some on the ISA and ABI, it may be possible to reduce the size of this table to some extent (for many ABIs it may 8-16 bytes per function and/or try/catch block), and to encode some information needed for unwinding via a predefined format for the epilog (the instruction sequence telling how to unwind the current stack frame), ... Though, granted, this space overhead may still matter in some applications, so it still isn't entirely free. ...
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-09-06 13:51 +0000 |
| Message-ID | <RvtcF.227204$Zz1.24057@fx35.iad> |
| In reply to | #146062 |
BGB <cr88192@gmail.com> writes: >On 8/30/2019 4:42 PM, Ian Collins wrote: >> On 30/08/2019 20:43, Mel wrote: >>> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero >>> <Bonita.Montero@gmail.com> wrote: >>> >>>> The non-throw-case takes almost no or no performance. >>> >>> That's no true. You have to install handlers evrry time or prepare >>> tbla for each function at program start... >> >> Have you actually measured the difference? I have on several occasions >> and yes, the no-throw path with exceptions is faster (even if only >> slightly) than testing error returns. It is also foolproof.. >> > >I agree, in this case. > >A sane implementation of exceptions can use a lookup table for >PC/EIP/RIP/whatever, and so only involves significant time overhead when >actually throwing an exception. It's the unwinding support that adds overhead. Regardless of whether the exception is ever thrown in any particular codepath. I have a large application (a full-system simulator) written in C++. When simulating an instruction, if an exception is detected (illegal instruction, illegal operand, instruction timeout, etc), it will longjmp back to the main loop. Replacing the longjmp with 'throw' cost 30% in application performance, even given the infrequency of longjmp calls/throw (exceptions in production code are rare; mainly when the stack limit is reached and more stack needs to be allocated by the OS to the application). YMMV.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-09-06 22:03 -0500 |
| Message-ID | <qkv6lv$9j7$1@dont-email.me> |
| In reply to | #146068 |
On 9/6/2019 8:51 AM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 8/30/2019 4:42 PM, Ian Collins wrote:
>>> On 30/08/2019 20:43, Mel wrote:
>>>> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
>>>> <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>> The non-throw-case takes almost no or no performance.
>>>>
>>>> That's no true. You have to install handlers evrry time or prepare
>>>> tbla for each function at program start...
>>>
>>> Have you actually measured the difference? I have on several occasions
>>> and yes, the no-throw path with exceptions is faster (even if only
>>> slightly) than testing error returns. It is also foolproof..
>>>
>>
>> I agree, in this case.
>>
>> A sane implementation of exceptions can use a lookup table for
>> PC/EIP/RIP/whatever, and so only involves significant time overhead when
>> actually throwing an exception.
>
> It's the unwinding support that adds overhead. Regardless of whether
> the exception is ever thrown in any particular codepath.
>
> I have a large application (a full-system simulator) written in C++.
> When simulating an instruction, if an exception is detected (illegal
> instruction, illegal operand, instruction timeout, etc), it will
> longjmp back to the main loop.
> > Replacing the longjmp with 'throw' cost 30% in application performance,
> even given the infrequency of longjmp calls/throw (exceptions in production
> code are rare; mainly when the stack limit is reached and more stack needs
> to be allocated by the OS to the application).
>
OK.
In my emulators, I instead worked by taking a snapshot of the state at
the time of the fault (and disabling memory IO operations and similar at
this time), setting things up so that the inner trampoline loop would
terminate (transferring control back to an outer-loop which handles
hardware faults/exceptions), which would then restore the relevant state
(and restore IO) while transferring control to the interrupt handler.
In my case, the emulator was mostly operating via "continuation passing
style", and would typically set up the pointer to the "next instruction
trace" prior to executing the current trace, so if an exception occurs
it could set this pointer to NULL and thus cause the outer trampoline to
terminate.
More or less (note, written in C):
while(tr && (cpu->lim>0))
{ cpu->lim-=tr->n_cyc; tr=tr->Run(cpu, tr); }
In this case, no usage is made here for either exceptions or longjmp...
Some of my other stuff uses longjmp though.
The 'lim' stuff is mostly related to time-slicing and hardware
interrupts and similar (and can be in the CPU Context structure partly
to facilitate "penalties" such as accounting for cache misses and similar).
This part would be omitted if one doesn't need time-slicing, leaving a
trampoline loop more like:
while(tr)
{ tr=tr->Run(cpu, tr); }
Frequently, these trampoline loops can become significant in the
profiler, so need to be kept fast.
Typically, my emulators are mostly one-off, typically written for a
single ISA and a set of hardware devices (as opposed to trying to
support "everything under the sun").
With an emulator for my custom hobby ISA (*1), on my Ryzen 2700X (single
threaded), I can generally get ~ 200 MIPS (~ 300 MHz) with a plain C
interpreter in this style, and ~ 650 MIPs (~ 800MHz) with a quick/dirty
JIT (output is mostly in a "call-threaded" style, with the output
consisting mostly of function calls; still operating via the trampoline
loops).
In the past (with an emulator for SH4), had managed to break 1000 MIPs
with a similar design. Though, SH4 does less useful work per
instruction, owing to the limitations of fixed-length 16-bit instructions.
Though, this emulator is more written to try to model the expected
hardware behavior than for maximum performance.
The emulator is a bit slower running on ARM hardware (eg: on a Raspberry
Pi or on my phone), but still manages to be considerably faster than
DOSBox and similar (in that a Doom port to my ISA is playable; whereas
with DOSBox on a RasPi it is basically unplayable). This is still true
even when just using the interpreter.
*1: Takes inspiration from various ISAs, general summary:
Load/Store (RISC style; Base+Disp and Base+Index*Sc addressing);
Also supports PC-rel and GBR-rel as special cases.
Constrained variable length (16/32 or 16/32/48-bit encodings);
Predicated instructions (sorta like ARM, but T/F vs full CC's);
Explicitly parallel instructions (vaguely akin to IA64 or similar);
Bundles are encoded as variable-length chains of instructions;
Parallel ops and predicated instructions use similar encodings.
Supports specialized ops to help with constant loading;
Constants are composed inline, rather than using memory loads;
Is 64-bit with 32 registers in the main RF (27 GPRs + 5 SPRs)
Double precision FPU (uses GPRs)
Optional packed-integer SIMD support (also via GPRs)
...
It can execute multiple instructions per clock, but this depends on the
compiler (or explicitly via ASM code) to figure out how to do so
(similar to VLIW style ISA's, such as Itanium/IA64 or TMS320C6xxx or
similar). This avoids some of the relative hardware cost and complexity
of "going superscalar". However, its encoding also avoids the severe
code-density penalties typical of VLIW architectures while doing so
(overall code density remains competitive with scalar RISCs); code can
also remain binary compatible with a scalar-only implementation (if it
follows the rules).
So, for a lot of the "fast" ASM code, there is some amount of:
ADD R23, R19, R9 | AND R29, #511, R13 | MUL R30, R27, R21
Or similar, with '|' designating ops which are to be run in parallel
(though, the ISA does impose some limits as to what sorts of things are
allowed with this; if one goes outside the rules for a given profile,
the results are undefined).
Otherwise, my C compiler will attempt to shuffle the instructions around
to find cases where it can put instructions in parallel with each other.
Compiler:
Mostly outputs flat ROM images, and a tweaked PE/COFF variant;
Currently only really supports C.
There is a partially-implemented / mostly-untested C++ subset though.
Still working on having a usable Verilog/FPGA implementation.
CPU core mostly works in simulation, mostly working on the various
peripheral hardware and trying to fill in the unit-testing at this point.
Which features can be enabled will depend some on the FPGA (currently
mostly targeting medium-range Spartan-7 and Artix-7 devices).
>
> YMMV.
>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-09-07 10:57 -0500 |
| Message-ID | <ql0k0v$did$1@news.albasani.net> |
| In reply to | #146088 |
( Mostly trying to clarify some things )
On 9/6/2019 10:03 PM, BGB wrote:
> On 9/6/2019 8:51 AM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 8/30/2019 4:42 PM, Ian Collins wrote:
>>>> On 30/08/2019 20:43, Mel wrote:
>>>>> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
>>>>> <Bonita.Montero@gmail.com> wrote:
>>>>>
>>>>>> The non-throw-case takes almost no or no performance.
>>>>>
>>>>> That's no true. You have to install handlers evrry time or prepare
>>>>> tbla for each function at program start...
>>>>
>>>> Have you actually measured the difference? I have on several
>>>> occasions
>>>> and yes, the no-throw path with exceptions is faster (even if only
>>>> slightly) than testing error returns. It is also foolproof..
>>>>
>>>
>>> I agree, in this case.
>>>
>>> A sane implementation of exceptions can use a lookup table for
>>> PC/EIP/RIP/whatever, and so only involves significant time overhead when
>>> actually throwing an exception.
>>
>> It's the unwinding support that adds overhead. Regardless of whether
>> the exception is ever thrown in any particular codepath.
>>
>> I have a large application (a full-system simulator) written in C++.
>> When simulating an instruction, if an exception is detected (illegal
>> instruction, illegal operand, instruction timeout, etc), it will
>> longjmp back to the main loop.
>> > Replacing the longjmp with 'throw' cost 30% in application performance,
>> even given the infrequency of longjmp calls/throw (exceptions in
>> production
>> code are rare; mainly when the stack limit is reached and more stack
>> needs
>> to be allocated by the OS to the application).
>>
> OK.
>
> In my emulators, I instead worked by taking a snapshot of the state at
> the time of the fault (and disabling memory IO operations and similar at
> this time), setting things up so that the inner trampoline loop would
> terminate (transferring control back to an outer-loop which handles
> hardware faults/exceptions), which would then restore the relevant state
> (and restore IO) while transferring control to the interrupt handler.
>
> In my case, the emulator was mostly operating via "continuation passing
> style", and would typically set up the pointer to the "next instruction
> trace" prior to executing the current trace, so if an exception occurs
> it could set this pointer to NULL and thus cause the outer trampoline to
> terminate.
>
...
>
> This part would be omitted if one doesn't need time-slicing, leaving a
> trampoline loop more like:
> while(tr)
> { tr=tr->Run(cpu, tr); }
>
Missing some relevant details here.
Trace Run was typically:
Set up some initial trace state ("cpu->tr_next" pointer, ...);
Execute an unrolled loop of indirect function calls;
Each unrolled loop-length, ..., has its own Run functions;
Return the "cpu->tr_next" pointer.
This may have been NULL'ed if an exception was thrown.
As-needed, the trace function may fetch traces for connected
control-flow patch, which will go through a big hash table (if the trace
has already been decoded for a given PC address) and may trigger the
emulator's instruction-decoding logic as-needed (which decodes a
non-branching trace of up to 32 instructions). Ideally, one wants to
avoid going through decoding if possible, as doing so is fairly expensive.
Following the fetch, the Run function may replace itself with a version
which does not fetch the traces (using the 'tr'/'Trace' structure to
cache the relevant pointers, setting the next pointers from the cached
values). Note that conditional direct-branch instructions are handled by
conditionally copying the value from one pointer to another and setting
a different value for the CPU Context's PC register.
If the emulated program triggers an I-cache flush, it may be necessary
to teardown the entire trace-graph (and flush any JIT related state,
..., if applicable). In my tests, full teardown was generally the faster
option.
Typically, also memory IO was via wrapper functions, which then call
through function pointers held in the CPU Context structure. These
pointers may be changed depending on state (such as whether or not the
MMU has been enabled, whether the address space is 32 or 48 bits,
whether or not an exception is in the process of being raised, ...).
The memory address space is fully emulated in my case, generally:
(If JIT/Fast case) Checks address against a cached set of 2 pages;
If found, do IO these and return.
(If MMU) Translate address via TLB;
May trigger TLB miss exception (ISA uses semi-exposed TLB)
(If Slow case) Model L1 and L2 cache misses
Accumulates counts of cache hits/misses, adds "penalty cycles", ...
Lookup the "memory span" associated with this address
Searches an spans array via a binary search.
If is is a "basic memory" span:
Add to 2-page cache, perform IO.
Else:
Call span's appropriate Get/Set handlers.
(Each span is set up with pointers for its matching HW device).
I guess some other emulators go and use OS-level memory-mapping tricks
to try to implement the address space, but I didn't want to deal with
this sort of hassle (similar reasons for it being single-threaded).
It is generally fast enough for what I need it for, so is acceptable.
All this is considerably different from how it would work in Verilog,
but I wanted it fast enough to be able to keep up with real-time. A lot
of the peripheral hardware is written using a lot more if/else branches
and "switch()" and similar though.
Similar, what makes for good results in Verilog results in particularly
bad performance if done in C (and vice versa). Though, some parts of the
emulator have been reused in some of the unit tests for Verilog modules.
Not really sure how common or uncommon of a design any of this is.
Note that underlying design can be applied to emulating other ISA
designs, eg, x86 or ARM, but in both cases, their use of condition codes
makes achieving decent emulator performance more difficult (CC's are
more difficult to check/update efficiently, vs a SuperH style True/False
flag or an explicit boolean register).
> Frequently, these trampoline loops can become significant in the
> profiler, so need to be kept fast.
>
...
>
> With an emulator for my custom hobby ISA (*1), on my Ryzen 2700X (single
> threaded), I can generally get ~ 200 MIPS (~ 300 MHz) with a plain C
> interpreter in this style, and ~ 650 MIPs (~ 800MHz) with a quick/dirty
> JIT (output is mostly in a "call-threaded" style, with the output
> consisting mostly of function calls; still operating via the trampoline
> loops).
>
...
On x86, much of the speedup from the JIT seems to be eliminating all the
indirect calls in favor of direct function calls.
So, an unrolled loop something like:
(*ops)->Run(cpu, *ops); ops++;
(*ops)->Run(cpu, *ops); ops++;
(*ops)->Run(cpu, *ops); ops++;
...
Becomes effectively something like, eg:
JX2VM_OpXOR_RIR(cpu, op1);
JX2VM_OpADD_RRR(cpu, op2);
...
(just in machine code).
Though, various common operations are translated directly, however much
of the overall speedup seems to be due to this transformation.
JIT is only really enabled at higher clock-speed targets for now, as it
interferes with some of the modeling and analysis features. If I am
telling it to operate at 50 or 100 MHz, chances are I care about
analysis, and if I tell it to go at 500MHz, it assumes I probably don't
care as much (and the plain interpreter can't keep up with real-time
emulation at 500MHz).
On PC's though, even just the interpreter is faster than what I can
expect from the hardware on an FPGA (short of getting a faster and much
more expensive FPGA, like a Kintex or Virtex), so it is already
basically fast enough for what I am doing.
I have noted, however, that this does not seem to apply to ARM; I saw
very little gain from call-threaded code over the plain interpreter (and
no JIT yet exists for Aarch64).
I had planned to move parts of the ARM JIT from using GPRs over to NEON
(NEON is a closer fit to my ISA than ARM's base integer ISA, but needs a
Pi3 or newer), however had not done so yet.
On a RasPi, the emulator isn't currently fast enough (even with JIT) to
give acceptable framerates if running Quake, which is kinda lame...
Though, it isn't exactly like the FPGA version would do much better here
(currently limited to ~ 50MHz).
Quake could probably be made faster, but it would likely involve
rewriting big chunks of the renderer in ASM or similar (like Quake did
originally on x86; rather than using the C version of the renderer).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-07 18:17 +0200 |
| Message-ID | <ql0l65$bdh$1@news.albasani.net> |
| In reply to | #146068 |
> It's the unwinding support that adds overhead. Regardless of
> whether the exception is ever thrown in any particular codepath.
Deallocation of the resources happens anyway, regardles if you program
in C or C++. So if you have the same kind of structures that hold the
resources and the deallocation is inlined or not in both cases, the
performance of resource-dellocation is actually the same. But the way
in C++ is more convenient when you consider something like the return
-code-evaluation- and goto-orgies in the Linux-kernel.
But throwing an exception itself has a high overhead independently of
calling any destructors. I wrote some little test-code tha measues the
overhead of cathing the same exception as thrown and thowing an excep-
tion two inheritance-levels deeper as catched:
#include <iostream>
#include <chrono>
#include <exception>
using namespace std;
using namespace std::chrono;
struct ExcBase : public exception
{
};
struct ExcDerivedA : public ExcBase
{
};
struct ExcDerivedB : public ExcDerivedA
{
};
typedef long long LL;
void BaseThrower();
void DerivedBThrower();
LL Benchmark( void (*thrower)(), unsigned const rep );
int main()
{
unsigned const REP = 1'000'000;
LL ns;
ns = Benchmark( BaseThrower, REP );
cout << "BaseThrower: " << (double)ns / REP << "ns" << endl;
ns = Benchmark( DerivedBThrower, REP );
cout << "DerivedBThrower: " << (double)ns / REP << "ns" << endl;
}
LL Benchmark( void (*thrower)(), unsigned const rep )
{
time_point<high_resolution_clock> start = high_resolution_clock::now();
for( unsigned i = rep; i; --i )
try
{
thrower();
}
catch( ExcBase & )
{
}
return (LL)duration_cast<nanoseconds>( high_resolution_clock::now()
- start ).count();
}
void BaseThrower()
{
throw ExcBase();
}
void DerivedBThrower()
{
throw ExcDerivedB();
}
I assume that this code ramps up the clock of my 3,6GHz Ryzen 7 1800X
to its boost of 4GHz as there's no load on the other cores. And it turns
out that throwing and catching the same exception is about 9300 clock
-cycles and catching the derived exception is ahout 10.600 clock-cycles.
So there might be many cases where calling the destructors when throwing
an exception isn't the part that consumes most of the time, f.e. when
you only deallocate memory to a memory-pool, which is usually very fast.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-07 18:48 +0200 |
| Message-ID | <ql0n17$8d9$1@news.albasani.net> |
| In reply to | #146090 |
> I assume that this code ramps up the clock of my 3,6GHz Ryzen 7 1800X > to its boost of 4GHz as there's no load on the other cores. And it turns > out that throwing and catching the same exception is about 9300 clock > -cycles and catching the derived exception is ahout 10.600 clock-cycles. > So there might be many cases where calling the destructors when throwing > an exception isn't the part that consumes most of the time, f.e. when > you only deallocate memory to a memory-pool, which is usually very fast. And I'm astonished that when I compile this code in 32 bit with VC++ 2019 the overhead of catching and throwing an exception is roughly twice as high. In 32-bit-mode the stack-frames are concatenated thorugh a linked list where the top is stored in a thread-local storage at FS:0.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-09-07 18:09 +0100 |
| Message-ID | <FvRcF.114537$jJ4.82695@fx05.am4> |
| In reply to | #146062 |
On 06/09/2019 12:24, BGB wrote:
> On 8/30/2019 4:42 PM, Ian Collins wrote:
>> On 30/08/2019 20:43, Mel wrote:
>>> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
>>> <Bonita.Montero@gmail.com> wrote:
>>>
>>>> The non-throw-case takes almost no or no performance.
>>>
>>> That's no true. You have to install handlers evrry time or prepare
>>> tbla for each function at program start...
>>
>> Have you actually measured the difference? I have on several
>> occasions and yes, the no-throw path with exceptions is faster (even
>> if only slightly) than testing error returns. It is also foolproof..
>>
>
> I agree, in this case.
>
> A sane implementation of exceptions can use a lookup table for
> PC/EIP/RIP/whatever, and so only involves significant time overhead when
> actually throwing an exception.
I've never used exceptions (apart from once, see below**). But I
understood that in a call-chain like this (so F calls G etc)
F -> G -> H -> I
If code inside I throws/raises an exception, then it somehow has to
works its way up the call stack, releasing any resources attached to
local variables, until it finds the place where that exception is caught
(ie. checked for in the code).
If that happens to be in F, then all the active locals of the
intervening G and H functions need to be processed (I guess, call their
destructors in C++). Block-scopes within G and H would make that harder.
But how does it do that? Does it need extra information pushed at every
call to make it possible? If so, then that would be extra overhead that
will affect even this call-chain:
A -> G -> H -> B
where exceptions aren't used at all.
(** I've used exceptions once, in a language where I myself implemented
an experimental version. But that was dynamic byte-code with a tagged
stack structure, so unwinding was trivial. And also much slower than you
would expected in C++)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-09-07 15:32 -0500 |
| Message-ID | <ql144q$clf$1@dont-email.me> |
| In reply to | #146092 |
On 9/7/2019 12:09 PM, Bart wrote:
> On 06/09/2019 12:24, BGB wrote:
>> On 8/30/2019 4:42 PM, Ian Collins wrote:
>>> On 30/08/2019 20:43, Mel wrote:
>>>> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
>>>> <Bonita.Montero@gmail.com> wrote:
>>>>
>>>>> The non-throw-case takes almost no or no performance.
>>>>
>>>> That's no true. You have to install handlers evrry time or prepare
>>>> tbla for each function at program start...
>>>
>>> Have you actually measured the difference? I have on several
>>> occasions and yes, the no-throw path with exceptions is faster (even
>>> if only slightly) than testing error returns. It is also foolproof..
>>>
>>
>> I agree, in this case.
>>
>> A sane implementation of exceptions can use a lookup table for
>> PC/EIP/RIP/whatever, and so only involves significant time overhead
>> when actually throwing an exception.
>
> I've never used exceptions (apart from once, see below**). But I
> understood that in a call-chain like this (so F calls G etc)
>
> F -> G -> H -> I
>
> If code inside I throws/raises an exception, then it somehow has to
> works its way up the call stack, releasing any resources attached to
> local variables, until it finds the place where that exception is caught
> (ie. checked for in the code).
>
> If that happens to be in F, then all the active locals of the
> intervening G and H functions need to be processed (I guess, call their
> destructors in C++). Block-scopes within G and H would make that harder.
>
> But how does it do that? Does it need extra information pushed at every
> call to make it possible? If so, then that would be extra overhead that
> will affect even this call-chain:
>
> A -> G -> H -> B
>
> where exceptions aren't used at all.
>
No extra info is needed on the stack or at runtime, as it is generally
provided indirectly via the program binary (such as via the PE/COFF
headers or similar).
It mostly uses a big lookup table, so an exception will occur at one
address, and the dispatcher looks up this address in the table.
This could contain either:
A pointer to the function function's prolog or epilog
It will parse these to restore the caller's frame
The allowed instruction sequences are defined in the ABI.
The process repeats, this time using the callers' address
A pointer to some handler or unwind logic
Control is passed to this logic, which does its thing.
If it catches the exception, we are done here.
If it is unwind logic, or doesn't catch the exception
Control returns back to the dispatcher.
We restore the caller's frame and continue as above.
Nothing is found:
Typically the process terminates or similar.
At this point, unwinding further is effectively impossible.
The table format is target specific, but generally encodes (in some form):
The starting address (as an RVA);
(MIPS, etc)
RVA of ending address, exception handler, handler info, etc.
(x86-64 or IA64)
Pointer to an UNWIND_INFO structure (process is more involved).
(ARM/SH/Thumb/etc) second DWORD holds several bit-twiddled fields
Whether or not an exception-handler exists is given as a flag.
The entry point for the handler will directly follow the epilog.
Otherwise, the prolog sequence is be parsed to unwind the function.
In my ISA (BJX2), it is encoded similarly to SH and Thumb and similar,
but with a little more flexibility regarding the prolog and epilog.
For example, the compiler uses a space-saving feature where the common
parts of the prolog and epilog sequences are "folded off" and reused
across multiple functions; the entry point for a function may simply
preserve the Link Register and then direct-call into the reused prolog
sequence. In this case, the unwind logic would need to follow the branch
to find the "real" prolog sequence (which is terminated by a function
return).
AFAIK, on ELF based systems, a specialized subset of the DWARF format is
used for unwinding from exceptions, rather than the Win64 approach of
parsing fixed-format epilog sequences.
>
> (** I've used exceptions once, in a language where I myself implemented
> an experimental version. But that was dynamic byte-code with a tagged
> stack structure, so unwinding was trivial. And also much slower than you
> would expected in C++)
OK.
I sort of have a lot of this stuff in place in my compiler and ABI spec,
but the relevant exception-handling machinery in the runtime hasn't been
implemented yet IIRC (not gotten around to it).
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2019-09-03 18:39 +0000 |
| Message-ID | <qkmc08$nr7$1@news.xmission.com> |
| In reply to | #145830 |
[Please do not mail me a copy of your followup]
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
<qk6qmj$83p$1@dont-email.me> thusly:
>"Rust is the future of systems programming, C is the new Assembly:
>Intel principal engineer, Josh Triplett"
>
>https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
From the article:
>> One of the reasons why Mozilla got interested is that Firefox was
>> written in more than 4 million lines of C++ code and had quite a bit
>> of highly critical vulnerabilities.
Does anyone here have any familiarity with the Mozilla source code? I
know it's open source, but I've never looked at it. I'm mostly
interested in things like:
- How do they handle errors? Is it C-style error codes or do they use
exceptions?
- Do they introduce small abstractions or only "big" abstractions
(e.g. god class code smell)
- Are they leveraging the type system for abstractions, or are they
doing things C-style with void*?
- Is the code full of "naked new/delete"? or are they using resource
encapsulation
My experience has been that lots of C++ code is written in a C style
and therefore very little of the benefits of C++ are realized in
practice.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 20:46 +0200 |
| Message-ID | <qkmcej$s3v$1@news.albasani.net> |
| In reply to | #145943 |
> Does anyone here have any familiarity with the Mozilla source code? > I know it's open source, but I've never looked at it. I'm mostly > interested in things like: > - How do they handle errors? Is it C-style error codes or do they use > exceptions? > - Do they introduce small abstractions or only "big" abstractions > (e.g. god class code smell) > - Are they leveraging the type system for abstractions, or are they > doing things C-style with void*? > - Is the code full of "naked new/delete"? or are they using resource > encapsulation > My experience has been that lots of C++ code is written in a C style > and therefore very little of the benefits of C++ are realized in > practice. The Firefox HTML-renderer Servo is writen in Rust. Rust is a smart language, but unfortunately it lacks exception.s Error-handling is done through returning a combined structure with error- and return-codes. So error-handling is almost as complex as in C.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-09-04 01:07 +0100 |
| Message-ID | <20190904010716.dce00dacfa7dfef90aa96f35@cvine--nospam--.freeserve.co.uk> |
| In reply to | #145944 |
On Tue, 3 Sep 2019 20:46:44 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > > Does anyone here have any familiarity with the Mozilla source code? > > I know it's open source, but I've never looked at it. I'm mostly > > interested in things like: > > - How do they handle errors? Is it C-style error codes or do they use > > exceptions? > > - Do they introduce small abstractions or only "big" abstractions > > (e.g. god class code smell) > > - Are they leveraging the type system for abstractions, or are they > > doing things C-style with void*? > > - Is the code full of "naked new/delete"? or are they using resource > > encapsulation > > My experience has been that lots of C++ code is written in a C style > > and therefore very little of the benefits of C++ are realized in > > practice. > > The Firefox HTML-renderer Servo is writen in Rust. > Rust is a smart language, but unfortunately it lacks exception.s > Error-handling is done through returning a combined structure with > error- and return-codes. So error-handling is almost as complex as > in C. As far as I can tell, in rust you can match on the returned Result type, and you can nest your matches to short-circuit in case of error in the same way that exceptions do. The match on the Result type is a somewhat more cumbersome version of a bind (Result and Option types are in fact monads, although not referred to as such). Using a Result type instead of exceptions seems to be a price that the rust developers thought worthwhile in order to enforce correct error handling through the type system: something that C of course does not do. It does come with some complexity cost.
[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.lang.c
csiph-web