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 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-12 07:33 -0800 |
| Message-ID | <dbb7e209-e5d8-4cca-8362-8f12712d4aed@googlegroups.com> |
| In reply to | #99060 |
On Monday, December 12, 2016 at 10:12:48 AM UTC-5, David Brown wrote: > On 12/12/16 12:15, Rick C. Hodgin wrote: > > robert...@yahoo.com wrote: > >> Yet there have been plenty of assemblers where the "native" > >> form was source,destination. Not least 68K, VAX and PDP-11. > >> Nor do all higher level programming languages use the > >> conventional "destination = " form. > > > > 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. > > It is common to use a symbol such as % to indicate that something is a > register. It means there is no conflict between register names and > user-defined identifiers. Users should not be using register names for their token names. And if they do, and the source is coming from a high level language like C or other, then the compiler should be smart enough to rename them. Having to use a % on register names ... it's just wrong. Sorry. > It is particularly common where you expect to > be using mainly compiled high-level language code, rather than > hand-written assembly - it saves having something like a _ prefix on all > high-level symbols. And it is useful for humans - it makes it clear > that %X is a register, while X is a symbol. Assemblers don't care one > way or the other. > > It is, of course, not universal - I have used assemblers that use such > register prefixes, and some that don't. And when I have written larger > programs in assembly (which I used to do, though never for x86) I found > I was often giving other names to the registers anyway, so prefixes made > no difference to me. > > > I truly believe Intel's assembly syntax is a towering achievement and > > triumph over AT&T's syntax. > > It is an assembler syntax - it is not a candidate for the Nobel prize in > literature! Agreed. But within the realm of assembly syntaxes, it's a "clean" break from AT&T ... in both senses of the word. > It is not a "towering achievement" - it's a relatively > simple assembler syntax that just happens to be a bit different from > another assembler syntax for the same processor. Not "a bit," but rather "notably." And not "different from" but rather "better than." Here, I'll fix it for you: ...it's a relatively simple assembler syntax that just happens to be notably better than another assembler syntax for the same processor. There. Now it's proper. > I have nothing against > you having a personal preference here - pick the style you like best. > But your exaggerations just look silly - it really is not such a big > deal. People use AT&T syntax all the time, and there are many cpus for > which the only standard syntax is much more like AT&T x86 than Intel x86. It is a huge deal. Intel obviously spent man-weeks defining and documenting their new syntax. They did it for a reason, and I doubt very seriously it came down to something like a copyright issue. But even if it did, their final product gave the world something better, and that is in line with my goals in my products. > If the differences were as extreme as you think, the AT&T syntax would > have died out as soon as Intel's version were available. And one would > have to question how the very smart people at AT&T managed to come up > with something so truly awful as their assembly syntax while the Intel > people came up with something so truly brilliant. People also spent probably man-months creating the Intel flavor for GCC. If AT&T worked just fine, why spend all that time on it? There are obviously people like me who see AT&T's syntax as incredibly obtuse and unusable to the point where they're willing to invest the time and effort and resources in creating the Intel alternative. I'm wholly on board with that mindset as I actually considered doing it a few times in the 2000s. Had I been doing more with assembly and GNU during those years, I probably would've as I was moving in that direction at that time, but was still using Microsoft tools for most things, so they already had Intel syntax. If GCC would've had Intel syntax sooner, I probably would've switched to Linux sooner. Not joking. > The reality is that it is very simple to pick an assembly syntax, and > very easy to get used to almost any assembly syntax. No. AT&T is clunky, busy, and cluttered. It's not at easy for me. If I had to read it, I'd do some global search-and-replace, like getting rid of %, and replacing all "movl " with "mov ", etc. I might even write a parser to convert it from AT&T syntax to Intel syntax. Not joking. It depends on the person, David. I recognize millions of people have no issue with AT&T syntax. I do. And it is such a high issue for me that I will not use it, and would go to great lengths to avoid using it. > > Intel's own people obviously felt AT&T's > > syntax was enough of an issue to devote time and resources to replace > > it with something new. > > True. But they would likely have needed to do something anyway, for > adding support for newer features. They could've extended AT&T's syntax. They obviously felt it wasn't desirable to do so. And it may have been for copyright reasons or some other legal constraint ... but regardless, where they went with it is far better than where AT&T was taking them (in my opinion). > > And I believe Intel's syntax is actually elegant > > (sans being in all caps). And I think Microsoft's addition of control > > logic (if blocks, while blocks, repeat blocks, etc.) was the next logical > > step, and something fabulous added to the toolset. > > There are many types of "high-level assembly constructs" around. Some > people like them, others don't. The assemblers I have used have not > supported anything like this, but it was certainly handy to have a few > types of automation such as automatically generating the optimal size of > jump instructions. The thing about Microsoft's additions are: you don't have to use them. But, when you do, they are easy, and they generally produce the exact code you would produce were you writing out every jump manually. And, the assembler gets to determine things for you, like if the jump is near and can use the condition you tested, or if it needs to jump near on the opposite condition, then issue an unconditional jump to reach the target, etc. It's just simply awesome as it removes those mechanical rigors, while still keeping you at the assembly level for the real work you need to do. > > To quote Trip's best line on Star Trek Enterprise: "I'm not the only one." > > (who thought AT&T's syntax was to be left behind as something > > better was pursued, even at the expense of new development time). > > You don't need to quote TV shows to say that there are other people who > prefer Intel x86 format to AT&T. But there are also other people who > prefer AT&T's syntax, and a good many others who really don't care and > can understand either format. It blows me away that there are people who would prefer AT&T's syntax. But, I've worked with some of those people in my career. They are unusual people in my experience. Introverted. Working in their head, often by mechanical rules like standards documents, and not in real- world practical ways. The world obviously needs both kinds of people ... I just can't relate to them, and likely in the same way you can't relate to me. It's just the way it is, Mr. Brown. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-13 01:45 -0600 |
| Message-ID | <si8v4c9r37tqbagfl0kfgudmmhttq35o4m@4ax.com> |
| In reply to | #99068 |
On Mon, 12 Dec 2016 07:33:21 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >> I have nothing against >> you having a personal preference here - pick the style you like best. >> But your exaggerations just look silly - it really is not such a big >> deal. People use AT&T syntax all the time, and there are many cpus for >> which the only standard syntax is much more like AT&T x86 than Intel x86. > >It is a huge deal. Intel obviously spent man-weeks defining and >documenting their new syntax. They did it for a reason, and I doubt >very seriously it came down to something like a copyright issue. But >even if it did, their final product gave the world something better, >and that is in line with my goals in my products. As I pointed out a week ago in this thread, it's unlikely that the AT&T syntax had any influence at all on Intel's assembler syntax for x86. Intel x86 syntax is an evolution of 8080 (Intel) syntax, which further has roots in 8008 syntax. Conversely AT&T syntax has its roots in PDP-11 syntax. The timing is such that the PDP-11 itself would have shipped (1970) only a short time before Intel started working on the 8008 (the chip shipped in 1972, Intel presumably started working on it before then), and Intel was already working on the 8080 in 1972 (shipped in 1974). And while PDP-11 assembler syntax eventually grew into AT&T syntax, it was certainly nothing you'd use as a portable model at the time. AT&T x86 syntax exists because *nix for x86 needed an assembler, and presumably the easiest way to do that was to hack up the "standard" assembler for *nix.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-12 16:49 +0000 |
| Message-ID | <87zik1ozxm.fsf@bsb.me.uk> |
| In reply to | #99060 |
David Brown <david.brown@hesbynett.no> writes: > On 12/12/16 12:15, Rick C. Hodgin wrote: <snip> >> I truly believe Intel's assembly syntax is a towering achievement and >> triumph over AT&T's syntax. > > It is an assembler syntax - it is not a candidate for the Nobel prize in > literature! If Swift were alive today, he wouldn't have to write about wars over which end of the egg to open in order to illustrate the absurd passions about trivia that we are capable of. He'd be spoilt for choice. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-12 10:25 -0800 |
| Message-ID | <b84d6bee-86dd-446f-b350-3cb137b53a9a@googlegroups.com> |
| In reply to | #99077 |
On Monday, December 12, 2016 at 11:49:32 AM UTC-5, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > > > On 12/12/16 12:15, Rick C. Hodgin wrote: > <snip> > >> I truly believe Intel's assembly syntax is a towering achievement and > >> triumph over AT&T's syntax. > > > > It is an assembler syntax - it is not a candidate for the Nobel prize in > > literature! > > If Swift were alive today, he wouldn't have to write about wars over > which end of the egg to open in order to illustrate the absurd passions > about trivia that we are capable of. He'd be spoilt for choice. Assuming you drive, why don't you drive another model of car, Ben? Or if you bicycle, why that type of bicycle? Or if you walk, why do you buy that type of shoe? People have preferences. Some of them are non-trivial. Won't buy an SUV because it's too tall to get into. Won't buy a two-door car because they have kids, etc. In my case, and in many other people's cases, we won't use AT&T syntax because it's very visually cluttered (compared to Intel's). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-13 10:50 +0100 |
| Message-ID | <o2og6u$8vv$1@dont-email.me> |
| In reply to | #99102 |
On 12/12/16 19:25, Rick C. Hodgin wrote: > On Monday, December 12, 2016 at 11:49:32 AM UTC-5, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 12/12/16 12:15, Rick C. Hodgin wrote: >> <snip> >>>> I truly believe Intel's assembly syntax is a towering achievement and >>>> triumph over AT&T's syntax. >>> >>> It is an assembler syntax - it is not a candidate for the Nobel prize in >>> literature! >> >> If Swift were alive today, he wouldn't have to write about wars over >> which end of the egg to open in order to illustrate the absurd passions >> about trivia that we are capable of. He'd be spoilt for choice. > > Assuming you drive, why don't you drive another model of car, Ben? Or > if you bicycle, why that type of bicycle? Or if you walk, why do you > buy that type of shoe? People have preferences. But while some people might say their Toyota is the best car they have ever driven, I doubt you would find anyone who will say "if I had to drive a Ford rather than Toyota, I'd give up my job as a taxi driver and move to a village in the Andes where there are no roads". No one finds it odd that you prefer Intel syntax to AT&T for x86 assembly. What is odd is the absurd passion about what is basically a trivial matter (as Ben aptly put it). > > People have preferences. Some of them are non-trivial. Won't buy an > SUV because it's too tall to get into. Won't buy a two-door car > because they have kids, etc. No, these are practical and reasonable choices. So is refusing to use m68k assembly when you are programming a PPC target. What you are talking about is more akin to the car controls being arranged in an unfamiliar fashion - perhaps a proper gearstick between the front seats rather than a little twig on the steering wheel. It is /nothing/ that you cannot quickly get used to, perhaps with the use of assembler macros for customisation. > > In my case, and in many other people's cases, we won't use AT&T syntax > because it's very visually cluttered (compared to Intel's). > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 04:02 -0800 |
| Message-ID | <de87a798-ce33-4caf-b71d-e564992933ba@googlegroups.com> |
| In reply to | #99177 |
FWIW, I always have been, and remain literally amazed, that anyone who's seen AT&T syntax, and Intel's syntax, would choose AT&T's over Intel's. I honestly believe it indicates something not right in that person's thinking. It's more cut and dry than anything else I've seen in software language choices of similar abilities. I remember the first time I saw AT&T syntax in the 1990s. I stood there staring at it thinking, "No way!" I could not believe it was real. The same response the next half dozen times I saw it. It actually put animosity between myself and GNU, and literally influenced my decision to not migrate to Linux, or GNU tools. I used to code almost exclusively in assembly in the 1990s. It was my everyday language. And AT&T syntax was horrid to my eyes and mind even back then. It remains patently so to this day, to the point where if I were forced to code in it ... I would not. I would leave that job and find another. And if there weren't any, I would switch professions. I almost had to leave my job recently for a business decision they had made that I disagreed with. But, they changed their policy toward it and I remained. Some things are important to people. Other things are necessities for people. I categorize x86 assembler syntax into a necessity because of how cluttered AT&T syntax is, while recognizing I don't need to be writing software. I could be a welder and be happy. I actually love welding. In any event ... it amazes me people would choose AT&T syntax over Intel's. Literally amazes me. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 13:14 +0000 |
| Message-ID | <o2os4t$q4a$1@dont-email.me> |
| In reply to | #99182 |
On 13/12/2016 12:02, Rick C. Hodgin wrote: > In any event ... it amazes me people would choose AT&T syntax > over Intel's. Literally amazes me. If it's that big a deal, why not write a syntax wrapper around it? Or have your smart editor deal it? Silly to change jobs over something that could be resolved in a long weekend. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 05:57 -0800 |
| Message-ID | <afbc23a4-853a-492b-841f-2ec441a769e6@googlegroups.com> |
| In reply to | #99186 |
On Tuesday, December 13, 2016 at 8:14:30 AM UTC-5, Bart wrote: > On 13/12/2016 12:02, Rick C. Hodgin wrote: > > > In any event ... it amazes me people would choose AT&T syntax > > over Intel's. Literally amazes me. > > If it's that big a deal, why not write a syntax wrapper around it? Or > have your smart editor deal it? > > Silly to change jobs over something that could be resolved in a long > weekend. I might do that. It's only a hypothetical situation right now. But, I do know I would not continue to work as a developer if I was forced to use AT&T syntax. But you're probably right ... there would be alternatives. I actually seriously considered writing an AT&T to Intel syntax parser back in the day if I did have to use GCC. But, it was never an issue. I never really used GCC until the late 2000s, and really 2009 or 2010 with any significance. At that time, some developers had already added Intel support to GCC and GDB. I was oh so glad to find that. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-13 14:32 +0100 |
| Message-ID | <o2ot6d$u16$1@dont-email.me> |
| In reply to | #99182 |
On 13/12/16 13:02, Rick C. Hodgin wrote:
> FWIW, I always have been, and remain literally amazed, that anyone
> who's seen AT&T syntax, and Intel's syntax, would choose AT&T's
> over Intel's. I honestly believe it indicates something not right in
> that person's thinking.
I haven't written much x86, but I read a bit of it sometimes. I usually
have a godbolt.org window open for various experimentations of
compilation, and for a snippet I just compiled the generated code is:
f1:
xor eax, eax
test BYTE PTR d[rip], 16
sete al
mov DWORD PTR d[rip], eax
ret
f3:
mov eax, DWORD PTR d[rip]
shr eax, 4
xor eax, 1
and eax, 1
mov DWORD PTR d[rip], eax
ret
or
f1:
xorl %eax, %eax
testb $16, d(%rip)
sete %al
movl %eax, d(%rip)
ret
f3:
movl d(%rip), %eax
shrl $4, %eax
xorl $1, %eax
andl $1, %eax
movl %eax, d(%rip)
ret
What are the differences here? I see a few:
1. Intel has dst, src ordering while AT&T has src, dst ordering.
Neither makes any difference to me - if you have worked with a few
assembly languages, you know that both orders work fine once you know
which one you are using.
2. Intel has no prefix on registers, AT&T has %. That would make Intel
syntax a little nicer to write, but AT&T has less risk of mixups when
reading - it is clear that "d" is an identifier, not a register.
3. Intel has no prefix on immediate values, AT&T has $. I must admit
that I can't see any advantage of a prefix on a numeric immediate value,
at least not in this snippet. But I don't see a big issue.
4. Intel uses extra words like "DWORD PTR" to indicate lengths, while
AT&T puts the length indication in the mnemonic. I prefer seeing it in
the mnemonic as being less verbose. But I would prefer the style used
by m68k assembly, which would be "mov.l" rather than "movl". So in my
book, neither format is ideal here.
5. Intel has [], AT&T has (). So what?
I gather that more complex addressing modes are a big ugly in AT&T
compared to Intel - this example doesn't use such addressing modes.
This has been described as Intel's syntax looking like an expression,
and AT&T syntax looking like a function call.
If I were to have to write x86 assembly, I would probably choose Intel
syntax if the main platform was Windows, and AT&T syntax if the main
platform was *nix. I don't see enough difference or difficulty with the
two formats to be a decider, so I would pick the common choice for the
platform. For a completely free choice, I would probably side with
Intel - but the difference is not enough for me to bother with the
"-masm=intel" flag when looked at generated code on godbolt.org.
>
> It's more cut and dry than anything else I've seen in software language
> choices of similar abilities.
>
> I remember the first time I saw AT&T syntax in the 1990s. I stood
> there staring at it thinking, "No way!" I could not believe it was real.
> The same response the next half dozen times I saw it. It actually put
> animosity between myself and GNU, and literally influenced my decision
> to not migrate to Linux, or GNU tools.
>
> I used to code almost exclusively in assembly in the 1990s. It was my
> everyday language. And AT&T syntax was horrid to my eyes and mind
> even back then. It remains patently so to this day, to the point where
> if I were forced to code in it ... I would not. I would leave that job
> and find another. And if there weren't any, I would switch professions.
There is no other way to describe that than petty and unprofessional.
>
> I almost had to leave my job recently for a business decision they
> had made that I disagreed with. But, they changed their policy
> toward it and I remained.
There may certainly be business decisions that you cannot in good
conscience accept, and there may also be business decisions that change
the scope of the job or the way of working to such an extent that it is
no longer the job you want. But this is not one of them. There are
very few people who are employed as "x86 assembly programmers" - I doubt
if there are /any/ who are employed as "Intel syntax x86 assembly
programmers".
>
> Some things are important to people. Other things are necessities
> for people. I categorize x86 assembler syntax into a necessity because
> of how cluttered AT&T syntax is, while recognizing I don't need to be
> writing software. I could be a welder and be happy. I actually love
> welding.
>
> In any event ... it amazes me people would choose AT&T syntax
> over Intel's. Literally amazes me.
>
It amazes me how amazed you are over something so trivial.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 05:58 -0800 |
| Message-ID | <43feb842-12bd-454d-a26a-661a06b755fd@googlegroups.com> |
| In reply to | #99192 |
On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: > [snip] It's not an issue worth arguing or debating. I merely state my per- sonal take on it. I recognize other people see things differently. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 06:21 -0800 |
| Message-ID | <a7b86fe3-e5de-4fe2-aebd-6df1782d7c7a@googlegroups.com> |
| In reply to | #99192 |
On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote:
> f1:
> xor eax, eax
> test BYTE PTR d[rip], 16
> sete al
> mov DWORD PTR d[rip], eax
> ret
> f3:
> mov eax, DWORD PTR d[rip]
> shr eax, 4
> xor eax, 1
> and eax, 1
> mov DWORD PTR d[rip], eax
> ret
This syntax is a little weird. I also don't know what d[rip] means.
I would re-write it as:
f1:
xor eax,eax
test byte ptr d[rip],16
sete al
mov d[rip],eax
ret
f3:
mov eax,d[rip]
shr eax,4
xor eax,1
and eax,1
mov d[rip],eax
ret
You also only /need/ overrides like DWORD PTR when the size of the
target isn't known, though it is common Intel syntax to include
them. I plan to phase them out with my assembler (LSA), and I also
plan to adopt AT&T's use of the trailing character to indicate the
size, rather than injecting "dword ptr" as I find that too long.
I won't use "l" or "s" though, but will use ".32" and ".16" and
other such, to indicate the bit-size.
I still don't know what d[rip] is. I've never seen that syntax
before. But, I haven't done much AMD64 assembly development.
Only here:
https://github.com/RickCHodgin/libsf/blob/master/source/vjr/source/dllfuncs/dll_dispatch_64.asm
This allowed me to use Visual FreePro, Jr. to dispatch code into user-
defined 64-bit DLLs.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-13 14:41 +0000 |
| Message-ID | <o2p18l$d2o$1@dont-email.me> |
| In reply to | #99204 |
On 13/12/2016 14:21, Rick C. Hodgin wrote:
> On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote:
>> f1:
>> xor eax, eax
>> test BYTE PTR d[rip], 16
> I still don't know what d[rip] is. I've never seen that syntax
> before.
You should try NASM which treats this stuff more sensibly.
'd' is probably a displacement. NASM would have that as:
[rip+d]
word [rip+d] ; etc when size is not obvious
Maybe they'd intended it to look like array syntax, where d is the
address of an array (and rip is presumably not the instruction pointer).
But I think that's a mistake; this is not a HLL.
And where d is indirect so its address is in r0, and the index is in r1,
would it allow: r0[r1]? NASM would require [r1*2+r0] or [r0+ri*2].
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 06:47 -0800 |
| Message-ID | <12253e36-d451-405c-b266-90387a48db0e@googlegroups.com> |
| In reply to | #99205 |
On Tuesday, December 13, 2016 at 9:41:51 AM UTC-5, Bart wrote: > On 13/12/2016 14:21, Rick C. Hodgin wrote: > > On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: > >> f1: > >> xor eax, eax > >> test BYTE PTR d[rip], 16 > > > I still don't know what d[rip] is. I've never seen that syntax > > before. > > You should try NASM which treats this stuff more sensibly. > > 'd' is probably a displacement. NASM would have that as: > > [rip+d] > word [rip+d] ; etc when size is not obvious > > Maybe they'd intended it to look like array syntax, where d is the > address of an array (and rip is presumably not the instruction pointer). > But I think that's a mistake; this is not a HLL. Since posting originally I googled it and it seems to be RIP-relative addressing. I knew AMD64 had relative addressing, but I thought it was only for branch targets, and not data access. So, I learned something new today. :-) > And where d is indirect so its address is in r0, and the index is in r1, > would it allow: r0[r1]? NASM would require [r1*2+r0] or [r0+ri*2]. It looks like the assembler would keep track of where "d" is in memory, and then insert the correct offset as needed for each line where it's referenced, rather than using an RBP-relative fixed location, the RIP- relative forms float in value, but remain fixed in memory. Not sure I see the advantage in doing that, except that you possibly gain back one register for general purpose use, but that base pointer register is still hard-wired to be associated with the stack selector, so it's not useful in accessing general purpose memory without the data selector override, meaning it's only natively useful for register- to-register storage. Still useful though. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-13 16:24 +0100 |
| Message-ID | <o2p3ol$m97$1@dont-email.me> |
| In reply to | #99206 |
On 13/12/16 15:47, Rick C. Hodgin wrote: > On Tuesday, December 13, 2016 at 9:41:51 AM UTC-5, Bart wrote: >> On 13/12/2016 14:21, Rick C. Hodgin wrote: >>> On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: >>>> f1: >>>> xor eax, eax >>>> test BYTE PTR d[rip], 16 >> >>> I still don't know what d[rip] is. I've never seen that syntax >>> before. "d" is just an identifier (an "int" in the original C code). d[rip] therefore means access d by offset relative to the instruction pointer, I assume. (As I said, this is generated assembly code, not something I wrote directly.) >> >> You should try NASM which treats this stuff more sensibly. >> >> 'd' is probably a displacement. NASM would have that as: >> >> [rip+d] >> word [rip+d] ; etc when size is not obvious >> >> Maybe they'd intended it to look like array syntax, where d is the >> address of an array (and rip is presumably not the instruction pointer). >> But I think that's a mistake; this is not a HLL. > > Since posting originally I googled it and it seems to be RIP-relative > addressing. I knew AMD64 had relative addressing, but I thought it > was only for branch targets, and not data access. So, I learned > something new today. :-) > >> And where d is indirect so its address is in r0, and the index is in r1, >> would it allow: r0[r1]? NASM would require [r1*2+r0] or [r0+ri*2]. > > It looks like the assembler would keep track of where "d" is in memory, > and then insert the correct offset as needed for each line where it's > referenced, rather than using an RBP-relative fixed location, the RIP- > relative forms float in value, but remain fixed in memory. > > Not sure I see the advantage in doing that, except that you possibly > gain back one register for general purpose use, but that base pointer > register is still hard-wired to be associated with the stack selector, > so it's not useful in accessing general purpose memory without the > data selector override, meaning it's only natively useful for register- > to-register storage. Still useful though. > The x86 architecture is desperately register-poor, even in amd64 mode. You would not want to use a register as a frame pointer unless it was actually needed.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-13 07:30 -0800 |
| Message-ID | <2e228b9d-045f-4625-9879-87cf41662af7@googlegroups.com> |
| In reply to | #99212 |
On Tuesday, December 13, 2016 at 10:24:31 AM UTC-5, David Brown wrote:
> The x86 architecture is desperately register-poor, even in amd64 mode.
> You would not want to use a register as a frame pointer unless it was
> actually needed.
[Not a response directly to David, but more an in-general post]
That's why I added window register extension (WEX) to my CPU design:
https://github.com/RickCHodgin/libsf/blob/master/arxoda/arxoda-documentation/images/wex_register_mapping.png
Every instruction that uses an ax,bx,cx,dx,si,di,bp encoding can be
re-directed to a different register based on the wex mapping. It
even allows direct manipulation of floating point and vector regs
(in up to 40-bit halves) using the regular integer instructions.
Floating point and vector instructions allow full manipulation of
their 80-bit size.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-14 14:12 -0600 |
| Message-ID | <pk935cdarjbeftnejmceotakn7o2fcqlfh@4ax.com> |
| In reply to | #99212 |
On Tue, 13 Dec 2016 16:24:23 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 13/12/16 15:47, Rick C. Hodgin wrote: >> On Tuesday, December 13, 2016 at 9:41:51 AM UTC-5, Bart wrote: >>> On 13/12/2016 14:21, Rick C. Hodgin wrote: >>>> On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: >>>>> f1: >>>>> xor eax, eax >>>>> test BYTE PTR d[rip], 16 >>> >>>> I still don't know what d[rip] is. I've never seen that syntax >>>> before. > >"d" is just an identifier (an "int" in the original C code). > >d[rip] therefore means access d by offset relative to the instruction >pointer, I assume. > >(As I said, this is generated assembly code, not something I wrote >directly.) I'm a little baffled as to why Rick is not recognizing this, but in MASM/Intel that sort of thing is often written as "[label+register]" instead of "label[register]". In most cases the two are identical, and either form is allowed. And ignoring that IP-relative addressing is an x86-64-only thing (or why one might want to use that).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-14 12:21 -0800 |
| Message-ID | <785d1065-d0b7-48a4-9329-55afeecf4afc@googlegroups.com> |
| In reply to | #99397 |
On Wednesday, December 14, 2016 at 3:11:46 PM UTC-5, robert...@yahoo.com wrote: > On Tue, 13 Dec 2016 16:24:23 +0100, David Brown > <david.brown@hesbynett.no> wrote: > > >On 13/12/16 15:47, Rick C. Hodgin wrote: > >> On Tuesday, December 13, 2016 at 9:41:51 AM UTC-5, Bart wrote: > >>> On 13/12/2016 14:21, Rick C. Hodgin wrote: > >>>> On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: > >>>>> f1: > >>>>> xor eax, eax > >>>>> test BYTE PTR d[rip], 16 > >>> > >>>> I still don't know what d[rip] is. I've never seen that syntax > >>>> before. > > > >"d" is just an identifier (an "int" in the original C code). > > > >d[rip] therefore means access d by offset relative to the instruction > >pointer, I assume. > > > >(As I said, this is generated assembly code, not something I wrote > >directly.) > > > I'm a little baffled as to why Rick is not recognizing this, but in > MASM/Intel that sort of thing is often written as "[label+register]" > instead of "label[register]". In most cases the two are identical, > and either form is allowed. And ignoring that IP-relative addressing > is an x86-64-only thing (or why one might want to use that). It was the RIP-relative addressing. I was unaware it was also for data. I just though the RIP-relative addressing was for displacement relative to the instruction pointer for a target as by branch or call. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-14 15:02 -0600 |
| Message-ID | <vnc35chchpm00nbp74tr0ie8ljkr3g3nie@4ax.com> |
| In reply to | #99403 |
On Wed, 14 Dec 2016 12:21:47 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >On Wednesday, December 14, 2016 at 3:11:46 PM UTC-5, robert...@yahoo.com wrote: >> On Tue, 13 Dec 2016 16:24:23 +0100, David Brown >> <david.brown@hesbynett.no> wrote: >> >> >On 13/12/16 15:47, Rick C. Hodgin wrote: >> >> On Tuesday, December 13, 2016 at 9:41:51 AM UTC-5, Bart wrote: >> >>> On 13/12/2016 14:21, Rick C. Hodgin wrote: >> >>>> On Tuesday, December 13, 2016 at 8:32:23 AM UTC-5, David Brown wrote: >> >>>>> f1: >> >>>>> xor eax, eax >> >>>>> test BYTE PTR d[rip], 16 >> >>> >> >>>> I still don't know what d[rip] is. I've never seen that syntax >> >>>> before. >> > >> >"d" is just an identifier (an "int" in the original C code). >> > >> >d[rip] therefore means access d by offset relative to the instruction >> >pointer, I assume. >> > >> >(As I said, this is generated assembly code, not something I wrote >> >directly.) >> >> >> I'm a little baffled as to why Rick is not recognizing this, but in >> MASM/Intel that sort of thing is often written as "[label+register]" >> instead of "label[register]". In most cases the two are identical, >> and either form is allowed. And ignoring that IP-relative addressing >> is an x86-64-only thing (or why one might want to use that). > >It was the RIP-relative addressing. I was unaware it was also for >data. I just though the RIP-relative addressing was for displacement >relative to the instruction pointer for a target as by branch or call. RIP for data addresses was added in x86-64. IP relative addressing for branches has been there since the 8086.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-14 13:19 -0800 |
| Message-ID | <81a76c81-1828-4497-b487-22f724a8c31c@googlegroups.com> |
| In reply to | #99414 |
On Wednesday, December 14, 2016 at 4:01:41 PM UTC-5, robert...@yahoo.com wrote: > On Wed, 14 Dec 2016 12:21:47 -0800 (PST), "Rick C. Hodgin" > >It was the RIP-relative addressing. I was unaware it was also for > >data. I just though the RIP-relative addressing was for displacement > >relative to the instruction pointer for a target as by branch or call. > > RIP for data addresses was added in x86-64. IP relative addressing > for branches has been there since the 8086. I knew that. But somehow I didn't put it together. I don't remember reading that it was relative addressing for data, so I just assumed it was for branch targets. But of course you're right ... it's been in there. Don't know. I just never made the connection. :-) A bit of trivia: AMD released their x86-64 specs on my birthday in 2000. :-) Always thought that was neat. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2016-12-13 16:46 +0000 |
| Subject | Petty and unprofessional (Was: Default values in #define) |
| Message-ID | <o2p8km$pje$1@news.xmission.com> |
| In reply to | #99192 |
In article <o2ot6d$u16$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >> I used to code almost exclusively in assembly in the 1990s. It was my >> everyday language. And AT&T syntax was horrid to my eyes and mind >> even back then. It remains patently so to this day, to the point where >> if I were forced to code in it ... I would not. I would leave that job >> and find another. And if there weren't any, I would switch professions. > >There is no other way to describe that than petty and unprofessional. Disagree. I took it as Rick saying, for all the world to see, what a great big stud he is and how he could get another (programming) job at the drop of a hat. A luxury many people do not have. I actually like Rick's idea of dropping programming altogether and becoming a welder. I think both professions would benefit. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/EternalFlame
[toc] | [prev] | [next] | [standalone]
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web