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 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 15:56 +0200 |
| Message-ID | <nphkmc$ng7$1@dont-email.me> |
| In reply to | #92625 |
On 23/08/16 15:01, Rick C. Hodgin wrote: > On Tuesday, August 23, 2016 at 8:52:25 AM UTC-4, Rick C. Hodgin wrote: >> ...Stallman, >> for example, believes several heinous things should be legal including >> pedophelia (). > We don't need the link - people who are interested can look it up for themselves. RMS is not shy about saying what he thinks. He basically believes in "no harm, no foul". He is completely against /harming/ children. But he is also against the idea that a particular type of action /always/ causes harm, and therefore /always/ should be treated the same way. Norms change. What we we consider "heinous" changes - over time, from place to place, from culture to culture, and amongst groups and individuals. Why is it that consensual sex with a 16 year old on their birthday (in most countries) is perfectly legal - but the same act the day before is the "heinous" crime of paedophilia, carrying many years jail sentence, even if the other party is just a couple of days older? And you don't have to go too far back in history to the point where a 16 year old would often be married for several years, and have kids of their own. Of course, you believe in certain "absolute" rules because of your faith, but many people prefer to be more concerned about the actual effect of actions rather than drawing lines that must not be crossed. RMS is one such person - and he has a fondness for expressing himself in the most dramatic and provocative way he can. Most people are able to separate a person's opinions and comments from their work. RMS has some far-out opinions, but that does not mean that the FSF, the gnu developers, or gnu users are a den of iniquity by association.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-23 06:59 -0700 |
| Message-ID | <ce73a070-0079-4633-8762-0ed1701e11e2@googlegroups.com> |
| In reply to | #92637 |
On Tuesday, August 23, 2016 at 9:56:36 AM UTC-4, David Brown wrote:
> [snip]
Basically, it comes from placing value on God, and God's teachings. By
submitting to Him, you have absolute authority to return to. When you
leave God and God's teachings out of things, you are subject to your own
personal whims, personal interpretations. It's what we see in this world
with the "changing norms":
http://biblehub.com/kjv/judges/21-25.htm
"In those days there was no king in Israel: every man did that which
was right in his own eyes."
It is the same today, as people have abandoned their true King: Jesus.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-23 10:42 -0700 |
| Message-ID | <lnh9abfkku.fsf@kst-u.example.com> |
| In reply to | #92637 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Most people are able to separate a person's opinions and comments from
> their work. RMS has some far-out opinions, but that does not mean that
> the FSF, the gnu developers, or gnu users are a den of iniquity by
> association.
Most people are able to separate things that are topical on comp.lang.c
from things that are not. David, you seem to lack that ability.
I ask you one more time, please stop feeding the troll.
--
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 | matt@godbolt.org |
|---|---|
| Date | 2016-08-23 06:47 -0700 |
| Message-ID | <59efcc90-ddd5-481a-a423-ae3ad6fdc205@googlegroups.com> |
| In reply to | #92622 |
Lots of edits below - just dipping in to this conversation :) > On Tuesday, August 23, 2016 at 8:42:49 AM UTC-4, mark.b...@gmail.com wrote: > > I don't think Matt Godbolt will change his name to pander to your > > frankly bizarre outlook. On Tuesday, August 23, 2016 at 7:52:25 AM UTC-5, Rick C. Hodgin wrote: > Well, it's my mistake then. Matt is the first "Godbolt" I've ever heard > of in my 47 years. I had concluded based on the two names added together > that it was something demeaning. My apologies to Matt and his family. Rick emailed me off-list and apologised, there's honestly no offence taken. I have an unusual name :) It's weirdly become synonymous with Compiler Explorer: I hear people saying "Let's check that code on godbolt" -- clearly many people don't realise it's my family name! As a friend said when I mentioned this "Talk about being religious about languages" :) Regards to all, Matt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 15:57 +0200 |
| Message-ID | <nphkov$ng7$2@dont-email.me> |
| In reply to | #92634 |
On 23/08/16 15:47, matt@godbolt.org wrote: > Lots of edits below - just dipping in to this conversation :) > >> On Tuesday, August 23, 2016 at 8:42:49 AM UTC-4, >> mark.b...@gmail.com wrote: >>> I don't think Matt Godbolt will change his name to pander to >>> your frankly bizarre outlook. > On Tuesday, August 23, 2016 at 7:52:25 AM UTC-5, Rick C. Hodgin > wrote: >> Well, it's my mistake then. Matt is the first "Godbolt" I've ever >> heard of in my 47 years. I had concluded based on the two names >> added together that it was something demeaning. My apologies to >> Matt and his family. > > Rick emailed me off-list and apologised, there's honestly no offence > taken. I have an unusual name :) It's weirdly become synonymous with > Compiler Explorer: I hear people saying "Let's check that code on > godbolt" -- clearly many people don't realise it's my family name! > > As a friend said when I mentioned this "Talk about being religious > about languages" :) > > Regards to all, Matt > Since you are online here, let me take the chance to thank you for that website. It is /really/ useful!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 15:31 +0200 |
| Message-ID | <nphj6v$ia4$1@dont-email.me> |
| In reply to | #92619 |
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".
>> f(U*, U*): # @f(U*, U*)
>> movq $42, (%rsi)
>> movq $0, (%rdi)
>> movl $42, %eax
>> retq
>
> And if I may just say this one thing: it's flatly wrong to use AT&T
> syntax when Intel syntax exists. AT&T syntax is like trying to read
> what should be simplicity in a sea of chaos.
>
It seems perfectly obvious to me. I've worked with dozens of different
assembly languages over the years, and find no problems with this. Of
course, if you are used to writing x86 assembly code (I am not - it's
about the one processor I /haven't/ programmed in assembly), then extra
familiarity with the Intel syntax will make the AT&T syntax harder.
But for code like this, it should be clear - obviously, the order here
is "source -> dest" rather than Intel's "dest <- source".
As for the difference between the syntaxes, AT&T is common in the *nix
world, and Intel is common in DOS + Windows world. 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. Both work fine for most instructions, and
both are ugly for complicated addressing modes. Intel syntax is nicer
for some things, but AT&T is more compact for code like this, rather than:
f(U*, U*): # @f(U*, U*)
mov qword ptr [rsi], 42
mov qword ptr [rdi], 0
mov eax, 42
ret
f(U*, U*):
mov QWORD PTR [rsi], 42
mov QWORD PTR [rdi], 0
mov rax, QWORD PTR [rsi]
ret
Both gcc and clang will give you Intel syntax with the switch "-masm=intel".
But in both cases, it is clearer and simpler to write in C and leave the
x86 assembly to the compiler writers :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-23 06:43 -0700 |
| Message-ID | <923445eb-4e67-4431-b695-53b9b3b50ec5@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: > > And if I may just say this one thing: it's flatly wrong to use AT&T > > syntax when Intel syntax exists. AT&T syntax is like trying to read > > what should be simplicity in a sea of chaos. > > Both gcc and clang will give you Intel syntax with the switch "-masm=intel". I am well aware of that. It's why I said, "...when Intel syntax exists." Along with AT&T syntax, I can also read Olde English text. I just prefer not to when modern English is available, and is so much easier to read. I think it's also presumptuous of AT&T to conclude a syntax having far more characters and symbols is a better choice than Intel's own syntax. Intel's syntax is much cleaner, and is the one they created for use with their own hardware. I have never understood AT&T's reasoning in creating what they did with x86 syntax. And, I have never understood why the people working on GCC chose that syntax over Intel's. And I think it speaks volumes that some developers went out of their way to rewrite the assembly generation algorithms to also allow Intel syntax, when it is a great deal of effort to do so, and did not exist for years (introduced only in the mid-2000s). As for CAlive, and all LibSF x86-based products, they will always and likely only support Intel's syntax. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-23 16:06 +0200 |
| Message-ID | <nphl89$pog$1@dont-email.me> |
| In reply to | #92632 |
On 23/08/16 15:43, Rick C. Hodgin wrote: > 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: >>> And if I may just say this one thing: it's flatly wrong to use AT&T >>> syntax when Intel syntax exists. AT&T syntax is like trying to read >>> what should be simplicity in a sea of chaos. >> >> Both gcc and clang will give you Intel syntax with the switch "-masm=intel". > > I am well aware of that. It's why I said, "...when Intel syntax exists." > > Along with AT&T syntax, I can also read Olde English text. I just prefer > not to when modern English is available, and is so much easier to read. > > I think it's also presumptuous of AT&T to conclude a syntax having far > more characters and symbols is a better choice than Intel's own syntax. > Intel's syntax is much cleaner, and is the one they created for use with > their own hardware. I have never understood AT&T's reasoning in creating > what they did with x86 syntax. As I noted, AT&T's syntax is older than Intel's. The question is, why did Intel bother making their own syntax when AT&T's existed and was familiar for many assembly programmers? As for "cleaner", it's a matter of opinion. Google a bit, and you will see both opinions expressed as though it was obvious and you'd have to be mad to think the other way. From what I have seen, some things are clearer in one syntax, others are clearer in the other syntax. Both leave much to be desired. > And, I have never understood why the > people working on GCC chose that syntax over Intel's. gcc and gas already supported the AT&T syntax for other processors when they started working on x86. Details vary a little between processors, but the aim of AT&T was to get a syntax that was as close to portable as possible for assembly. So while Intel syntax had appeal for those that think the world revolves around x86, AT&T has always been popular with people who like a variety of processors. > And I think it > speaks volumes that some developers went out of their way to rewrite the > assembly generation algorithms to also allow Intel syntax, when it is a > great deal of effort to do so, and did not exist for years (introduced > only in the mid-2000s). They added support for Intel syntax because gcc was beginning to be popular on Windows rather than just *nix, and users were asking for support. First, support for parsing the syntax in gas (the gnu assembler) was needed - support for generating it in gcc was probably a small task. > > As for CAlive, and all LibSF x86-based products, they will always and > likely only support Intel's syntax. > Your choice.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-23 07:15 -0700 |
| Message-ID | <77aa1383-5827-4627-8b3e-0e602754b548@googlegroups.com> |
| In reply to | #92640 |
On Tuesday, August 23, 2016 at 10:06:10 AM UTC-4, David Brown wrote: > On 23/08/16 15:43, Rick C. Hodgin wrote: > > I think it's also presumptuous of AT&T to conclude a syntax having far > > more characters and symbols is a better choice than Intel's own syntax. > > Intel's syntax is much cleaner, and is the one they created for use with > > their own hardware. I have never understood AT&T's reasoning in creating > > what they did with x86 syntax. > > As I noted, AT&T's syntax is older than Intel's. The question is, why > did Intel bother making their own syntax when AT&T's existed and was > familiar for many assembly programmers? Well, I think it's obvious ... they were trying to save developer's eyes. They offered an alternative CPU, and an alternative assembler syntax, both were better, and both were them trying to make the world a better place. And might I just say that's definitely one area where Intel got it right! :-) AT&T's syntax older than Intel's ... people used to write in other languages, including Olde English. Things change over time because improvements come along ... like Intel's syntax. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-04 13:26 +0100 |
| Message-ID | <o2120v$tud$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #92640 |
In article <nphl89$pog$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: <SNIP> >As I noted, AT&T's syntax is older than Intel's. The question is, why >did Intel bother making their own syntax when AT&T's existed and was >familiar for many assembly programmers? Maybe for extortion reasons, i.e. patenting it or similar annoyances? So much is sure that Zilog wasn't allowed to use Intels 8080 instruction mnemonics in its assemblers, and developped the (much better) Z80 instruction set. <SNIP> >Your choice. Groetjes, Albert > > -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-05 22:07 -0600 |
| Message-ID | <rkcc4ctqglmac3c11hhc0k4mlqqemqeiak@4ax.com> |
| In reply to | #97973 |
On Sun, 4 Dec 2016 13:26:07 +0100 (CET), albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote: >In article <nphl89$pog$1@dont-email.me>, >David Brown <david.brown@hesbynett.no> wrote: ><SNIP> >>As I noted, AT&T's syntax is older than Intel's. The question is, why >>did Intel bother making their own syntax when AT&T's existed and was >>familiar for many assembly programmers? Common(-ish) assembler syntax is a pretty new thing. Every machine having its own assembler, often wildly different, used to be the rule. Within a manufacturer, you often saw more than a bit of similarities in assemblers for different machines. And AT&T assembler syntax largely evolved from DEC's PDP-11 assembler syntax, and that only predated the 8080 by a few years. The PDP-11 shipped in 1970, the 8080 in 1974, and Intel was working on it in 1972, so there would have been very little chance of a "standard" developing from the PDP-11 in that interval. More specifically, PAL-11 and MACRO-11 evolved into the Unix as (which then headed towards gas), and that didn't exist outside of AT&T until about 1973. Further, the (Intel) 8080 assembler syntax is a clear descendent of the 8008 assembler syntax, and that chip shipped in 1972. The Intel 8086 assembler was again an evolution of the 8080 assembler. As for x86, gas has never supported the x86 segmentation model very well, so that would be have an issue as well. And back them programming in assembler was a serious issue for many people, AT&T syntax, at least as implemented by as and gas, doesn't make for a very good assembler. as and gas exist mainly to serve as the back end for some compilers, actual use by programmers was a secondary consideration (it works, but that's about all you can say about it). And since gas is intended to be fairly generic, there are more than a few syntax quirks on may ISAs (consider the classic x86 "fsub %st,%st(2)" issue, which leaves the result of %st-%st(2) in %st(2), which is unexpected, to say the least, given the usual operand ordering). >Maybe for extortion reasons, i.e. patenting it or similar annoyances? >So much is sure that Zilog wasn't allowed to use Intels 8080 >instruction mnemonics in its assemblers, and developped the (much better) >Z80 instruction set. The two are unrelated. Zilog enhanced the ISA, and then developed a new set of mnemonics because Intel had a (questionable, IMO) copyright on the 8080 mnemonics.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 06:22 -0800 |
| Message-ID | <7bceee4f-6335-4f35-82b0-9340cdfe204f@googlegroups.com> |
| In reply to | #98120 |
On Monday, December 5, 2016 at 10:07:46 PM UTC-6, robert...@yahoo.com wrote: > Further, the (Intel) 8080 assembler syntax is a clear descendent of > the 8008 assembler syntax, and that chip shipped in 1972. The Intel > 8086 assembler was again an evolution of the 8080 assembler. As for > x86, gas has never supported the x86 segmentation model very well, so > that would be have an issue as well. Various assembler features are more necessary on some architectures than others. For example, some architectures have many instructions which can be used with either an immediate operand or a value fetched from memory, while others have dedicated instructions for use with immediate operands. Likewise, some support direct-mode addressing, while others don't. Some support double-indirect addressing. The question, then, of what addressing mode should be represented by an instruction like "and ah,x" would depend upon the target architecture. I'm personally a fan of using # for immediate addressing with any instruction that can use either direct or immediate mode, and brackets for indirect addressing on architectures that use that [thus avoiding ambiguity altogether] and am not particularly keen on Intel's assembler's use of the symbol to select an addressing mode, but recognize that requiring # for instructions which can't use anything but immediate mode, or [] for instructions which can't use immediate mode, would be a bit silly. On something like a 6502, it might also be awkward to have "and [[foo,x]]" as the syntax for indexed indirect addressing while using "and [foo,x]" represented ordinary indexed addressing (MOS Technologies' recommended syntax for indexed indirect addressing is "adc (foo,x)", and for ordinary indexed addressing "adc foo,x"; immediate addressing is "adc #value".
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-07 00:50 -0600 |
| Message-ID | <1r9f4c9oocnef0k2f0rqpbsdjd6rk1is6v@4ax.com> |
| In reply to | #98163 |
On Tue, 6 Dec 2016 06:22:50 -0800 (PST), supercat@casperkitty.com
wrote:
>On Monday, December 5, 2016 at 10:07:46 PM UTC-6, robert...@yahoo.com wrote:
>> Further, the (Intel) 8080 assembler syntax is a clear descendent of
>> the 8008 assembler syntax, and that chip shipped in 1972. The Intel
>> 8086 assembler was again an evolution of the 8080 assembler. As for
>> x86, gas has never supported the x86 segmentation model very well, so
>> that would be have an issue as well.
>
>Various assembler features are more necessary on some architectures than
>others. For example, some architectures have many instructions which can
>be used with either an immediate operand or a value fetched from memory,
>while others have dedicated instructions for use with immediate operands.
>Likewise, some support direct-mode addressing, while others don't. Some
>support double-indirect addressing.
But how to code those in an assembler is more up to the designers of
the assembler (or at least its syntax), than the ISA designers
(although those often closely related groups). The S/360 guys decided
that operands should be basically untyped, and have separate mnemonics
for all the different variants of instructions. So you have A (add
fullword from memory), AH (add halfword from memory), AR (add
register), and more recently AGR, AGFR, ARK, AGRK, AY, AG, AGF, AFI,
AGFI, AHIK, AGHIK, AHY, AHI, and AGHI (the F forms are 32 bit - also
true if no size specified, the G forms are 64 bit, the R forms are
register-to-register, the I forms are immediates, the Y forms use an
extended addressing format, the K forms are three operand). And that
doesn't include a bunch of logical forms ("L" - aka unsigned),
interlocked ("S"), or oddball stuff (high word, carry, and some other
stuff). Had the assembler designers decided to provide for some
typing, an x86-like "add rax,ebx" (AGFR*) or "add rax,memory-dword"
(A), as well as the rest could have been done under a single mnemonic.
AT&T syntax (as opposed to Intel) moves x86 a fair way back to the
untyped S/360 style, where length suffixes are common, and things like
hashmarks for immediates are really a slightly misplaced modifier for
the mnemonic. So clearly both are possible for a single ISA.
And getting back to the Z-80 vs. 8080 assembler issue, you could
certainly write 8080 code in Z-80 assembler, you just had to avoid
anything that generated an instruction not on the 8080. At least one
Z-80 assembler even had an option to enforce that.
*Yes, I know there is not an actual x86 instruction like that (add
32-bit register to 64-bit register), but the extension of Intel syntax
to support such a thing is trivial.
>The question, then, of what addressing mode should be represented by an
>instruction like "and ah,x" would depend upon the target architecture.
>I'm personally a fan of using # for immediate addressing with any
>instruction that can use either direct or immediate mode, and brackets
>for indirect addressing on architectures that use that [thus avoiding
>ambiguity altogether] and am not particularly keen on Intel's assembler's
>use of the symbol to select an addressing mode, but recognize that
>requiring # for instructions which can't use anything but immediate mode,
>or [] for instructions which can't use immediate mode, would be a bit
>silly. On something like a 6502, it might also be awkward to have "and
>[[foo,x]]" as the syntax for indexed indirect addressing while using
>"and [foo,x]" represented ordinary indexed addressing (MOS Technologies'
>recommended syntax for indexed indirect addressing is "adc (foo,x)",
>and for ordinary indexed addressing "adc foo,x"; immediate addressing is
>"adc #value".
The debate as to whether assemblers should by typed is an old one.
IMO, both approaches have issues, and end up with awkward
constructions, especially as the ISA evolves over time. OTOH, both
approaches are clearly usable. Typing allows the assembler to catch
some errors, OTOH, given the nature of much assembler code, you end up
using bunches of "casts", since type information gets lost quite
often.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 06:33 -0800 |
| Message-ID | <182c8012-3187-4aa9-a557-0c5c13a2ffac@googlegroups.com> |
| In reply to | #98234 |
On Wednesday, December 7, 2016 at 12:50:13 AM UTC-6, robert...@yahoo.com wrote:
> On Tue, 6 Dec 2016 06:22:50 -0800 (PST), supercat wrote:
> >Various assembler features are more necessary on some architectures than
> >others. For example, some architectures have many instructions which can
> >be used with either an immediate operand or a value fetched from memory,
> >while others have dedicated instructions for use with immediate operands.
> >Likewise, some support direct-mode addressing, while others don't. Some
> >support double-indirect addressing.
>
> But how to code those in an assembler is more up to the designers of
> the assembler (or at least its syntax), than the ISA designers
> (although those often closely related groups).
It would be possible to design an assembly-language format which could cope
with every addressing mode that has ever been used in any remotely-popular
processor, and could handle many more besides. On the other hand, such a
format would end up being more verbose than one which was tailored for a
particular architecture, and would also tend to suggest in many cases the
availability of instructions which aren't actually available. For example,
on the PIC 16C54, which has a register called W and a file of numbered
registers called "F"-registers, one could write instructions equivalent to:
W = W ^ 0xA5
W = W ^ MyReg ; Assume MyReg is a label for some register
MyReg = W ^ MyReg
W = W - MyReg
MyReg = W - MyReg
Using a syntax like:
xor w,w,#0xA5
xor w,w,MyReg
xor MyReg,w,MyReg
sub w,w,MyReg
sub MyReg,w,MyReg
but that would suggest that those instructions offered a lot more choices
than they do. In fact, Microchip would use:
xorlw 0xA5
xorwf MyReg,w
xorwf MyReg,f
subwf MyReg,w
subwf MyReg,f
Operations that operate upon register files have a one-bit selection to
indicate whether the result should go into W or back to the register file;
a few operations like xor are available with immediate addressing, but many
others (including, for the 16C54, addition) are not.
Coding with an assembly language which mirrors the actual abilities of the
machine is more convenient than coding for a more verbose form. While
it might be more convenient for compiler writers to produce a more general
form of output and then have a matrix to describe what instructions are
actually available, humans will often have an easier time writing code which
which better fits the machine architecture.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-07 23:06 -0600 |
| Message-ID | <njph4c5sqtrtisul9j0cc8lvhdualo61m8@4ax.com> |
| In reply to | #98260 |
On Wed, 7 Dec 2016 06:33:59 -0800 (PST), supercat@casperkitty.com wrote: >On Wednesday, December 7, 2016 at 12:50:13 AM UTC-6, robert...@yahoo.com wrote: >> On Tue, 6 Dec 2016 06:22:50 -0800 (PST), supercat wrote: >> >Various assembler features are more necessary on some architectures than >> >others. For example, some architectures have many instructions which can >> >be used with either an immediate operand or a value fetched from memory, >> >while others have dedicated instructions for use with immediate operands. >> >Likewise, some support direct-mode addressing, while others don't. Some >> >support double-indirect addressing. >> >> But how to code those in an assembler is more up to the designers of >> the assembler (or at least its syntax), than the ISA designers >> (although those often closely related groups). > >It would be possible to design an assembly-language format which could cope >with every addressing mode that has ever been used in any remotely-popular >processor, and could handle many more besides. On the other hand, such a >format would end up being more verbose than one which was tailored for a >particular architecture, and would also tend to suggest in many cases the >availability of instructions which aren't actually available. For example, >on the PIC 16C54, which has a register called W and a file of numbered >registers called "F"-registers, one could write instructions equivalent to: > > W = W ^ 0xA5 > W = W ^ MyReg ; Assume MyReg is a label for some register > MyReg = W ^ MyReg > W = W - MyReg > MyReg = W - MyReg > >Using a syntax like: > > xor w,w,#0xA5 > xor w,w,MyReg > xor MyReg,w,MyReg > sub w,w,MyReg > sub MyReg,w,MyReg > >but that would suggest that those instructions offered a lot more choices >than they do. In fact, Microchip would use: > > xorlw 0xA5 > xorwf MyReg,w > xorwf MyReg,f > subwf MyReg,w > subwf MyReg,f > >Operations that operate upon register files have a one-bit selection to >indicate whether the result should go into W or back to the register file; >a few operations like xor are available with immediate addressing, but many >others (including, for the 16C54, addition) are not. > >Coding with an assembly language which mirrors the actual abilities of the >machine is more convenient than coding for a more verbose form. While >it might be more convenient for compiler writers to produce a more general >form of output and then have a matrix to describe what instructions are >actually available, humans will often have an easier time writing code which >which better fits the machine architecture. I don't necessarily disagree. And at this point I'm not sure if you're arguing for Intel or AT&T syntax - both have the "excess implied possibilities" problem, but in different ways. But my main point is that there isn't necessarily any one obvious minimum or best assembler syntax for any given ISA. But I do agree that a good assembler syntax will be at least somewhat specialized towards the ISA in question. OTTH, it matters less these days, since so much less assembler gets written.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-08 01:44 -0800 |
| Message-ID | <d9001a86-2b91-4dcf-98ab-194d7f0d32e9@googlegroups.com> |
| In reply to | #98337 |
robert...@yahoo.com wrote: > [snip] ... Intel or AT&T syntax - both have the "excess implied possibilities" > problem, but in different ways. What do you mean, Robert? I know of only a few cases where implied syntax could result in different opcodes being used. Cases like the size of an encoded immediate, of dual encoding opportunities like INT3 and INT 3, or in the REX range. Some are overcome with different mnemonics, or a "dword ptr" override. Only a small few are truly implied. Best regards, Rick C. Hodgin Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-08 06:58 -0600 |
| Message-ID | <orli4cdthvqu6ig8df1m2ssedr6sa0e4r1@4ax.com> |
| In reply to | #98348 |
On Thu, 8 Dec 2016 01:44:30 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >robert...@yahoo.com wrote: >> [snip] ... Intel or AT&T syntax - both have the "excess implied possibilities" >> problem, but in different ways. > >What do you mean, Robert? > >I know of only a few cases where implied syntax could result in different >opcodes being used. Cases like the size of an encoded immediate, of dual >encoding opportunities like INT3 and INT 3, or in the REX range. Some >are overcome with different mnemonics, or a "dword ptr" override. >Only a small few are truly implied. We're discussing cases where the syntax of the assembler can (incorrectly) imply the existence of operations that are not actually supported by the ISA. Consider the Intel syntax "mov" operation. It pretty generally moves things from one integer-ish register to another. But it not infact, fully orthogonal. For example, you can move a 16 bit GP register to a seg reg, but not one seg reg to another, or an immediate to a segreg, despite those being obvious possibilities based on the syntax. Likewise you can't do "mov cr2,dr3".
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-10 08:16 -0800 |
| Message-ID | <0eb7c069-94aa-4f7a-8bc8-cd720131502d@googlegroups.com> |
| In reply to | #98348 |
On Thursday, December 8, 2016 at 4:44:39 AM UTC-5, Rick C. Hodgin wrote: > robert...@yahoo.com wrote: > > [snip] ... Intel or AT&T syntax - both have the "excess implied possibilities" > > problem, but in different ways. > > What do you mean, Robert? > > I know of only a few cases where implied syntax could result in different > opcodes being used. Cases like the size of an encoded immediate, of dual > encoding opportunities like INT3 and INT 3, or in the REX range. Some > are overcome with different mnemonics, or a "dword ptr" override. > Only a small few are truly implied. Could somebody please repost this so Robert Wessel can read it? I'm genuinely curious as to what he was talking about here with the "excess implied possibilities" problem. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-11 02:47 -0600 |
| Message-ID | <rg4q4c92t89io4sip0u9obp9skrdfj90jo@4ax.com> |
| In reply to | #98710 |
On Sat, 10 Dec 2016 08:16:26 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >On Thursday, December 8, 2016 at 4:44:39 AM UTC-5, Rick C. Hodgin wrote: >> robert...@yahoo.com wrote: >> > [snip] ... Intel or AT&T syntax - both have the "excess implied possibilities" >> > problem, but in different ways. >> >> What do you mean, Robert? >> >> I know of only a few cases where implied syntax could result in different >> opcodes being used. Cases like the size of an encoded immediate, of dual >> encoding opportunities like INT3 and INT 3, or in the REX range. Some >> are overcome with different mnemonics, or a "dword ptr" override. >> Only a small few are truly implied. > >Could somebody please repost this so Robert Wessel can read it? I'm >genuinely curious as to what he was talking about here with the "excess >implied possibilities" problem. I actually responded a couple of days ago: ::We're discussing cases where the syntax of the assembler can ::(incorrectly) imply the existence of operations that are not actually ::supported by the ISA. Consider the Intel syntax "mov" operation. It ::pretty generally moves things from one integer-ish register to ::another. But it not infact, fully orthogonal. For example, you can ::move a 16 bit GP register to a seg reg, but not one seg reg to ::another, or an immediate to a segreg, despite those being obvious ::possibilities based on the syntax. Likewise you can't do "mov ::cr2,dr3".
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-09 15:49 -0800 |
| Message-ID | <o2ffrc$d8h$1@dont-email.me> |
| In reply to | #98337 |
On 12/7/2016 9:06 PM, Robert Wessel wrote: > On Wed, 7 Dec 2016 06:33:59 -0800 (PST), supercat@casperkitty.com > wrote: > >> On Wednesday, December 7, 2016 at 12:50:13 AM UTC-6, robert...@yahoo.com wrote: >>> On Tue, 6 Dec 2016 06:22:50 -0800 (PST), supercat wrote: >>>> Various assembler features are more necessary on some architectures than >>>> others. For example, some architectures have many instructions which can >>>> be used with either an immediate operand or a value fetched from memory, >>>> while others have dedicated instructions for use with immediate operands. >>>> Likewise, some support direct-mode addressing, while others don't. Some >>>> support double-indirect addressing. >>> >>> But how to code those in an assembler is more up to the designers of >>> the assembler (or at least its syntax), than the ISA designers >>> (although those often closely related groups). >> >> It would be possible to design an assembly-language format which could cope >> with every addressing mode that has ever been used in any remotely-popular >> processor, and could handle many more besides. On the other hand, such a >> format would end up being more verbose than one which was tailored for a >> particular architecture, and would also tend to suggest in many cases the >> availability of instructions which aren't actually available. For example, >> on the PIC 16C54, which has a register called W and a file of numbered >> registers called "F"-registers, one could write instructions equivalent to: >> >> W = W ^ 0xA5 >> W = W ^ MyReg ; Assume MyReg is a label for some register >> MyReg = W ^ MyReg >> W = W - MyReg >> MyReg = W - MyReg >> >> Using a syntax like: >> >> xor w,w,#0xA5 >> xor w,w,MyReg >> xor MyReg,w,MyReg >> sub w,w,MyReg >> sub MyReg,w,MyReg >> >> but that would suggest that those instructions offered a lot more choices >> than they do. In fact, Microchip would use: >> >> xorlw 0xA5 >> xorwf MyReg,w >> xorwf MyReg,f >> subwf MyReg,w >> subwf MyReg,f >> >> Operations that operate upon register files have a one-bit selection to >> indicate whether the result should go into W or back to the register file; >> a few operations like xor are available with immediate addressing, but many >> others (including, for the 16C54, addition) are not. >> >> Coding with an assembly language which mirrors the actual abilities of the >> machine is more convenient than coding for a more verbose form. While >> it might be more convenient for compiler writers to produce a more general >> form of output and then have a matrix to describe what instructions are >> actually available, humans will often have an easier time writing code which >> which better fits the machine architecture. > > > I don't necessarily disagree. And at this point I'm not sure if > you're arguing for Intel or AT&T syntax - both have the "excess > implied possibilities" problem, but in different ways. > > But my main point is that there isn't necessarily any one obvious > minimum or best assembler syntax for any given ISA. But I do agree > that a good assembler syntax will be at least somewhat specialized > towards the ISA in question. OTTH, it matters less these days, since > so much less assembler gets written. FWIW, wrt Intel vs AT&T syntax, well just do them both. Example: (Normal GAS GCC) http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html (MingW GAS version, it likes the underscores prefixing the function names... IIRC, it did not work/link without them...) http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_mingw_asm.html (MS Macro Asm version, Intel syntax) http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html ;^)
[toc] | [prev] | [next] | [standalone]
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web