Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92512 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2016-08-19 14:22 -0700 |
| Last post | 2016-08-22 05:11 -0700 |
| Articles | 20 on this page of 355 — 30 participants |
Back to article view | Back to comp.lang.c
Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:22 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 09:36 +1200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:48 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 14:56 -0700
Re: Default values in #define Chad <cdalten@gmail.com> - 2016-08-22 07:56 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 17:09 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:47 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 08:55 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 09:27 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 09:41 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 20:19 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 12:54 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:14 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:23 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 05:42 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:52 -0700
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-23 06:01 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:06 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:56 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:59 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-23 10:42 -0700
Re: Default values in #define matt@godbolt.org - 2016-08-23 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:57 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 15:31 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:06 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:15 -0700
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 13:26 +0100
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:07 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-06 06:22 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 00:50 -0600
Re: Default values in #define supercat@casperkitty.com - 2016-12-07 06:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-07 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 01:44 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-08 06:58 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:16 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:47 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:49 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 15:52 -0800
Re: Default values in #define asetofsymbols@gmail.com - 2016-12-09 00:52 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:19 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-07 04:43 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 14:18 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-08 07:22 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 08:00 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-08 22:14 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-12-08 13:44 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:07 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 17:00 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 17:46 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 08:37 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-10 09:42 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-10 10:05 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 02:51 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 04:40 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:06 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 03:15 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-12 16:12 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:33 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 01:45 -0600
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 16:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 10:25 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 10:50 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 04:02 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 13:14 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:57 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 14:32 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 05:58 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:21 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-13 14:41 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 06:47 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 16:24 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 07:30 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:12 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 12:21 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 15:02 -0600
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 13:19 -0800
Petty and unprofessional (Was: Default values in #define) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-13 16:46 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 09:04 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-13 20:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:19 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-13 11:33 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 11:44 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-14 10:04 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:37 -0800
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:28 -0600
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:23 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:10 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:54 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 18:57 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 02:53 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-14 05:59 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:03 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 12:22 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 17:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-14 18:37 -0800
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:25 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 07:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-12 07:35 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 09:17 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 11:03 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 11:41 -0800
Re: Default values in #define supercat@casperkitty.com - 2016-12-12 12:31 -0800
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-12-12 13:13 -0800
Re: Default values in #define BartC <bc@freeuk.com> - 2016-12-12 20:22 +0000
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:49 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-11 07:10 -0800
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:21 -0800
Re: Default values in #define jameskuyper@verizon.net - 2016-12-11 10:33 -0800
Re: Default values in #define Melzzzzz <mel@zzzzz.com> - 2016-12-11 16:22 +0100
Re: Default values in #define luser droog <luser.droog@gmail.com> - 2016-12-11 07:16 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 13:54 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 14:09 -0800
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-13 14:31 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-13 16:11 -0800
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:49 -0700
Re: Default values in #define Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-21 05:50 -0600
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-12-21 13:10 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-22 12:56 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-22 21:11 +0100
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-22 15:47 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 11:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 20:07 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-23 14:30 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-24 06:25 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 10:34 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-24 08:50 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-24 15:37 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 11:58 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 01:27 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-24 22:28 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-24 23:38 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:44 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 07:29 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 07:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:26 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-25 11:11 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 12:03 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:31 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 09:28 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 22:51 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-29 16:35 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 01:44 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 10:06 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:41 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:24 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:32 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-30 22:30 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 09:17 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:46 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 10:29 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:12 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-08-31 12:30 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 11:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:56 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 08:17 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:18 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-31 22:34 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 00:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:19 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 11:38 +0200
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 10:03 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 10:31 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-01 12:50 -0700
Re: Default values in #define Jean-Marc Bourguet <jm@bourguet.org> - 2016-09-01 21:30 +0200
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-02 05:37 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 08:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 22:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-06 07:32 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:54 -0700
Re: Default values in #define Keith Thompson <kst-u@mib.org> - 2016-09-02 08:40 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-02 10:16 -0700
Re: Default values in #define Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 15:16 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-25 08:28 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 00:54 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 01:00 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 11:17 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 04:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 13:45 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:09 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:11 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:31 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:48 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:50 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:01 +0200
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 10:57 -0700
Re: Default values in #define Ike Naar <ike@iceland.freeshell.org> - 2016-08-31 06:09 +0000
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 12:24 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 17:39 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:49 +0100
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:51 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:46 +0200
Re: Default values in #define Richard Damon <Richard@Damon-Family.org> - 2016-08-26 17:37 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 15:05 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 10:25 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 16:25 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 18:12 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 13:47 +1200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 19:32 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:54 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:11 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-27 18:25 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:11 -0400
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 06:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:16 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:17 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:26 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 13:10 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 16:35 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:28 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 15:38 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 13:27 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 16:42 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:16 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-29 17:24 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:21 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 08:12 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 15:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:53 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 10:34 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 14:44 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 12:48 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:19 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 11:24 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:33 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:51 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:46 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 16:26 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-09-03 17:31 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:03 -0800
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 21:36 +0200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 17:30 -0400
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:39 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 03:57 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 15:34 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 07:33 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 10:46 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 10:03 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 22:52 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-09-01 07:41 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 14:58 -0400
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:27 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 08:21 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:05 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-31 09:15 -0700
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-09-02 22:22 +0200
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-28 08:41 +1200
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:34 -0400
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 09:41 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 08:07 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:08 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 15:41 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:30 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:14 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 17:20 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 23:37 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:19 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:26 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 04:40 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:56 +0200
Re: Default values in #define albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-04 15:43 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 19:34 +1200
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 00:51 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-30 20:36 +1200
Re: Default values in #define Robert Wessel <robertwessel2@yahoo.com> - 2016-08-31 00:39 -0500
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-26 21:40 -0700
Re: Default values in #define Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 09:22 -0400
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-29 11:36 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-09 16:26 -0800
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-27 06:34 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-27 12:48 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:12 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:10 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:18 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 10:32 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:49 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:13 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 14:48 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 09:14 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-26 08:59 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:43 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-29 22:58 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-30 07:14 +0100
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-30 00:14 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 00:26 -0700
Re: Default values in #define already5chosen@yahoo.com - 2016-08-30 02:10 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 10:47 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 03:32 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:38 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:44 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 14:00 +0200
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 18:55 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 12:24 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 14:11 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 16:28 -0700
Re: Default values in #define me <crisdunbar@gmail.com> - 2016-08-30 16:54 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-31 06:27 +0100
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 23:09 +0100
Re: Default values in #define supercat@casperkitty.com - 2016-08-30 16:06 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:35 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-30 13:30 +0200
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-30 04:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:40 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 15:17 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 06:47 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:58 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-29 09:09 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:16 +0200
Re: Default values in #define already5chosen@yahoo.com - 2016-08-31 02:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-31 12:49 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-31 09:02 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-25 10:31 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:01 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:24 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 10:43 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 23:29 +0200
Re: Default values in #define supercat@casperkitty.com - 2016-08-29 16:27 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 10:02 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 10:33 -0700
Re: Default values in #define "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-25 14:12 -0700
Re: Default values in #define supercat@casperkitty.com - 2016-08-25 14:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-29 16:27 +0200
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-22 23:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 14:39 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 09:32 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 05:33 -0700
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-23 06:13 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 06:22 -0700
Re: Default values in #define David Brown <david.brown@hesbynett.no> - 2016-08-23 16:13 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-23 07:35 -0700
Re: Default values in #define Gareth Owen <gwowen@gmail.com> - 2016-08-23 19:08 +0100
Re: Default values in #define Rosario19 <Ros@invalid.invalid> - 2016-08-24 09:05 +0200
Re: Default values in #define mark.bluemel@gmail.com - 2016-08-24 00:49 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-24 05:40 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-19 22:56 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 10:14 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 18:09 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 13:15 +1200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-19 19:10 -0700
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-20 14:50 +1200
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 10:35 +0100
Re: Default values in #define Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-20 03:13 -0700
Re: Default values in #define BartC <bc@freeuk.com> - 2016-08-20 12:24 +0100
Re: Default values in #define Ian Collins <ian-news@hotmail.com> - 2016-08-21 00:14 +1200
Re: Default values in #define gazelle@shell.xmission.com (Kenny McCormack) - 2016-08-20 14:13 +0000
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:17 -0700
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:08 -0700
Re: Default values in #define Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:06 +0100
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-20 12:14 -0700
Re: Default values in #define Philipp Klaus Krause <pkk@spth.de> - 2016-08-21 12:51 +0200
Re: Default values in #define "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-22 05:11 -0700
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-12 07:35 -0800 |
| Message-ID | <ee26fe5c-d55e-43a3-9f1b-7417817bdb16@googlegroups.com> |
| In reply to | #99067 |
On Monday, December 12, 2016 at 10:31:38 AM UTC-5, supe...@casperkitty.com wrote: > On Monday, December 12, 2016 at 5:15:35 AM UTC-6, Rick C. Hodgin wrote: > > What's the purpose of the % everywhere? It looks like AT&T syntax > > was designed explicitly to make it easier for assemblers to parse the > > source code, rather than to support the needs of human developers. > > Given that meany features which are useful for humans offer no benefit to > code generators and vice versa, I would think that it would be helpful for > development systems to define distinct forms of assembly language for the > different purposes. Humans may benefit from having mnemonics for the > various opcodes, but code generators could just as easily output numeric > codes [e.g. "4,9,foo,3" meaning "Using format #4, generate code where the > opcode is 9, the first operand is "foo", and the second operand is 3"]; > since an assembler which works off the numeric format could be smaller, > leaner, and faster than one which needs to know all the different opcodes > and their associated mnemonics, a development system that used such an > assembler could produce machine code more quickly than one which has to > go through a more human-readable form. In cases where a human might need > to read the code, a translation utility could output a human-readable > representation. I agree completely, and I think that's a brilliant suggestion, Supercat. It would also be worth encoding within the tool a translation mechanism to take it from computer-readable code into human-readable code, and vice-versa, for those purposes. Brilliant. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-12 09:17 -0800 |
| Message-ID | <lntwa9qd7t.fsf@kst-u.example.com> |
| In reply to | #99067 |
supercat@casperkitty.com writes:
> On Monday, December 12, 2016 at 5:15:35 AM UTC-6, Rick C. Hodgin wrote:
>> What's the purpose of the % everywhere? It looks like AT&T syntax
>> was designed explicitly to make it easier for assemblers to parse the
>> source code, rather than to support the needs of human developers.
>
> Given that meany features which are useful for humans offer no benefit to
> code generators and vice versa, I would think that it would be helpful for
> development systems to define distinct forms of assembly language for the
> different purposes.
I don't.
> Humans may benefit from having mnemonics for the
> various opcodes, but code generators could just as easily output numeric
> codes [e.g. "4,9,foo,3" meaning "Using format #4, generate code where the
> opcode is 9, the first operand is "foo", and the second operand is 3"];
> since an assembler which works off the numeric format could be smaller,
> leaner, and faster than one which needs to know all the different opcodes
> and their associated mnemonics, a development system that used such an
> assembler could produce machine code more quickly than one which has to
> go through a more human-readable form. In cases where a human might need
> to read the code, a translation utility could output a human-readable
> representation.
I don't think the size and speed of the assembler is particularly
relevant to the speed of compilation. Implementing and maintaining a
second assembly syntax, text-based but not meant to be human-readable,
would, in my opinion, be a waste of time and effort. And bugs where the
human-readable assembly language is inconsistent with the "4,9,foo,3"
syntax would be inevitable and difficult to track down. Assemblers are
perfectly capable of parsing human-readable assembly language.
If you want to save the time spent in the assembler, just have the
compiler backend generate binary machine code.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-12 11:03 -0800 |
| Message-ID | <0a48f040-bc78-489d-a475-d2a578e2cdbc@googlegroups.com> |
| In reply to | #99086 |
On Monday, December 12, 2016 at 11:17:01 AM UTC-6, Keith Thompson wrote: > I don't think the size and speed of the assembler is particularly > relevant to the speed of compilation. Implementing and maintaining a > second assembly syntax, text-based but not meant to be human-readable, > would, in my opinion, be a waste of time and effort. And bugs where the > human-readable assembly language is inconsistent with the "4,9,foo,3" > syntax would be inevitable and difficult to track down. Assemblers are > perfectly capable of parsing human-readable assembly language. Time required for assembly usually isn't an issue on today's machines, but certainly was an issue in the past; it may also remain an issue on some self-hosting embedded platforms. More significantly, while human programmers often benefit from vendor- specific features that are present in many assemblers, compilers would benefit more from being able to have their output treated identically by all vendors' assemblers. > If you want to save the time spent in the assembler, just have the > compiler backend generate binary machine code. Many development systems have incompatible object-code formats. Having a platform define a standard slightly-higher-level format which could then be turned into a compatible object file would make it possible to link code from multiple compilers provided they all output that format.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-12 11:41 -0800 |
| Message-ID | <lnd1gxq6ik.fsf@kst-u.example.com> |
| In reply to | #99110 |
supercat@casperkitty.com writes:
> On Monday, December 12, 2016 at 11:17:01 AM UTC-6, Keith Thompson wrote:
>> I don't think the size and speed of the assembler is particularly
>> relevant to the speed of compilation. Implementing and maintaining a
>> second assembly syntax, text-based but not meant to be human-readable,
>> would, in my opinion, be a waste of time and effort. And bugs where the
>> human-readable assembly language is inconsistent with the "4,9,foo,3"
>> syntax would be inevitable and difficult to track down. Assemblers are
>> perfectly capable of parsing human-readable assembly language.
>
> Time required for assembly usually isn't an issue on today's machines, but
> certainly was an issue in the past; it may also remain an issue on some
> self-hosting embedded platforms.
Self-hosting embedded platforms? How many of those exist (and are
relevant).
I can run a compiler on my phone, but that's possible because it runs an
OS based on Linux.
> More significantly, while human programmers often benefit from vendor-
> specific features that are present in many assemblers, compilers would
> benefit more from being able to have their output treated identically
> by all vendors' assemblers.
Ah, so you want to define a new text-based, but not human-readable,
assembly language format *and* you want *all* assemblers to recognize
it ...
>> If you want to save the time spent in the assembler, just have the
>> compiler backend generate binary machine code.
>
> Many development systems have incompatible object-code formats. Having a
> platform define a standard slightly-higher-level format which could then
> be turned into a compatible object file would make it possible to link
> code from multiple compilers provided they all output that format.
... including assemblers targeting instruction sets that are still being
developed.
Would this format be the same for different instruction sets, so
"4,9,foo,3" would be valid, and would have the same meaning, for all
targets? If so, it seems even more impractical. If not, I see little
point in the whole idea.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-12 12:31 -0800 |
| Message-ID | <f7279de4-2e78-4f7b-9d2d-e463fdf47405@googlegroups.com> |
| In reply to | #99119 |
On Monday, December 12, 2016 at 1:40:55 PM UTC-6, Keith Thompson wrote: > Would this format be the same for different instruction sets, so > "4,9,foo,3" would be valid, and would have the same meaning, for all > targets? If so, it seems even more impractical. If not, I see little > point in the whole idea. The idea would be that the hardware vendor would supply a recommended format along with the rest of the ABI. If three vendors develop assemblers for five different architectures, there's no way compilers that want to work with all of them would be able to avoid including logic for five different targets, but requiring that they include logic for all fifteen combinations of hardware and devtool vendor seems needlessly wasteful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-12 13:13 -0800 |
| Message-ID | <ln4m28rgtp.fsf@kst-u.example.com> |
| In reply to | #99126 |
supercat@casperkitty.com writes:
> On Monday, December 12, 2016 at 1:40:55 PM UTC-6, Keith Thompson wrote:
>> Would this format be the same for different instruction sets, so
>> "4,9,foo,3" would be valid, and would have the same meaning, for all
>> targets? If so, it seems even more impractical. If not, I see little
>> point in the whole idea.
>
> The idea would be that the hardware vendor would supply a recommended
> format along with the rest of the ABI. If three vendors develop
> assemblers for five different architectures, there's no way compilers
> that want to work with all of them would be able to avoid including
> logic for five different targets, but requiring that they include
> logic for all fifteen combinations of hardware and devtool vendor
> seems needlessly wasteful.
https://xkcd.com/927/
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-12 20:22 +0000 |
| Message-ID | <o2n0ri$37a$1@dont-email.me> |
| In reply to | #99110 |
On 12/12/2016 19:03, supercat@casperkitty.com wrote: > On Monday, December 12, 2016 at 11:17:01 AM UTC-6, Keith Thompson wrote: >> I don't think the size and speed of the assembler is particularly >> relevant to the speed of compilation. Implementing and maintaining a >> second assembly syntax, text-based but not meant to be human-readable, >> would, in my opinion, be a waste of time and effort. And bugs where the >> human-readable assembly language is inconsistent with the "4,9,foo,3" >> syntax would be inevitable and difficult to track down. Assemblers are >> perfectly capable of parsing human-readable assembly language. > > Time required for assembly usually isn't an issue on today's machines, but > certainly was an issue in the past; it may also remain an issue on some > self-hosting embedded platforms. It shouldn't be but it is. It shouldn't have been in the past either. The first time I got a compiler to generate ASM source (early 2000s), it took five times as long to assemble the output as it took me to compile high level source code. Even though the assembler's job is far simpler. That was NASM 1. NASM 2 is faster, but I tested it recently, and compared it with my first assembler (c. 1980): My assembler (Z80 8-bit 2.5 MHz) 1,700 lines per second Nasm 2 (AMD 64-bit 2.7 GHz) 23,000 lines per second. Only 13 times faster, when it ought be 1000 times faster! (If I wrote an assembler now, I know it will probably work at 2M lps or more.) But then, NASM is particularly slow. Something like GoASM will probably be much faster (but with the new ultra fast compiler I'm planning, any sort of ASM stage - following by all the linking business - will make it grind to a halt). With the assemblers built-in to the back-end of some compilers, I can't judge how fast they might be. Perhaps they're actually efficient! > More significantly, while human programmers often benefit from vendor- > specific features that are present in many assemblers, compilers would > benefit more from being able to have their output treated identically > by all vendors' assemblers. Every assembler I've ever tried has been bristling with features that I never use! And as I usually write most executable ASM code as inline code within a high-level language, I demand very little in the way of features. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 14:49 +0000 |
| Message-ID | <871sxezfjy.fsf@bsb.me.uk> |
| In reply to | #98765 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Sat, 10 Dec 2016 08:37:00 -0800 (PST), "Rick C. Hodgin" > <rick.c.hodgin@gmail.com> wrote: <snip> >>Seriously, I will never use AT&T syntax. It breaks my heart that it >>even exists. > > While I think Intel syntax for x86 is better than AT&T, it's hardly a > career changer. Quitting your profession for that reason would be > like a trucker deciding to quit their job because they didn't like the > new font on the updated company logo painted on the side of the truck. > It's just massively far down the list of priorities. Er... do realise you are taking to someone who won't use Apple products because of their logo? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-11 07:10 -0800 |
| Message-ID | <ec7a9dc3-7df0-4f64-9a35-7e5ac9489f13@googlegroups.com> |
| In reply to | #98804 |
Ben Bacarisse wrote: > Er... do realise you are taking to someone who won't use Apple products > because of their logo? Not quite. It's the spirit behind the company, which manifests itself in the outrageous financial and product success seen in the world, which is then also manifested in its logo. The spirit at work is why I reject it. The logo is just one outward manifestation of that spirit. The same is true for Starbucks. A serpenty logo representative of the underlying spirit at work. Why else would people pay so much for a cup of coffee? Or for a shiny device in Apple's case? That anti-Chrrist spirit moves in unsaved people, guidung them unaware. They are slaves to unseen forces unaware. And only Jesus Christ can set a person free from that bondage, and give them new eyes to see the spirit at work there for what ut is (evil). When I checked a few years ago, Apple, Inc. had cash on hand and sales placing it in the top 20 nations in the world, ahead of Poland. That doesn't happen by accident. That is a spirit at work with the anti-Christ spirit in this world. Whereas efforts like mine, given over to Christ as an offering of worship, are shunned by virtually everybody, and ridiculed openly by most. ----- There really is a war on for your eternal soul. Whether you win or lose the war is entirely dependent upon what you did with Jesus Christ. If you believe in Him and ask Him to forgive your sin, you win. If you reject Him you have already lost as you remain under condemnation. The spirit at work in a person or thing created by people is evident by its fruit. And it is very easy to gloss over the surface and think you have the correct answer. The truth requires a deeper investigation. I advise you to pursue it, Ben. Rigorously. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-11 07:21 -0800 |
| Message-ID | <959b3cf6-4b7a-43d0-a553-295473971f49@googlegroups.com> |
| In reply to | #98808 |
On Sunday, December 11, 2016 at 9:10:31 AM UTC-6, Rick C. Hodgin wrote: > The same is true for Starbucks. A serpenty logo representative of the > underlying spirit at work. Why else would people pay so much for a > cup of coffee? Or for a shiny device in Apple's case? That anti-Chrrist > spirit moves in unsaved people, guidung them unaware. They are slaves > to unseen forces unaware. And only Jesus Christ can set a person free > from that bondage, and give them new eyes to see the spirit at work > there for what ut is (evil). > Not sure if this is better or worse, but the Starbucks mascot is a Siren from Greek mythology. A foul creature who lures sailors with her song to their doom. -- free the nipple
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-11 10:33 -0800 |
| Message-ID | <667e4ead-0b7e-49bb-90cb-75b8cb61f226@googlegroups.com> |
| In reply to | #98810 |
On Sunday, December 11, 2016 at 10:22:00 AM UTC-5, luser droog wrote: > On Sunday, December 11, 2016 at 9:10:31 AM UTC-6, Rick C. Hodgin wrote: > > > The same is true for Starbucks. A serpenty logo representative of the > > underlying spirit at work. Why else would people pay so much for a > > cup of coffee? Or for a shiny device in Apple's case? That anti-Chrrist > > spirit moves in unsaved people, guidung them unaware. They are slaves > > to unseen forces unaware. And only Jesus Christ can set a person free > > from that bondage, and give them new eyes to see the spirit at work > > there for what ut is (evil). > > > > Not sure if this is better or worse, but the Starbucks mascot is > a Siren from Greek mythology. A foul creature who lures sailors > with her song to their doom. I'm not sure how reliable this is, but it goes into more detail and makes more sense to me than the other explanations I've found: <http://www.deadprogrammer.com/starbucks-logo-mermaid> Given the sexual motivation for the concept of twin-tailed mermaids, I doubt that Rick would be any happier with this explanation than he is with his own satanic explanation.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-12-11 16:22 +0100 |
| Message-ID | <20161211162228.3ee9580b@maxa-pc> |
| In reply to | #98808 |
On Sun, 11 Dec 2016 07:10:25 -0800 (PST) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > Ben Bacarisse wrote: > > Er... do realise you are taking to someone who won't use Apple > > products because of their logo? > > Not quite. It's the spirit behind the company, which manifests itself > in the outrageous financial and product success seen in the world, > which is then also manifested in its logo. > .... Fuck! > The spirit at work in a person or thing created by people is evident > by its fruit. And it is very easy to gloss over the surface and think > you have the correct answer. The truth requires a deeper > investigation. I advise you to pursue it, Ben. Rigorously. God is dead! Satan lives! Hail Satan! -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-11 07:16 -0800 |
| Message-ID | <a1ff4fd8-ef8a-4213-a60e-068847206add@googlegroups.com> |
| In reply to | #98804 |
On Sunday, December 11, 2016 at 8:49:44 AM UTC-6, Ben Bacarisse wrote: > Robert Wessel <robertwessel2@yahoo.com> writes: > > > On Sat, 10 Dec 2016 08:37:00 -0800 (PST), "Rick C. Hodgin" > > <rick.c.hodgin@gmail.com> wrote: > <snip> > >>Seriously, I will never use AT&T syntax. It breaks my heart that it > >>even exists. > > > > While I think Intel syntax for x86 is better than AT&T, it's hardly a > > career changer. Quitting your profession for that reason would be > > like a trucker deciding to quit their job because they didn't like the > > new font on the updated company logo painted on the side of the truck. > > It's just massively far down the list of priorities. > > Er... do realise you are taking to someone who won't use Apple products > because of their logo? > I don't use them because of their price tag, which is completely removable or only on the box usually. -- and not enough mouse buttons. I miss 3-buttons and the Athena widgets.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 13:54 -0800 |
| Message-ID | <o2pqkv$dpb$1@dont-email.me> |
| In reply to | #98765 |
On 12/11/2016 12:51 AM, Robert Wessel wrote: > On Sat, 10 Dec 2016 08:37:00 -0800 (PST), "Rick C. Hodgin" > <rick.c.hodgin@gmail.com> wrote: > >> On Friday, December 9, 2016 at 8:46:36 PM UTC-5, Chris M. Thomasson wrote: >>> On 12/9/2016 5:00 PM, Rick C. Hodgin wrote: >>>> Chris M. Thomasson wrote: >>>>> Yikes! Humm, you probably should not look at this: >>>>> >>>>> http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm >>>>> >>>>> Your eyes might start bleeding... >>>>> >>>>> ;^) >>>> >>>>> >>>>> I like both AT&T and Intel syntax. I can use them both, and that is okay >>>>> with me >>>> >>>> If forced to use AT&T syntax, I would switch professions. Not joking. >>> >>> Wow! >> >> I did a brief impromptu poll in my family, with my non-programmer wife >> who doesn't have any interest in programming, and my 12-year old son >> who is very much like his mother, and they both agreed that the Intel >> syntax is preferable. >> >> Here are some of their reasons: >> >> 1) Like the brackets more than parenthesis. >> 2) The % symbol everywhere is "just weird." >> 3) The Intel syntax aligns things in columns more easily with >> the variable-length number being after the left-side, which >> helps it be seen more easily, as in this page: >> http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html >> >> versus this page: >> http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html >> >> 4) The AT&T syntax looks "generally busy." >> 5) The Intel syntax is nicely spaced, and "simplified." >> >> Could not agree more. And, I gave them no prompting in finding this >> information out. I sent them this email unannounced and unspoken to >> regarding the poll: >> >> -----[ Begin ]----- >> Subject: Opinion poll -- Which is easier to read >> >>From a straight-forward easiness of reading, which one is easier to read? >> >> #1 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html >> >> Or #2 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html >> >> Please choose #1 or #2. >> -----[ End ]----- >> >> I'd be curious what your non-programmer friends/family think with that >> poll. And also what your programmer friends/family think. :-) >> >> Seriously, I will never use AT&T syntax. It breaks my heart that it >> even exists. > > > While I think Intel syntax for x86 is better than AT&T, it's hardly a > career changer. Quitting your profession for that reason would be > like a trucker deciding to quit their job because they didn't like the > new font on the updated company logo painted on the side of the truck. > It's just massively far down the list of priorities. Possible Scenario -> Rick's Boss: ___________________________________ Our company was fortunate enough to get an important customer, who happens to want some assembly language functions that solve x, y and z in AT&T syntax for x86 and SPARC. We want you Rick, to create the x86 version because we really like your asm skills buddy! ___________________________________ Would Rick "really" quit, in real life? ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 14:09 -0800 |
| Message-ID | <71e55abd-b7ba-4666-8829-9b930fea2511@googlegroups.com> |
| In reply to | #99271 |
On Tuesday, December 13, 2016 at 4:55:05 PM UTC-5, Chris M. Thomasson wrote: > Possible Scenario -> Rick's Boss: > ___________________________________ > Our company was fortunate enough to get an important customer, who > happens to want some assembly language functions that solve x, y and z > in AT&T syntax for x86 and SPARC. We want you Rick, to create the x86 > version because we really like your asm skills buddy! > ___________________________________ > > Would Rick "really" quit, in real life? If they wanted my skills on such a project, they would give me some kind of leeway to write a utility which uses an Intel-like syntax. Absent that, I would pass on the project. And if it became some conditional factor on my employment, I would leave. The same if they tried to get me to write an app for iPads or iPhones, or to use any of the Apple-supported toolsets. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-13 14:31 -0800 |
| Message-ID | <o2psoh$ldt$1@dont-email.me> |
| In reply to | #99277 |
On 12/13/2016 2:09 PM, Rick C. Hodgin wrote: > On Tuesday, December 13, 2016 at 4:55:05 PM UTC-5, Chris M. Thomasson wrote: >> Possible Scenario -> Rick's Boss: >> ___________________________________ >> Our company was fortunate enough to get an important customer, who >> happens to want some assembly language functions that solve x, y and z >> in AT&T syntax for x86 and SPARC. We want you Rick, to create the x86 >> version because we really like your asm skills buddy! >> ___________________________________ >> >> Would Rick "really" quit, in real life? > > If they wanted my skills on such a project, they would give me some > kind of leeway to write a utility which uses an Intel-like syntax. > Absent that, I would pass on the project. And if it became some > conditional factor on my employment, I would leave. The same if > they tried to get me to write an app for iPads or iPhones, or to > use any of the Apple-supported toolsets. Okay, your Boss tells you: Write the solution in Intel syntax. Then pass it over to another employee that can convert it to AT&T to satisfy the customers requirements. There is something that might make you uneasy: When you give your code over to the converter... We want you to review the resulting AT&T syntax before we sign off on it. Please Rick, do not quit over this! ;^o Would you stay?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 16:11 -0800 |
| Message-ID | <c20ec774-6413-406c-a3f9-265d9aef17e2@googlegroups.com> |
| In reply to | #99284 |
On Tuesday, December 13, 2016 at 5:31:07 PM UTC-5, Chris M. Thomasson wrote: > On 12/13/2016 2:09 PM, Rick C. Hodgin wrote: > > On Tuesday, December 13, 2016 at 4:55:05 PM UTC-5, Chris M. Thomasson wrote: > >> Possible Scenario -> Rick's Boss: > >> ___________________________________ > >> Our company was fortunate enough to get an important customer, who > >> happens to want some assembly language functions that solve x, y and z > >> in AT&T syntax for x86 and SPARC. We want you Rick, to create the x86 > >> version because we really like your asm skills buddy! > >> ___________________________________ > >> > >> Would Rick "really" quit, in real life? > > > > If they wanted my skills on such a project, they would give me some > > kind of leeway to write a utility which uses an Intel-like syntax. > > Absent that, I would pass on the project. And if it became some > > conditional factor on my employment, I would leave. The same if > > they tried to get me to write an app for iPads or iPhones, or to > > use any of the Apple-supported toolsets. > > Okay, your Boss tells you: > > Write the solution in Intel syntax. Then pass it over to another > employee that can convert it to AT&T to satisfy the customers requirements. > > There is something that might make you uneasy: When you give your code > over to the converter... We want you to review the resulting AT&T syntax > before we sign off on it. > > Please Rick, do not quit over this! > > ;^o > > > Would you stay? Absolutely. So long as I could write, debug, and maintain in Intel syntax ... I'm good go to go. :-) It is only for my personal needs in this area, and not because I think AT&T syntax couldn't produce usable code or product an equally valid product ... I just find it unworkable to use. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-23 06:49 -0700 |
| Message-ID | <afb0e43b-8d9d-4498-8558-fa395d02ba5c@googlegroups.com> |
| In reply to | #92630 |
On Tuesday, August 23, 2016 at 9:31:20 AM UTC-4, David Brown wrote: > On 23/08/16 14:23, Rick C. Hodgin wrote: > > On Tuesday, August 23, 2016 at 3:14:28 AM UTC-4, David Brown wrote: > >> An online compiler is marvellous for such testing: > >> <http://gcc.godbolt.org/#> > > > > "God Bolt"? You don't know me at all, David, do you? :-) > > > > It never occurred to me to notice - and even if I had, I would not have > thought you would be bothered by some guy's name. It seems a big jump > to assume that the domain name here is picked with some religious or > anti-religious meaning just because it has the three letters g, o and d > in sequence. For all you know, it could be from a different language - > the web is not just made by "merkins" - in Norwegian, the word "god" > simply means "good". I contacted Matt to personally apologize, and he conveyed the same thing in reply. He said the last name is likely a misspelling of "good bolt" as in "good in archery" or "good in making crossbow bolts", etc. I had no idea. But, it's interesting. ----- Well, I definitely need to revisit my "quick assessment" of people's names giving the global nature of our communication these days, and the multitude of languages, names, and cultures I have insufficient knowledge of. Lesson learned. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-21 05:50 -0600 |
| Message-ID | <wd2dnYN22Jbj8cfFnZ2dnUU7-dPNnZ2d@supernews.com> |
| In reply to | #92630 |
David Brown <david.brown@hesbynett.no> wrote: > As for the difference between the syntaxes, AT&T is common in the > *nix world, and Intel is common in DOS + Windows world. In the early GCC days, compiler developers commonly used the OS assembler and linker, so it was essential to make GCC compatible with the OS tools. Once GAS was done, it made perfect sense to make it compatible with the system assembler. (Many people don't realize that that GCC and GNU Binutils are actually separate projects.) > I think the AT&T syntax is actually older - it is basically the same > style as for other processors, and they had an assembler for the x86 > before Intel had standardised on a syntax. That's really interesting, and I had no idea. Can you tell me how you know this? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-21 13:10 +0100 |
| Message-ID | <o3drdp$jv7$1@dont-email.me> |
| In reply to | #99980 |
On 21/12/16 12:50, Andrew Haley wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> As for the difference between the syntaxes, AT&T is common in the >> *nix world, and Intel is common in DOS + Windows world. > > In the early GCC days, compiler developers commonly used the OS > assembler and linker, so it was essential to make GCC compatible with > the OS tools. Once GAS was done, it made perfect sense to make it > compatible with the system assembler. (Many people don't realize that > that GCC and GNU Binutils are actually separate projects.) > While I agree with you in principle, a key point is that DOS and Windows have never had such a thing as a "system assembler" (or linker). And while the different assemblers available for x86 on DOS and Windows (with the exception of gas) have used Intel syntax as far as I know, they have differed somewhat in the details of assembler directives, command line options, etc. gcc was simply not available on Windows until gas (and the rest of binutils) was also ported, and gcc always uses gas on Windows. So compatibility with other assemblers was never really an issue here, as it had been on *nix systems. (For the record, /I/ know that they are separate projects - but I agree that many people don't realise it.) >> I think the AT&T syntax is actually older - it is basically the same >> style as for other processors, and they had an assembler for the x86 >> before Intel had standardised on a syntax. > > That's really interesting, and I had no idea. Can you tell me how you > know this? > I can't remember where I picked this up (assuming, of course, that I am correct - I added the "I think" escape clause because I am not sure). I believe the AT&T x86 syntax was based on the AT&T syntax for older processors, such as those used on the PDP-11.
[toc] | [prev] | [next] | [standalone]
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web