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 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-09 15:52 -0800 |
| Message-ID | <o2fg0r$d8h$2@dont-email.me> |
| In reply to | #98624 |
On 12/9/2016 3:49 PM, Chris M. Thomasson wrote: > 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 > Oh and by the way, if you look at the code and notice an XCHG instruction without a explicit LOCK prefix, well, that particular instruction implies it already. ;^)
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-09 00:52 -0800 |
| Message-ID | <bc38a8a3-fe45-4d6a-a631-a90471cd68a4@googlegroups.com> |
| In reply to | #98234 |
I think that in assembly 'Type' of one data has to be just the number of bit of that data type. So data type has to be 8bit, 16bit 32bit etc (if it is signed or unsigned is the instruction that include it)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-10 03:19 -0600 |
| Message-ID | <cmhn4c1hr95vf5jatfbla4pvpiebmd2qlv@4ax.com> |
| In reply to | #98461 |
On Fri, 9 Dec 2016 00:52:03 -0800 (PST), asetofsymbols@gmail.com wrote: >I think that in assembly 'Type' of one data has to be just the number of bit of that data type. So data type has to be 8bit, 16bit >32bit etc (if it is signed or unsigned is the instruction that include it) I don't see why it would have to be limited to just the size. While Intel syntax does not do so, you could have different memory types for floats and integer values, and generate an error attempting to reference a float with a "mov" or an integer with an "fld" (at least unless you used a "cast"). While I'm not particularly familiar with the product, I believe Randy Hyde's HLA does such things.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-07 04:43 -0800 |
| Message-ID | <20e82ec3-1eb1-4bac-8e78-6bcf1e3d870a@googlegroups.com> |
| In reply to | #97973 |
David Brown <david...@hesbynett.no> wrote: >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? I believe that is obvious. Intel's syntax is cleaner, less verbose, fewer repeating characters, and generally far more pleasing to the eye. AT&T's syntax is like looking at wet cow dung. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 14:18 +0100 |
| Message-ID | <o2bmg9$oae$1@dont-email.me> |
| In reply to | #98253 |
On 07/12/16 13:43, Rick C. Hodgin wrote: > David Brown <david...@hesbynett.no> wrote: >> 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? > > I believe that is obvious. Intel's syntax is cleaner, less verbose, > fewer repeating characters, and generally far more pleasing to the eye. > "Clean" is in the eye of the beholder. I have used assembly languages that are "op src, dest" and some that are "op dest, src". I have used some that specify widths as part of the opcode, part of the register, or additional arguments. You get used to anything - well, almost anything. The Microchip PIC assembly is so hideous that you need to define assembler macros in order to make anything legible. > AT&T's syntax is like looking at wet cow dung. > We are talking about x86 assembly here! The whole architecture is gruesome (in the eye of this beholder) - there is no way to make a nice assembly syntax for it. But if you are going to work with these devices in assembly you need to be familiar with reading both syntaxes, while probably have a strong /personal/ preference for which one you write. It is all just about preference and taste. Except for comments about Microchip PIC assembly, of course - those are undeniable fact :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-08 07:22 -0800 |
| Message-ID | <b72f8d5d-11cf-4c2c-a731-f96da112118c@googlegroups.com> |
| In reply to | #98352 |
David Brown wrote: > We are talking about x86 assembly here! The whole architecture > is gruesome (in the eye of this beholder) - there is no way to > make a nice assembly syntax for it. Intel did. And I disagree that x86 is gruesome when discussing 80386 and later. It's quite elegant given its limited register set. You can rename eax,ebx,ecx,edx,esi,edi,ebp as rN names and it's quite similar to other architectures, with some operations requiring certain register targets, with others being more generic. Selectors are used instead of segments, with a flat 4GB address space being available. The only un-elegant things about x86 are many kernel-only things. But most developers will never see that. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 08:00 -0800 |
| Message-ID | <b896eb4c-9d20-4c97-965f-168f5eacda4b@googlegroups.com> |
| In reply to | #98352 |
On Thursday, December 8, 2016 at 7:18:24 AM UTC-6, David Brown wrote:
> "Clean" is in the eye of the beholder. I have used assembly languages
> that are "op src, dest" and some that are "op dest, src". I have used
> some that specify widths as part of the opcode, part of the register, or
> additional arguments. You get used to anything - well, almost anything.
> The Microchip PIC assembly is so hideous that you need to define
> assembler macros in order to make anything legible.
I don't mind the PIC assembly format generally aside from its radix
notation, and the lack of a nice way of specifying a port+bit combination.
Also, when writing conditional skip instructions I always add an extra
space to the succeeding line, something I would think Microchip should
recommend, so e.g. code to copy one bit to another if a momentary
disturbance would be acceptable would be:
bcf destreg,destbit
btfsc srcreg,srcbit
bsf destreg,destbit
Provided that code is written using ,f and ,d rather than ,1 and ,0 what
else don't you like about the syntax?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-08 22:14 +0100 |
| Message-ID | <o2cicm$ute$1@dont-email.me> |
| In reply to | #98379 |
On 08/12/16 17:00, supercat@casperkitty.com wrote: > On Thursday, December 8, 2016 at 7:18:24 AM UTC-6, David Brown wrote: >> "Clean" is in the eye of the beholder. I have used assembly languages >> that are "op src, dest" and some that are "op dest, src". I have used >> some that specify widths as part of the opcode, part of the register, or >> additional arguments. You get used to anything - well, almost anything. >> The Microchip PIC assembly is so hideous that you need to define >> assembler macros in order to make anything legible. > > I don't mind the PIC assembly format generally aside from its radix > notation, and the lack of a nice way of specifying a port+bit combination. > Also, when writing conditional skip instructions I always add an extra > space to the succeeding line, something I would think Microchip should > recommend, so e.g. code to copy one bit to another if a momentary > disturbance would be acceptable would be: > > bcf destreg,destbit > btfsc srcreg,srcbit > bsf destreg,destbit > > Provided that code is written using ,f and ,d rather than ,1 and ,0 what > else don't you like about the syntax? > Well, the mnemonic "btfsc" for a start. "Bit Test File register and Skip if Clear"? Long, long ago when I had to use a PIC, I used macros to write the above as: BitClear destreg, destbit IfBit srcreg, srcbit BitSet destreg, destbit I also had macros for making port+bit combinations. I seem to also remember the assembler missing a good deal of the directives needed for defining data, and tracking the current data and code page could easily be a mess if you wanted something reasonably efficient and reasonably automatic. But to be fair on the assembly, much of my dislike of the assembly was perhaps merely dislike of the cpu itself. And once I had made the effort on a good set of macros, it was reasonable enough. (Microchip gets full marks for making very solid and robust microcontrollers, and for making them available for decades - but the cpu is /not/ pleasant.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 13:44 -0800 |
| Message-ID | <4cca4b09-ff38-4cce-8d72-05fc78a372b2@googlegroups.com> |
| In reply to | #98409 |
On Thursday, December 8, 2016 at 3:14:22 PM UTC-6, David Brown wrote: > (Microchip gets full marks for making very solid and robust > microcontrollers, and for making them available for decades - but the > cpu is /not/ pleasant.) I actually like the low-end and mid-range designs, though I find it curious that a problem which some General Instruments PICs fixed in the 1970s (the lack of a register to access the state of a port latch) was not fixed in any Microchip PICs prior to the 18xx series. The register banking is something of a pain, but a lot of things on that architecture work out much more nicely than on the Intel 8051, CDP1802, or even the Z80 for that matter.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-09 16:07 -0800 |
| Message-ID | <o2fgti$g8r$1@dont-email.me> |
| In reply to | #98253 |
On 12/7/2016 4:43 AM, Rick C. Hodgin wrote: > David Brown <david...@hesbynett.no> wrote: >> 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? > > I believe that is obvious. Intel's syntax is cleaner, less verbose, > fewer repeating characters, and generally far more pleasing to the eye. > > AT&T's syntax is like looking at wet cow dung. Yikes! Humm, you probably should not look at this: http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm Your eyes might start bleeding... ;^) I like both AT&T and Intel syntax. I can use them both, and that is okay with me.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-09 17:00 -0800 |
| Message-ID | <719e1515-f600-4a1c-ba17-8062de544f34@googlegroups.com> |
| In reply to | #98630 |
Chris M. Thomasson wrote: > Yikes! Humm, you probably should not look at this: > > http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm > > Your eyes might start bleeding... > > ;^) > > I like both AT&T and Intel syntax. I can use them both, and that is okay > with me If forced to use AT&T syntax, I would switch professions. Not joking. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-09 17:46 -0800 |
| Message-ID | <o2fmn4$v6e$1@dont-email.me> |
| In reply to | #98640 |
On 12/9/2016 5:00 PM, Rick C. Hodgin wrote: > Chris M. Thomasson wrote: >> Yikes! Humm, you probably should not look at this: >> >> http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm >> >> Your eyes might start bleeding... >> >> ;^) > >> >> I like both AT&T and Intel syntax. I can use them both, and that is okay >> with me > > If forced to use AT&T syntax, I would switch professions. Not joking. Wow!
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-10 08:37 -0800 |
| Message-ID | <d3c3653e-7345-47a6-92e1-efe66b973c75@googlegroups.com> |
| In reply to | #98644 |
On Friday, December 9, 2016 at 8:46:36 PM UTC-5, Chris M. Thomasson wrote:
> On 12/9/2016 5:00 PM, Rick C. Hodgin wrote:
> > Chris M. Thomasson wrote:
> >> Yikes! Humm, you probably should not look at this:
> >>
> >> http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm
> >>
> >> Your eyes might start bleeding...
> >>
> >> ;^)
> >
> >>
> >> I like both AT&T and Intel syntax. I can use them both, and that is okay
> >> with me
> >
> > If forced to use AT&T syntax, I would switch professions. Not joking.
>
> Wow!
I did a brief impromptu poll in my family, with my non-programmer wife
who doesn't have any interest in programming, and my 12-year old son
who is very much like his mother, and they both agreed that the Intel
syntax is preferable.
Here are some of their reasons:
1) Like the brackets more than parenthesis.
2) The % symbol everywhere is "just weird."
3) The Intel syntax aligns things in columns more easily with
the variable-length number being after the left-side, which
helps it be seen more easily, as in this page:
http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html
versus this page:
http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html
4) The AT&T syntax looks "generally busy."
5) The Intel syntax is nicely spaced, and "simplified."
Could not agree more. And, I gave them no prompting in finding this
information out. I sent them this email unannounced and unspoken to
regarding the poll:
-----[ Begin ]-----
Subject: Opinion poll -- Which is easier to read
From a straight-forward easiness of reading, which one is easier to read?
#1 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html
Or #2 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html
Please choose #1 or #2.
-----[ End ]-----
I'd be curious what your non-programmer friends/family think with that
poll. And also what your programmer friends/family think. :-)
Seriously, I will never use AT&T syntax. It breaks my heart that it
even exists.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-10 09:42 -0800 |
| Message-ID | <9544b32b-5e5b-41ad-9779-a9d69c87a7ee@googlegroups.com> |
| In reply to | #98712 |
On Saturday, December 10, 2016 at 10:37:16 AM UTC-6, Rick C. Hodgin wrote:
> I did a brief impromptu poll in my family, with my non-programmer wife
> who doesn't have any interest in programming, and my 12-year old son
> who is very much like his mother, and they both agreed that the Intel
> syntax is preferable.
>
> Here are some of their reasons:
>
> 1) Like the brackets more than parenthesis.
> 2) The % symbol everywhere is "just weird."
> 3) The Intel syntax aligns things in columns more easily with
> the variable-length number being after the left-side, which
> helps it be seen more easily, as in this page:
Borland's assembler supported three modes:
1. The default mode worked in a fashion consistent with Intel MASM 5.1
documentation.
2. QUIRKS mode would make the assembler work in a fashion consistent
with the way MASM 5.1 actually worked.
3. IDEAL mode made it work in a way which was unique to Borland's
assembler, but allowed faster assembly and IMHO made more sense.
I don't have any samples of IDEAL mode code available for comparison, but
it would be interesting to see what various programmers would think about
it. Perhaps the most notable thing about it is that an instruction like:
mov ax,someLabel
would always be processed as a move-immediate regardless of how the label
was defined; code wanting to load memory from the address given by someLabel
would use the syntax:
mov ax,[someLabel]
again regardless of how the label was defined.
To my mind, the two styles of assembler convey different philosophies of
how tools to generate machine code should behave, and I think that same
distinction is sometimes apparent with C compilers. Sometimes one wants
something that acts as much as possible like a high-level language, but
at other times one knows what instructions one wants the machine to
generate and simply wants a way of writing source code that will make
that happen.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-10 10:05 -0800 |
| Message-ID | <1436e57f-54e8-4ab3-80cc-36dd6c991079@googlegroups.com> |
| In reply to | #98720 |
On Saturday, December 10, 2016 at 12:43:00 PM UTC-5, supe...@casperkitty.com wrote:
> On Saturday, December 10, 2016 at 10:37:16 AM UTC-6, Rick C. Hodgin wrote:
> > I did a brief impromptu poll in my family, with my non-programmer wife
> > who doesn't have any interest in programming, and my 12-year old son
> > who is very much like his mother, and they both agreed that the Intel
> > syntax is preferable.
> >
> > Here are some of their reasons:
> >
> > 1) Like the brackets more than parenthesis.
> > 2) The % symbol everywhere is "just weird."
> > 3) The Intel syntax aligns things in columns more easily with
> > the variable-length number being after the left-side, which
> > helps it be seen more easily, as in this page:
>
> Borland's assembler supported three modes:
>
> 1. The default mode worked in a fashion consistent with Intel MASM 5.1
> documentation.
>
> 2. QUIRKS mode would make the assembler work in a fashion consistent
> with the way MASM 5.1 actually worked.
>
> 3. IDEAL mode made it work in a way which was unique to Borland's
> assembler, but allowed faster assembly and IMHO made more sense.
>
> I don't have any samples of IDEAL mode code available for comparison, but
> it would be interesting to see what various programmers would think about
> it. Perhaps the most notable thing about it is that an instruction like:
>
> mov ax,someLabel
>
> would always be processed as a move-immediate regardless of how the label
> was defined; code wanting to load memory from the address given by someLabel
> would use the syntax:
>
> mov ax,[someLabel]
>
> again regardless of how the label was defined.
>
> To my mind, the two styles of assembler convey different philosophies of
> how tools to generate machine code should behave, and I think that same
> distinction is sometimes apparent with C compilers. Sometimes one wants
> something that acts as much as possible like a high-level language, but
> at other times one knows what instructions one wants the machine to
> generate and simply wants a way of writing source code that will make
> that happen.
There were several things about MASM 6.11d I began to dislike over the
years. At first it was amazing because it had all kinds of high-level
fixups. But over time I began to see clunky syntax compared with a
language like C. I began to wonder why the need for such disparate
syntaxes. It didn't make any sense.
For the assembler I'm currently developing, I have developed a new
syntax. You can compare them side-by-side as I wrote a conversion
tool to transform the original MASM 6.11d into my syntax. It still
has some flaws in conversion, but I'll get them sorted out as I go
along (Lord willing):
https://github.com/RickCHodgin/libsf/blob/master/exodus/source/debi/debi.asm
https://github.com/RickCHodgin/libsf/blob/master/exodus/source/debi/debi.lasm
Conversion tool (written for Visual FoxPro):
https://github.com/RickCHodgin/libsf/blob/master/exodus/tools/xbase/convert_asm_to_lasm.prg
Examples:
-----[ Begin MASM 6.11d ]-----
TITLE Debi Debugger
.MODEL tiny
.STACK 0h
INCLUDE \exodus\source\common\keylist.asp
INCLUDE \exodus\source\common\equates.asp
INCLUDE \exodus\source\common\macros.asp
INCLUDE debi_mac.asp ; Macros used for DEBI
INCLUDE debi_eq.asp ; Equates used for DEBI
.386P
_TEXT32 SEGMENT BYTE 'CODE' USE32
ASSUME NOTHING
; These are required to be the first 2 dwords in the file
dd offset main
dd offset requestor
main PROC
mov ds,cs:data_segment
mov ds:bootup,0
call initialize_driver
; Right now, carry? is SET or CLEAR indicating status of driver
retf
main ENDP
_TEXT32 ENDS
END
-----[ End MASM 6.11d ]-----
-----[ Begin LASM ]-----
include "\libsf\exodus\source\common\keylist.lasp"
include "\libsf\exodus\source\common\equates.lasp"
include "\libsf\exodus\source\common\macros.lasp"
include "debi_mac.lasp" // Macros used for DEBI
include "debi_eq.lasp" // Equates used for DEBI
code text32
| org 0
{
// These are required to be the first 2 dwords in the file
u32 offset main
u32 offset requestor
function main
{
mov ds,cs:data_segment
mov ds:bootup,0
initialize_driver()
// Right now, carry? is SET or CLEAR indicating status of driver
retf
}
}
-----[ End LASM ]-----
I also want to switch every reference to an address or offset to use
the label / token name itself, and for every memory reference related
to its contents or data at its address to use [this] form with brackets.
That will remove the need for "mov eax,offset name" and just use
"mov eax,name" when referring to the address. And it will use
"mov eax,[name]" when referring to the thing pointed to by name.
function main
{
mov ds,cs:[data_segment]
mov [bootup],0
initialize_driver()
// Right now, carry? is SET or CLEAR indicating status of driver
retf
}
It will take some getting used to, but it also goes along with a new
syntax I'm allowing for pointer references, and pointer-to-pointer
references in CAlive:
https://groups.google.com/d/msg/caliveprogramminglanguage/011Japa-DbM/GGTULbgxFgAJ
Example:
// Traditional C pointer, and pointer-to-pointer syntax:
char* p;
char** pp;
*p = 0;
*pp = p;
*(*pp) = 0;
*((*pp)+5) = 0;
// CAlive definition syntax:
[char] p;
[[char]] pp;
// CAlive use syntax:
[p] = 0; // Same as "*p = 0;"
[pp] = p; // Same as "*pp = p;"
[[pp]] = p; // Same as "*(*pp) = p;"
[[pp]+5] = p; // Same as "*((*pp)+5) = p;"
// Note: CAlive fully supports C syntax as well
I actually want to introduce a new symbol in CAlive's GUI which merges
[[ into a single character, and ]] into a single character, allowing
for alignment in the above definitions. I will also introduce specific
color highlighting, which will likely be a yellow silk-screen effect.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-11 02:51 -0600 |
| Message-ID | <hm4q4c59mpbm10u4m546q1ot949iq09bic@4ax.com> |
| In reply to | #98712 |
On Sat, 10 Dec 2016 08:37:00 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >On Friday, December 9, 2016 at 8:46:36 PM UTC-5, Chris M. Thomasson wrote: >> On 12/9/2016 5:00 PM, Rick C. Hodgin wrote: >> > Chris M. Thomasson wrote: >> >> Yikes! Humm, you probably should not look at this: >> >> >> >> http://webpages.charter.net/appcore/vzoom/refcount/refcount-ia32-gcc.asm >> >> >> >> Your eyes might start bleeding... >> >> >> >> ;^) >> > >> >> >> >> I like both AT&T and Intel syntax. I can use them both, and that is okay >> >> with me >> > >> > If forced to use AT&T syntax, I would switch professions. Not joking. >> >> Wow! > >I did a brief impromptu poll in my family, with my non-programmer wife >who doesn't have any interest in programming, and my 12-year old son >who is very much like his mother, and they both agreed that the Intel >syntax is preferable. > >Here are some of their reasons: > > 1) Like the brackets more than parenthesis. > 2) The % symbol everywhere is "just weird." > 3) The Intel syntax aligns things in columns more easily with > the variable-length number being after the left-side, which > helps it be seen more easily, as in this page: > http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html > > versus this page: > http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html > > 4) The AT&T syntax looks "generally busy." > 5) The Intel syntax is nicely spaced, and "simplified." > >Could not agree more. And, I gave them no prompting in finding this >information out. I sent them this email unannounced and unspoken to >regarding the poll: > > -----[ Begin ]----- >Subject: Opinion poll -- Which is easier to read > >From a straight-forward easiness of reading, which one is easier to read? > >#1 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html > >Or #2 -- http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_gcc_asm.html > >Please choose #1 or #2. > -----[ End ]----- > >I'd be curious what your non-programmer friends/family think with that >poll. And also what your programmer friends/family think. :-) > >Seriously, I will never use AT&T syntax. It breaks my heart that it >even exists. While I think Intel syntax for x86 is better than AT&T, it's hardly a career changer. Quitting your profession for that reason would be like a trucker deciding to quit their job because they didn't like the new font on the updated company logo painted on the side of the truck. It's just massively far down the list of priorities.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-11 04:40 -0800 |
| Message-ID | <f6ac0e66-636a-4af3-92ac-34caa5edebe5@googlegroups.com> |
| In reply to | #98765 |
robert...@yahoo.com wrote: > While I think Intel syntax for x86 is better than AT&T, it's hardly a > career changer. Quitting your profession for that reason would > be like a trucker deciding to quit their job because they didn't > like the new font on the updated company logo painted on the > side of the truck. It's more like they rearranged the gauges to read empty on the right, and full on the left, and converted their labels to egg latin. I have dyslexia. It would be so difficult for me to read AT&T syntax I would not do it. Normal reading today is hard enough. I even still miss things like your post. Begg-est regg-egegg-ards, Regg-ick C. Hegg-odgegg-in
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-11 23:06 -0600 |
| Message-ID | <a3bs4c1f2e0f8eh0bv04ai30hcl83imcv4@4ax.com> |
| In reply to | #98785 |
On Sun, 11 Dec 2016 04:40:00 -0800 (PST), "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: >robert...@yahoo.com wrote: >> While I think Intel syntax for x86 is better than AT&T, it's hardly a >> career changer. Quitting your profession for that reason would >> be like a trucker deciding to quit their job because they didn't >> like the new font on the updated company logo painted on the >> side of the truck. > >It's more like they rearranged the gauges to read empty on the >right, and full on the left, and converted their labels to egg latin. > >I have dyslexia. It would be so difficult for me to read AT&T syntax I >would not do it. Normal reading today is hard enough. I even still miss things like your post. 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.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-12 03:15 -0800 |
| Message-ID | <3b4b06af-b0a5-4079-a8e9-043eb7a9cab5@googlegroups.com> |
| In reply to | #98989 |
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. I truly believe Intel's assembly syntax is a towering achievement and triumph over AT&T's syntax. 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. 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. 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). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-12 16:12 +0100 |
| Message-ID | <o2memm$pka$1@dont-email.me> |
| In reply to | #99032 |
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. 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! 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. 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. 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. The reality is that it is very simple to pick an assembly syntax, and very easy to get used to almost any assembly syntax. > 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. > 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. > > 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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 18 — ← Prev page 1 2 [3] 4 5 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web