Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67978 > 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 165 — 31 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" 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" Ian Collins <ian-news@hotmail.com> - 2019-08-29 23:35 +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 20:00 +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" Öö Tiib <ootiib@hot.ee> - 2019-08-29 06:08 -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:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:00 -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 10:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:26 -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 10:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 06:30 -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 15:59 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 07:42 -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 14:44 +0000
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" Daniel <danielaparker@gmail.com> - 2019-09-05 13:28 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-06 02:36 -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: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" Manfred <noname@invalid.add> - 2019-08-31 18: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-08-31 18:21 +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" Öö Tiib <ootiib@hot.ee> - 2019-09-01 03:21 -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-01 12:25 +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 12:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 04:13 -0700
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-01 23:18 +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-09-01 14:04 +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-02 07:20 +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" 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" 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: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 11:07 -0700
Re: 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-05 19:23 +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-09-06 08:25 +0200
Re: 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-18 16:55 +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" Ian Collins <ian-news@hotmail.com> - 2019-09-06 17:16 +1200
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" Daniel <danielaparker@gmail.com> - 2019-09-03 12:16 -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:35 +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-03 22:49 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-04 00:20 -0700
Re: Comments on third parties Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-07 06:59 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 17:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 09:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 20:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 14:40 -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-06 10:05 +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:33 +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 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" 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" 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" 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" 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" 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
Error handling strategies (was: Rust is the future of systems programming C is the new Assembly) legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20: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-09-08 20:29 +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" Ian Collins <ian-news@hotmail.com> - 2019-09-08 12:40 +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-09 08:59 +0200
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-09 16:35 +0000
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" Öö Tiib <ootiib@hot.ee> - 2019-08-31 04:50 -0700
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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2019-09-03 20:14 +0000 |
| Subject | Error handling strategies (was: Rust is the future of systems programming C is the new Assembly) |
| Message-ID | <qkmhiu$sp4$3@news.xmission.com> |
| In reply to | #68050 |
[Please do not mail me a copy of your followup]
Anton Shepelev <anton.txt@gmail.com> spake the secret code
<20190831030515.3e92d06f46e1fe46e5d4e7a8@gmail.com> thusly:
>[...] Code with exceptions is not
>transparent, because it hides the error-handling part of the
>algorithm, and incomplete information is akin to a lie.
Code with subroutines is not transparent, because it hides the details
of the algorithm and incomplete information is akin to a lie.
You are essentially arguing for code that is 100% details with 0%
abstraction.
Return codes and exceptions are two different strategies for handling
errors. Handling errors is bug-prone because most people don't do
sufficient unit testing to force their code down all the error
handling paths to validate the error handling. This is true whether
you use exceptions or return code style error handling. However, I've
seen far more bugs in code that uses return code style error handling
than I've seen in code that uses exceptions.
--
"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-08 20:29 +0200 |
| Message-ID | <ql3hap$r8f$1@news.albasani.net> |
| In reply to | #68046 |
> 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 | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 15:42 +0200 |
| Message-ID | <almarsoft.8871656568901274022@news.albasani.net> |
| In reply to | #68035 |
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 | #68032 |
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 | #68026 |
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 | #68048 |
> 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 | #68048 |
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 | #68257 |
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 | #68259 |
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 | #68262 |
( 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 | #68259 |
> 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 | #68269 |
> 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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-09-08 12:40 +1200 |
| Message-ID | <gtj0vtFnafoU6@mid.individual.net> |
| In reply to | #68259 |
On 07/09/2019 01:51, 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. Surely the unwinding has to happen on function return whether you are using exceptions or not? > 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. Doing so will bypass any object destructors, so you would have been restricted to the C with classes subset. Which implies there would have been nothing to unwind had you used exceptions. Using longjmp with anything beyond the C with classes subset is a bad idea in C++. > 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). How long ago was this by the way? We had to disable exceptions in an embedded project in the early 2000s due to performance issues that aren't there in modern compilers. Exception performance has improved significantly in recent years. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-09 08:59 +0200 |
| Message-ID | <ql4t8o$60r$1@dont-email.me> |
| In reply to | #68278 |
On 08/09/2019 02:40, Ian Collins wrote: > On 07/09/2019 01:51, 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. > > Surely the unwinding has to happen on function return whether you are > using exceptions or not? > Without exceptions, code will need to call destructors as objects die. But the compiler knows when this will happen, and can re-order them, simplify them, combine them, or otherwise optimise them in the normal code path. When you have (table-driven) exceptions, you need tables to handle unwinding from any possible exception point, from any function along the way, including handling of partially created or partially destructed objects. That causes a big overhead in code tables, which is relevant for some systems. And it might also limit the compiler's ability to optimise normal flow constructors and destructors, and perhaps other code.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-09-09 16:35 +0000 |
| Message-ID | <6bvdF.375955$cG6.88787@fx34.iad> |
| In reply to | #68278 |
Ian Collins <ian-news@hotmail.com> writes: > >On 07/09/2019 01:51, Scott Lurndal wrote: >> BGB <cr88192@gmail.com> writes: >>> On 8/30/2019 4:42 PM, Ian Collins wrote: >>> 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. > >Surely the unwinding has to happen on function return whether you are >using exceptions or not? Not necessarily. Look at the difference in generated code between normally compiled C++ and C++ compiled with -fno-exceptions. > >> 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. > >Doing so will bypass any object destructors, so you would have been >restricted to the C with classes subset. Which is perfectly acceptable for high-performance code. Avoid dynamic allocation at run-time. > Which implies there would have >been nothing to unwind had you used exceptions. Using longjmp with >anything beyond the C with classes subset is a bad idea in C++. > >> 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). > >How long ago was this by the way? The original code was started using Cfront 2.1 circa 1990. The current version was developed further between 2008 and 2010 from the original codebase. >We had to disable exceptions in an >embedded project in the early 2000s due to performance issues that >aren't there in modern compilers. Exception performance has improved >significantly in recent years. The simluator codebase doesn't use dynamic allocation in threads which simulate the target processor core(s), so longjmp() works well and is highly reliable (the simulator, which boots the target operating system, runs with better performance than the final generation hardware (last gen was developed around 1990 using 10k ECL chips and sold for 2.8 Million)). It's run the target MCP (operating system) with a COBOL based workload in simulation for years with no failures (and no memory allocation issues, since all dynamic memory is allocated at application startup). The current ARMv8 SOC simulator I work on also avoids dynamic allocation in the threads which simulate the 64-bit ARM cores[*]. This doesn't, of course, run as fast as the target hardware, but it still boots SMP linux to the busybox prompt in less than 55 seconds. [*] Being a more modern codebase, albeit partially derived from the original, it does use C++ exceptions to handle detected exceptions when simulating instructions (e.g. AArch64 Data Aborts, Instruction Aborts, IRQs, FIQs, et alia).
[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 | #68257 |
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 | #68271 |
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 | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-08-31 04:50 -0700 |
| Message-ID | <3f973679-5c24-46d2-87f5-4e8715f7ac48@googlegroups.com> |
| In reply to | #68012 |
On Friday, 30 August 2019 09:13:33 UTC+3, Mel wrote: > On Thu, 29 Aug 2019 14:53:05 +0200, Bonita Montero > <Bonita.Montero@gmail.com> wrote: > > Rust is nice, but Rust has no exceptions. I wouldn't like to > evaluate > > this combined error- and return-values after each function-call that > > might fail. > > That's Rust advantage. Returnig discriminated union is right way for > handling errors. Rust has syntactic sugar in that. Latest proposal > for c++ exceptions leans toeard that solution. Perhaps different people think of error handling differently. I learned programming using BASIC interpreter in eighties and there was ERROR statement for generating errors and ON ERROR GOTO statement for trapping those to handler. Logic was to keep the already messy algorithms expressed in BASIC cleaner by handling errors in separate place. C and C++ with no error handling in language and most errors just left to be undefined behavior felt seriously inferior because of that. When Microsoft added SEH exceptions to both C and C++ in nineties then it felt good extension.
[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 | #67978 |
[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 | #68173 |
> 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]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web