Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394650 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2025-10-22 09:45 -0300 |
| Last post | 2025-11-24 11:52 -0600 |
| Articles | 20 on this page of 248 — 14 participants |
Back to article view | Back to comp.lang.c
_BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 09:45 -0300
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-10-22 11:42 -0500
Re: _BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 14:23 -0300
Re: _BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 14:25 -0300
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-10-22 14:03 -0500
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-23 12:46 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-23 13:32 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-23 13:59 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-23 17:06 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 10:29 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 11:17 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:12 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 14:49 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 17:23 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 07:56 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 19:36 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 11:56 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 15:50 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:06 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 15:27 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 14:51 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:06 +0100
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-29 17:10 -0600
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 17:32 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:46 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:12 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:07 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-23 17:55 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-23 14:38 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 00:30 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 12:17 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 13:44 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:02 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 12:31 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:33 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 14:41 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 16:46 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:41 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 18:35 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 21:26 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 22:27 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 18:10 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 21:25 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 21:58 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 15:20 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 02:08 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 19:06 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:52 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 13:15 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 15:08 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 19:21 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:40 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 22:04 -0500
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 08:55 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 12:05 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 15:49 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 15:44 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 17:37 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 18:42 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 21:43 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 22:19 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 02:32 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 12:46 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 14:39 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 11:43 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 12:20 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 14:02 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-27 16:02 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 21:15 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 00:15 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 09:46 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 13:12 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 12:45 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 15:33 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 15:47 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-29 19:23 +0200
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 00:20 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-29 19:30 +0200
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-28 13:09 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 22:43 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 17:13 +0000
Re: _BitInt(N) Ike Naar <ike@sdf.org> - 2025-11-27 17:38 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 17:59 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-28 03:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 11:49 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 14:46 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-28 15:23 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 00:08 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 03:12 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-28 19:38 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 11:24 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-29 14:45 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 14:40 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-29 17:15 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 10:27 -0500
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 16:29 -0800
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 22:08 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-20 11:24 -0800
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-21 00:18 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 23:07 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-22 02:51 -0800
Re: _BitInt(N) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-22 19:23 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 03:01 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-20 18:22 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 21:57 -0800
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-20 21:27 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 21:51 -0800
Re: _BitInt(N) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-21 02:27 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 22:48 -0800
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-29 03:26 +0100
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-29 03:32 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 12:24 +0000
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-28 09:48 -0500
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 11:41 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 19:46 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 21:58 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 15:59 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 00:11 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 16:39 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 01:49 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 19:36 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-04 17:58 -0800
[meta] Newsreader and formatting (was Re: _BitInt(N)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-28 02:56 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-12-01 14:59 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:18 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:06 -0800
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-01 23:59 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 08:31 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-02 12:14 +0100
[OT] Keyboard layout (was Re: _BitInt(N)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 14:01 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-02 15:33 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-03 09:23 +0100
Re: _BitInt(N) Richard Heathfield <rjh@cpax.org.uk> - 2025-12-03 08:29 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-03 02:16 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 11:01 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-15 14:19 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 22:24 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-02 12:21 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 13:45 +0100
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 14:15 +0100
Block syntax (was Re: _BitInt(N)) bart <bc@freeuk.com> - 2025-12-02 14:12 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 13:53 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-12-02 19:55 +0200
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 19:37 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 21:07 +0100
Re: _BitInt(N) Ike Naar <ike@sdf.org> - 2025-11-27 08:10 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 01:30 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 02:18 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 04:12 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 20:24 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 22:58 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 16:46 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 02:30 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-30 05:31 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 12:51 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-30 18:17 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 17:55 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-01 00:08 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 01:14 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-01 04:10 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 14:41 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 16:24 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 17:19 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 19:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 20:14 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-02 01:04 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 18:21 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:34 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 22:01 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 15:01 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 11:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 11:29 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:10 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 08:56 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 19:38 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:42 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-02 22:17 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-03 09:25 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-03 06:17 -0500
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-03 10:07 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:19 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:21 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-30 18:05 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 20:32 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 12:22 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:41 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:28 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 13:35 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 15:14 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 12:09 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 18:03 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 11:38 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 14:12 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 14:57 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 18:29 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 18:33 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:12 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 12:45 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 15:31 +0200
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:29 +0200
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-26 21:19 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:29 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 21:54 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 13:42 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 12:01 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 15:08 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 13:24 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 23:11 +0200
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-26 17:04 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 01:05 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 02:54 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:17 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 22:41 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 00:17 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 01:22 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:00 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:05 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 10:51 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 13:10 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 15:26 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 15:09 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 17:26 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 21:53 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-30 17:32 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 08:36 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 11:37 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:37 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 14:14 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 16:28 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:39 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 14:10 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 04:29 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-23 21:39 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 11:45 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 13:57 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 12:56 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 15:17 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:59 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:35 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 14:21 +0000
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 13:12 -0600
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 17:00 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 20:10 -0600
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:30 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 01:51 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:22 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 04:37 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 11:52 -0600
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-11-26 21:19 -0500 |
| Message-ID | <10g8cf3$10jol$1@dont-email.me> |
| In reply to | #395491 |
On 2025-11-26 04:29, Michael S wrote: > On Tue, 25 Nov 2025 18:33:30 +0000 > bart <bc@freeuk.com> wrote: ... >> Then maybe C bitfields could be used, but a bigger problem with those >> is poor control over layout, which is anyway implementation-defined. >> (Mine of course don't have that problem!) > > According to the language of The Standard, it's not 'poor control'. > As far as standard requirements goes, there is *no* control on layout of > bit fields. C ;doesn't provide enough control over bit-field layouts to be useful, but it's an exaggeration to say it provides no control at all: "An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified. A bit-field declaration with no declarator, but only a colon and a width, indicates an unnamed bit-field.148) As a special case, a bit-field structure member with a width of zero indicates that no further bit-field is to be packed into the unit in which the previous bit-field, if any, was placed."
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-15 08:29 -0800 |
| Message-ID | <86pl8fu2se.fsf@linuxsc.com> |
| In reply to | #395512 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 2025-11-26 04:29, Michael S wrote: > >> On Tue, 25 Nov 2025 18:33:30 +0000 >> bart <bc@freeuk.com> wrote: > > ... > >>> Then maybe C bitfields could be used, but a bigger problem with those >>> is poor control over layout, which is anyway implementation-defined. >>> (Mine of course don't have that problem!) >> >> According to the language of The Standard, it's not 'poor control'. >> As far as standard requirements goes, there is *no* control on >> layout of bit fields. > > C ;doesn't provide enough control over bit-field layouts to be useful, > but it's an exaggeration to say it provides no control at all: [...] In my experience standard C does provide enough control over bit-field layout to be useful under some conditions. It doesn't provide as much control as I would like, but in some circumstances it does provide enough to be useful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-25 21:54 +0100 |
| Message-ID | <10g551s$3onvh$2@dont-email.me> |
| In reply to | #395461 |
On 25/11/2025 13:12, Michael S wrote:
> On Tue, 25 Nov 2025 11:38:32 +0000
> bart <bc@freeuk.com> wrote:
>
>>
>> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,
>> and played with 1/2/4 bits, but my view is that above this range,
>> using exact bit-sizes is the wrong way to go.
>>
>
> Either that or manifestation of your NIH syndrome.
> Which explanation do you consider more likely?
>
>> While for odd sizes up to 64 bits, bitfields are more apt than
>> employing the type system.
>>
>
> int sign_extend12(unsigned x)
> {
> return (_BitInt(12))x;
> }
>
> Nice, is not it?
> Doing the same with bit fields is possible, but less obvious and less
> convenient. Also it potentially can play havoc with compiler that took
> strict aliasing rules more seriously than they deserve.
>
> int sign_extend12(unsigned x)
> {
> struct bar {
> signed a: 12;
> };
> return ((struct bar*)&x)->a;;
> }
>
int sign_extend12(unsigned x)
{
union {
struct { unsigned u : 12; };
struct { signed s : 12; };
} u = {{ x }};
return u.s;
}
No need for messing about with aliases - type-punning unions are safe
and efficient (on good compilers).
But the _BitInt version is definitely neater. I can see myself using
_BitInt(12) and similar sizes for things like values read from hardware
sensors of different resolutions.
(The code for all three is the same with gcc on x86 or arm64 -
unfortunately, gcc does not yet support _BitInt on many targets.)
> Doing the same with shifts is almost as convenient as with _BitInt and
> it works great on all popular compilers, but according to wording of C
> Standard it is Undefined Behavior.
>
> int sign_extend12(unsigned x)
> {
> return (int32_t)((uint32_t)x << 20) >> 20;
> }
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-25 13:42 -0800 |
| Message-ID | <87bjkpkcvm.fsf@example.invalid> |
| In reply to | #395480 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> But the _BitInt version is definitely neater. I can see myself using
> _BitInt(12) and similar sizes for things like values read from
> hardware sensors of different resolutions.
>
> (The code for all three is the same with gcc on x86 or arm64 -
> unfortunately, gcc does not yet support _BitInt on many targets.)
[...]
Is support for _BitInt limited by target or by version?
It looks like _BitInt support was introduced in gcc 14.1.0. You might
have older versions of gcc on other platforms.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 12:01 +0200 |
| Message-ID | <20251126120130.00003772@yahoo.com> |
| In reply to | #395483 |
On Tue, 25 Nov 2025 13:42:37 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] > > But the _BitInt version is definitely neater. I can see myself > > using _BitInt(12) and similar sizes for things like values read from > > hardware sensors of different resolutions. > > > > (The code for all three is the same with gcc on x86 or arm64 - > > unfortunately, gcc does not yet support _BitInt on many targets.) > [...] > > Is support for _BitInt limited by target or by version? > > It looks like _BitInt support was introduced in gcc 14.1.0. You might > have older versions of gcc on other platforms. > The most recent version of arm-none-eabi-gcc in my distribution of choice (msys2) is 13.3.0. I am too lazy to compile arm-none-eabi-gcc from source. Would rather wait. I suppose, David is like me in that regard, except that he probably uses even more conservative distribution.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 15:08 +0100 |
| Message-ID | <10g71ks$ev96$1@dont-email.me> |
| In reply to | #395493 |
On 26/11/2025 11:01, Michael S wrote: > On Tue, 25 Nov 2025 13:42:37 -0800 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> But the _BitInt version is definitely neater. I can see myself >>> using _BitInt(12) and similar sizes for things like values read from >>> hardware sensors of different resolutions. >>> >>> (The code for all three is the same with gcc on x86 or arm64 - >>> unfortunately, gcc does not yet support _BitInt on many targets.) >> [...] >> >> Is support for _BitInt limited by target or by version? >> >> It looks like _BitInt support was introduced in gcc 14.1.0. You might >> have older versions of gcc on other platforms. >> > > The most recent version of arm-none-eabi-gcc in my distribution of > choice (msys2) is 13.3.0. > I am too lazy to compile arm-none-eabi-gcc from source. Would rather > wait. > I suppose, David is like me in that regard, except that he probably > uses even more conservative distribution. > > I have release 13.3 installed, but I haven't used it on any projects yet. I tend to use new releases on new projects, but I am very conservative about changing toolchains in existing projects. But for things like this, I use godbolt.org - it is /so/ much easier than testing individually. Just pick the compiler target and version from the list, and see if you get an error message when using _BitInt.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 13:24 +0100 |
| Message-ID | <10g6rhq$bn6e$2@dont-email.me> |
| In reply to | #395483 |
On 25/11/2025 22:42, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> But the _BitInt version is definitely neater. I can see myself using >> _BitInt(12) and similar sizes for things like values read from >> hardware sensors of different resolutions. >> >> (The code for all three is the same with gcc on x86 or arm64 - >> unfortunately, gcc does not yet support _BitInt on many targets.) > [...] > > Is support for _BitInt limited by target or by version? > Both - I expect it to be implemented for more targets in later versions :-) > It looks like _BitInt support was introduced in gcc 14.1.0. You might > have older versions of gcc on other platforms. > It was added to x86 and AArch64 targets in gcc 14. It is not supported on any other targets as yet, as far as I know. Presumably it will come when someone has done the work for the backends. (Some of such implementations are target-independent, but some are backend specific.) Generally, x86-64 and AArch64 are the targets that get the most focus and support from the big companies, which 32-bit ARM, MIPS, PowerPC, etc., can often be a little slower due to fewer resources.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-25 23:11 +0200 |
| Message-ID | <20251125231158.00000c0d@yahoo.com> |
| In reply to | #395461 |
On Tue, 25 Nov 2025 14:12:07 +0200
Michael S <already5chosen@yahoo.com> wrote:
>
> Doing the same with shifts is almost as convenient as with _BitInt and
> it works great on all popular compilers, but according to wording of C
> Standard it is Undefined Behavior.
>
> int sign_extend12(unsigned x)
> {
> return (int32_t)((uint32_t)x << 20) >> 20;
> }
>
Before someone corrects me, I'd correct myself: the code above does not
contain Undefined Behavior. It's merely Implementation Defined Behavior.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-26 17:04 -0600 |
| Message-ID | <10g815q$s8ai$1@dont-email.me> |
| In reply to | #395460 |
On 11/25/2025 5:38 AM, bart wrote:
> On 25/11/2025 02:03, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 24/11/2025 14:41, David Brown wrote:
>>>> On 24/11/2025 13:31, bart wrote:
>>>> That's all up to the implementation.
>>>> You are worrying about completely negligible things here.
>>>
>>> Is it that negligible? That's easy to say when you're not doing the
>>> implementing! However it may impact on the size and performance of
>>> code.
>>
>> You're right, it's easy to say when I'm not doing the implementing.
>> Which I'm not.
>>
>> The maintainers of gcc and llvm/clang have done that for me, so I don't
>> have to worry about it.
>>
>> Are you planning to implement bit-precise integer types yourself? I
>> don't think you've said so in this thread. If you are, you have at
>> least two existing implementations you can look at for ideas.
>
> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits, and
> played with 1/2/4 bits, but my view is that above this range, using
> exact bit-sizes is the wrong way to go.
>
On normal PC's, it is meh.
On FPGA's, more so the whole HLS (High Level Synthesis) thing, it is
much more significant.
Also it is a bridge that allows sensible mapping some Verilog semantics
onto C, which can in turn be made more efficient than "ye olde shifts
and masking". This is partly a case because the compiler has more
freedom to either use specific CPU features, or to implement the
constructs in ways that are more efficient but would impose too much
mental computational burden on normal programmers (such as shifts being
relative to other shifts, and/or where the most efficient masking
strategy depends on the width of the type being masked, etc).
Though, granted, bolting a bunch of Verilog stuff onto C is also
nonstandard (and goes well beyond the scope of _BitInt). But, a lot of
it is stuff that wouldn't really make sense at all in C in the absence
of exact-width integers.
Though, the other parts of Verilog don't map over quite so easily...
always @(posedge clock)
...
... yeah ...
Ironically, had started looking into adding Verilog support to my
compiler (at the time hoping maybe to be able to implement something
that was less of a pain to debug on than Verilator), most I got here was
the idea that modules would be mapped onto classes and so each module
could be implemented as a class instance, with an internal run/step
method which would check variables and fire off any "always" blocks when
appropriate.
The effort kinda stalled out at this stage though (and motivation
lessened when I actually found some of the bugs I had been looking for).
Some other functionality had ended up mapped onto C, some features
(ironically) being useful in this C land, and others not so much.
Well, maybe some people could cheer for things like "casez()" or
"__switchz()":
__switchz(val[15:0])
{
case 0bZZZZ_ZZZZ_ZZZZ_ZZZ0u16: ... matches everything with LSB clear
case 0bZZZZ_ZZZZ_ZZZZ_ZZ01u16: ... matches with LSB's as 01
case 0bZZZZ_ZZZZ_ZZZZ_Z011u16: ...
case 0b1111_ZZZZ_ZZZZ_0111u16: ... mastches 0111 and MSBs set to 1s.
}
Where, 0bZZZZ_ZZZZ_ZZZZ_Z011u16 is a C syntax analog of
16'bbZZZZ_ZZZZ_ZZZZ_Z011 (and in this case my compiler allows for either
_ or single quotes).
Though, implementing this in a way that is efficient is a harder problem
(much more complicated than a normal "switch()").
Though, had I gotten this part implemented, would still have also needed:
A high performance emulator (now partly written, but, would likely need
a full JIT compiler rather than a call-threading interpreter);
A better/more usable debugger (*).
*: My existing "jx2vm" emulator mostly dumps stuff if the emulator
exits, and has an integrated GDB style debugger, this still leaves
something to be desired.
So, more likely the desired debugger would likely be built on "x3vm",
but have not yet done so.
Also compiler needs to produce more complete debuginfo. As-is, it is
outputting symbol maps (in nm notation, similar to that typically used
by the Linux kernel), with line-numbers in a slightly nonstandard way,
and some small about of STABS. Maybe weak, but currently the most
reachable strategy (contrast, GCC would typically put the debug info
inside the binary, either as STABS or DWARF depending on target, ...).
The debuginfo is still very incomplete, and I am also lacking a good
debugger here.
I had considered the possibility of going to a binary format for the map
files to save space, but for now they are still ASCII based (well, or
the possible lazier option of internally generating the map in ASCII
format, but then dumping it in gzip format or similar ".map.gz"; would
need to decompress them when loaded, but would leave an easy option for
a user to get back to an ASCII map file as needed). Including STABS
would add considerable bulk even vs just a normal symbol listing.
I have my own reasons for not wanting to put debuginfo inside the
binaries themselves. MSVC is kinda similar, just uses ".PDB" files instead.
> While for odd sizes up to 64 bits, bitfields are more apt than employing
> the type system.
>
This is missing the point of the purpose of _BitInt...
>> Here's an idea. Rather than asserting that _BitInt(1'000'000)
>> is silly and obviously useless, try *asking* how it's useful.
>> I personally don't know what I'd do with a million-bit integer,
>> but maybe somebody out there has a valid use for it. Meanwhile,
>> its existence doesn't bother me.
>
> Again, my view is that types like _BitInt(123456) (could they have made
> it any more fiddly to type?!) is the same mistake that early Pascal made
> with arrays.
>
> It is common that an N-array of T and an M-array of T are not
> compatible, but usually there are ways to deal generically with both.
>
For using them in a way that is useful for their intended purpose, there
need to be some constraints here.
But, alas, debating 1M bit values is a little moot in my case as the
compiler doesn't go quite that big.
Most cases where a giant _BitInt could make sense are better served by
not using _BitInt.
In this case, the limit is 16383 bits, but this is still bigger than
anything it really makes sense to do with _BitInt.
Also doesn't make sense for Verilog either; about as soon as you start
trying to use values this big, it is "gonna eat the FPGA".
Well, and for things like bignums, could instead make a case for a
dynamic typesystem and the ability for user code to plug new types into
said dynamic typesystem (and register operators for said types).
But, this is probably a feature that is unlikely to get added to mainline C.
Well, and probably about as soon as someone adds dynamic types, people
might start pushing for also adding a garbage collector, even if (thus
far) still no one has succeeded in making GC "not suck" (some may point
to JVM and .NET, but they mostly just made it "less obvious").
Contrast to my recent annoyance that Firefox is regularly stalling for
extended periods of time for presumably GC related reasons (and has
seemingly failed to implement one that runs particularly fast).
>
>> My guess is that once you've implemented integers wider than 128
>> or 256 bits, million-bit integers aren't much extra effort.
>
> I've implemented 128-bit arithmetic, and have seen some scary-looking C
> code that implemented 256-bit arithmetic. Neither of those would scale
> to N-bits where N can be arbitrary large /and/ might not be a multiple
> of either 64 or 8.
>
> You would need pretty much the same algorithms as used for arbitrary
> precision. Those usually require N to be some multiple of 'limb' size.
>
Note for example, say:
How do you think I would have implemented large _BitInt?...
Why is storage a multiple of 128-bits / 16 bytes?...
...
Well, internally in this case the compiler effectively just sorta
generates internal runtime calls.
In this case:
1-64 bits: Mostly native;
65-128: Semi-native mixed with runtime calls.
129-256: Runtime calls to fixed-width 256-bit handlers.
257-16383: Generic runtime calls that pass the width as an argument.
...
If the size isn't an exact multiple of the target size, one can pad it
up and and then sign or zero extend the high-order element.
Ironically, it is sorta like a partial inverse of "memcpy()" and
"memset()" with a fixed size:
Size is small, better to handle it inline;
Medium, use size-specialized handling;
Large, use a generic call (actually call "memcpy()").
Say:
<= 64 bytes: Inline
65-512 bytes: Call into fixed-size copies
Generally, copy any trailing bytes and then fall into a copy-slide.
> 512: Actually call "memcpy()".
Even for smaller types, there is no guarantee that it is not a runtime call.
Say, for example, on some random (non x86-64 or similar) target:
long x, y, z;
...
z=x/y;
How confident can you be that it is *not* just secretly calling a
runtime function?...
Even if the ISA has an instruction, there isn't much guarantee that it
is going to be faster than using a runtime call.
Or, say, the only time one can be semi-confident it is not a runtime
call is if it is "int/const" or similar (because the compiler can turn
this into multiply-by-reciprocal).
Say, a CPU being left with choices for how to implement divide:
Faster, but very expensive;
Say, for example, a radix divider or similar;
Medium cost, kinda slow: Hardware shift-and-subtract or similar;
Can give ~ 36 cycle 32-bit IDIV, and ~ 68 cycle 64-bit IDIV.
Cheap but slow: Trap and emulate, OS then uses shift-and-subtract.
In some cases, it being faster for the compiler to use runtime calls for
divide and similar, since this can sidestep the performance cost of the
emulation trap.
Except ironically, me shifting towards the counter stance for Binary128,
as Binary128 operations can be sufficiently slow that the code-density
savings can offset the (comparably modest in this case) performance cost
of the emulation traps (otherwise, code using "long double" or similar
having a whole lot of runtime calls; which cost around 8x the code
footprint of just pretending one has the corresponding instructions).
Also semi-relevant for RV64, which also lacks particularly good options
for implementing fast "__int128" support, which is (ironically) somewhat
relevant for making the Binary128 FPU emulation not slow. Though, I also
took the non-standard stance of defining these operations as working on
register pairs (in this case, defining FADD.Q and FMUL.Q as using
register pairs being the less-bad option than also pretending it has
128-bit FPR's; more so as in this case SIMD operations already use
register pairs for 128-bit SIMD, ...).
So, a "Pseudo-Q" defined in terms of:
CPU only actually implements F/D;
Define .Q operations as being allowed, but operating via traps.
Arguably poor, but cheapest option in this case.
Actually supporting Q extension would be too expensive.
I don't exactly expect Binary128 to suddenly become cheap either.
Though, for integer divide and similar, the relative cost is low enough
(and divide is common enough) that trap-and-emulate is rather painful.
So, in the absence of a HW divider, better to use a runtime call
(probably via a shift-and-subtract loop or similar).
But, divide is still rare enough to make it hard-pressed to justify the
cost of a more expensive HW divider (such as Radix-16 or Goldschmidt or
similar). One might still be left with trap-and-emulate for FPU divide
and SQRT though.
Or, say, other wonk (for an ISA like RV64):
FDIV, FSQRT: Trap
FMADD/etc (when RM=DYN): Trap
Assuming here that DYN has the option of IEEE correct semantics.
Which means trapping on HW which doesn't have single-rounded FMA.
Mildly annoying then if building with GCC, one has to use special
options to disable FMA and tell it to use a runtime call for FDIV, etc,
in an attempt to avoid it stepping on cases that need emulation traps.
Well, and for sake of IEEE semantics:
Trapping on subnormal/denormal inputs;
Trapping with LOBs of inputs are non-zero for FMUL;
Partial width makes FMUL a lot cheaper for hardware;
But, then one needs to trap in some cases.
...
Well, and other fun corner cutting, like lacking hardware page walking
and reliance on a trap handler to deal with TLB misses; etc.
Well, for an ISA like RV, can also corner-cut things like supporting
options other than X0 and X1 for JAL and JALR (if Rd is not X0 or X1, trap).
Well, and if the CPU is being "extra budget", they might use trap and
emulate for misaligned loads/stores. Though, IMO this is getting a
little too budget (and there are a lot of things that can be implemented
more efficiently if one has at least semi-fast unaligned load/store).
...
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-27 01:05 +0000 |
| Message-ID | <10g883v$ulcd$1@dont-email.me> |
| In reply to | #395508 |
On 26/11/2025 23:04, BGB wrote:
> On 11/25/2025 5:38 AM, bart wrote:
>> On 25/11/2025 02:03, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 24/11/2025 14:41, David Brown wrote:
>>>>> On 24/11/2025 13:31, bart wrote:
>>>>> That's all up to the implementation.
>>>>> You are worrying about completely negligible things here.
>>>>
>>>> Is it that negligible? That's easy to say when you're not doing the
>>>> implementing! However it may impact on the size and performance of
>>>> code.
>>>
>>> You're right, it's easy to say when I'm not doing the implementing.
>>> Which I'm not.
>>>
>>> The maintainers of gcc and llvm/clang have done that for me, so I don't
>>> have to worry about it.
>>>
>>> Are you planning to implement bit-precise integer types yourself? I
>>> don't think you've said so in this thread. If you are, you have at
>>> least two existing implementations you can look at for ideas.
>>
>> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,
>> and played with 1/2/4 bits, but my view is that above this range,
>> using exact bit-sizes is the wrong way to go.
>>
>
> On normal PC's, it is meh.
>
> On FPGA's, more so the whole HLS (High Level Synthesis) thing, it is
> much more significant.
>
>
> Also it is a bridge that allows sensible mapping some Verilog semantics
> onto C, which can in turn be made more efficient than "ye olde shifts
> and masking". This is partly a case because the compiler has more
> freedom to either use specific CPU features, or to implement the
> constructs in ways that are more efficient but would impose too much
> mental computational burden on normal programmers (such as shifts being
> relative to other shifts, and/or where the most efficient masking
> strategy depends on the width of the type being masked, etc).
>
> Though, granted, bolting a bunch of Verilog stuff onto C is also
> nonstandard (and goes well beyond the scope of _BitInt). But, a lot of
> it is stuff that wouldn't really make sense at all in C in the absence
> of exact-width integers.
>
>
>
> Though, the other parts of Verilog don't map over quite so easily...
> always @(posedge clock)
> ...
> ... yeah ...
>
> Ironically, had started looking into adding Verilog support to my
> compiler (at the time hoping maybe to be able to implement something
> that was less of a pain to debug on than Verilator), most I got here was
> the idea that modules would be mapped onto classes and so each module
> could be implemented as a class instance, with an internal run/step
> method which would check variables and fire off any "always" blocks when
> appropriate.
>
> The effort kinda stalled out at this stage though (and motivation
> lessened when I actually found some of the bugs I had been looking for).
>
>
> Some other functionality had ended up mapped onto C, some features
> (ironically) being useful in this C land, and others not so much.
>
> Well, maybe some people could cheer for things like "casez()" or
> "__switchz()":
> __switchz(val[15:0])
> {
> case 0bZZZZ_ZZZZ_ZZZZ_ZZZ0u16: ... matches everything with LSB clear
> case 0bZZZZ_ZZZZ_ZZZZ_ZZ01u16: ... matches with LSB's as 01
> case 0bZZZZ_ZZZZ_ZZZZ_Z011u16: ...
> case 0b1111_ZZZZ_ZZZZ_0111u16: ... mastches 0111 and MSBs set to 1s.
> }
>
> Where, 0bZZZZ_ZZZZ_ZZZZ_Z011u16 is a C syntax analog of
> 16'bbZZZZ_ZZZZ_ZZZZ_Z011 (and in this case my compiler allows for either
> _ or single quotes).
>
>
>
> Though, implementing this in a way that is efficient is a harder problem
> (much more complicated than a normal "switch()").
>
> Though, had I gotten this part implemented, would still have also needed:
> A high performance emulator (now partly written, but, would likely need
> a full JIT compiler rather than a call-threading interpreter);
> A better/more usable debugger (*).
>
> *: My existing "jx2vm" emulator mostly dumps stuff if the emulator
> exits, and has an integrated GDB style debugger, this still leaves
> something to be desired.
>
> So, more likely the desired debugger would likely be built on "x3vm",
> but have not yet done so.
>
>
> Also compiler needs to produce more complete debuginfo. As-is, it is
> outputting symbol maps (in nm notation, similar to that typically used
> by the Linux kernel), with line-numbers in a slightly nonstandard way,
> and some small about of STABS. Maybe weak, but currently the most
> reachable strategy (contrast, GCC would typically put the debug info
> inside the binary, either as STABS or DWARF depending on target, ...).
> The debuginfo is still very incomplete, and I am also lacking a good
> debugger here.
>
> I had considered the possibility of going to a binary format for the map
> files to save space, but for now they are still ASCII based (well, or
> the possible lazier option of internally generating the map in ASCII
> format, but then dumping it in gzip format or similar ".map.gz"; would
> need to decompress them when loaded, but would leave an easy option for
> a user to get back to an ASCII map file as needed). Including STABS
> would add considerable bulk even vs just a normal symbol listing.
>
> I have my own reasons for not wanting to put debuginfo inside the
> binaries themselves. MSVC is kinda similar, just uses ".PDB" files instead.
>
>
>> While for odd sizes up to 64 bits, bitfields are more apt than
>> employing the type system.
>>
>
> This is missing the point of the purpose of _BitInt...
Which is ... ?
From what I can gether, on ordinary computers, Bitint(N), for N of 1/2
to 63, is just rounded up to the next size of 8/16/32/64 bits, if N is
not already at that size.
That's if storage is involved.
The other aspect appears to be two-fold:
* BitInt(N) used as a cast on an ordinary value will zero- or
sign-extend the low N bits
* When reading from storage allocated with BitInt(N), is ensures only N
bits of info are retrieved, extended as necessary, even of more then N
bits were stored. This applies even if the storage was rounded up.
So it seems to be mainly about masking.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-27 02:54 +0000 |
| Message-ID | <10g8ehf$i159$2@paganini.bofh.team> |
| In reply to | #395450 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
> Here's an idea. Rather than asserting that _BitInt(1'000'000)
> is silly and obviously useless, try *asking* how it's useful.
> I personally don't know what I'd do with a million-bit integer,
> but maybe somebody out there has a valid use for it. Meanwhile,
> its existence doesn't bother me.
>
> My guess is that once you've implemented integers wider than 128
> or 256 bits, million-bit integers aren't much extra effort.
Actually critical thing is support for sizes between 256 and 1024,
here good inline code can be nontrivially faster than than
calls to general library. Once you go above 1024 mutiplication
is costly enough so that other thing do not make much difference.
But ambitious implementation may try to gain due to known size
also for somewhat bigger sizes, so low limit would be unnatural.
IIUC currently for RSA modulus having about 3000 bits is
recomended setting, but switch to 4000 bits is likely in
near future. Actual arithmetic in RSA need double number
of bits compared to modulus, so to properly support RSA
implementation should have limit 8192 or bigger. So, it
looks that gcc has limit choosen just to support important
applications like RSA.
For million bit integers one wants FFT multiplication, for
sizes available in gcc one could use slightly simpler
methods which are faster than FFT in intermediate range.
Of course, one can call 'mpn' routines from GMP, so such
multiplication is just a function call, unless implementor
does not want to use GMP.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-29 22:17 +0100 |
| Message-ID | <10gfnsk$sda3$2@solani.org> |
| In reply to | #395408 |
Am 24.11.25 um 13:31 schrieb bart: > On 24/11/2025 11:17, David Brown wrote: >> On 24/11/2025 01:30, bart wrote: > >>> Saving memory was mentioned. To achieve that means having bitfields >>> that may not start at bit 0 of a byte, and may cross byte- or word- >>> boundaries. >>> >> >> No, that is incorrect. >> >> The proposal mentions saving /space/ as relevant in FPGAs - not >> saving / memory/. > > But I was responding to a suggestion here that one use of _BitInts - > presumably for ordinary hardware - was to save memory. > > That's not going to happen if they are simply rounded up to the next > power-of-two type. SDCC has no padding bytes - a _BitInt(N) uses (N+7)/8 bytes. And for SDCC, _BitInt is currently the only way to get adressable integers that are not a "power-of-two type". Philipp
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-29 22:41 +0000 |
| Message-ID | <10gfsre$1a5el$2@paganini.bofh.team> |
| In reply to | #395576 |
Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 24.11.25 um 13:31 schrieb bart:
>> On 24/11/2025 11:17, David Brown wrote:
>>> On 24/11/2025 01:30, bart wrote:
>>
>>>> Saving memory was mentioned. To achieve that means having bitfields
>>>> that may not start at bit 0 of a byte, and may cross byte- or word-
>>>> boundaries.
>>>>
>>>
>>> No, that is incorrect.
>>>
>>> The proposal mentions saving /space/ as relevant in FPGAs - not
>>> saving / memory/.
>>
>> But I was responding to a suggestion here that one use of _BitInts -
>> presumably for ordinary hardware - was to save memory.
>>
>> That's not going to happen if they are simply rounded up to the next
>> power-of-two type.
>
> SDCC has no padding bytes - a _BitInt(N) uses (N+7)/8 bytes. And for
> SDCC, _BitInt is currently the only way to get adressable integers that
> are not a "power-of-two type".
But do SDCC support any non-8 bit processor? I hope that gcc 8-bit
targets will also use minimal number of bytes.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 00:17 +0100 |
| Message-ID | <10gfutm$sh8q$1@solani.org> |
| In reply to | #395580 |
Am 29.11.25 um 23:41 schrieb Waldek Hebisch: > > But do SDCC support any non-8 bit processor? I hope that gcc 8-bit > targets will also use minimal number of bytes. I don't really know. I know most of the architectures targeted by SDCC, but what is a "non-8 bit processor"? Philipp
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-30 01:22 +0000 |
| Message-ID | <10gg684$1fl4d$3@paganini.bofh.team> |
| In reply to | #395583 |
Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 29.11.25 um 23:41 schrieb Waldek Hebisch:
>>
>> But do SDCC support any non-8 bit processor? I hope that gcc 8-bit
>> targets will also use minimal number of bytes.
>
> I don't really know. I know most of the architectures targeted by SDCC,
> but what is a "non-8 bit processor"?
Processor which is not 8 bit processor.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 11:00 +0100 |
| Message-ID | <10gh4kr$t89e$2@solani.org> |
| In reply to | #395586 |
Am 30.11.25 um 02:22 schrieb Waldek Hebisch: > Philipp Klaus Krause <pkk@spth.de> wrote: >> Am 29.11.25 um 23:41 schrieb Waldek Hebisch: >>> >>> But do SDCC support any non-8 bit processor? I hope that gcc 8-bit >>> targets will also use minimal number of bytes. >> >> I don't really know. I know most of the architectures targeted by SDCC, >> but what is a "non-8 bit processor"? > > Processor which is not 8 bit processor. > That doesn't make it much clearer. All SDCC targets have (by their standards) reasonablish ability to address 8-bit bytes, at least in RAM and have instructions to operate on 8-bit data (but so do x86 and amd64, which are not widely considered to be 8-bit). For all targets, memory tends to be somewhat small on typical systems, so it makes sense to not have padding bytes. But there are cases where padding bytes could give a little bit of extra speed (due to alignment) in some situations, but IMO none, where having them would be worth it. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-30 11:05 +0200 |
| Message-ID | <20251130110532.000058bc@yahoo.com> |
| In reply to | #395583 |
On Sun, 30 Nov 2025 00:17:10 +0100 Philipp Klaus Krause <pkk@spth.de> wrote: > Am 29.11.25 um 23:41 schrieb Waldek Hebisch: > > > > But do SDCC support any non-8 bit processor? I hope that gcc 8-bit > > targets will also use minimal number of bytes. > > I don't really know. I know most of the architectures targeted by > SDCC, but what is a "non-8 bit processor"? > > Philipp > The list of supported targets on SDCC front page: * Intel MCS51 based microprocessors * Maxim (formerly Dallas) DS80C390 variants * Freescale (formerly Motorola) HC08 based * Zilog Z80 based MCUs * Padauk (pdk14, pdk15) * STMicroelectronics STM8 * MOS 6502 and WDC 65C02 Work is in progress: * Rabbit 4000, 5000, 6000 * Padauk pdk13 and the f8 and f8l Unmaintained: * Microchip PIC16 and PIC18 I know nothing about Rabbit and Padauk. The rest of architectures in the list are '8-bit processors'. Now, if you ask me, I don't understand why Waldek Hebisch considers difference between 8-bit and [byte-addressable] 16-bit targets important. As far as size of relevant C types goes, they look the same: char - 8 bits int - 16 bit long - 32 bits There is possibly difference in the size of 'short', but I don't understand why it matters. Examples of still relevant 16-bit targets: Microchip PIC24, TI C5000 The latter is not byte-addressable. I am not sure about the former.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 10:51 +0100 |
| Message-ID | <10gh43a$t89e$1@solani.org> |
| In reply to | #395595 |
Am 30.11.25 um 10:05 schrieb Michael S: > > The list of supported targets on SDCC front page: > * Intel MCS51 based microprocessors OK, that one is plain 8-bit. > * Maxim (formerly Dallas) DS80C390 variants I'm not really familiar with this one. One one hand it is an MCS-51 derivative, and the instructions mostly operate on 8-bit data, but it also AFAIK has a flat 24-bit address space. > * Freescale (formerly Motorola) HC08 based 8-bit, I'd say. > * Zilog Z80 based MCUs This one gets complicated. The original Z80 had a 4-bit ALU, but is widely considered 8-bit, and I'd agree. It has an 8-bit data bus, a 16-bit address bus. Most instructions operate on 8-bit data, but there are some that operate on 16 bits. But SDCC supports many "Z80 based" MCUs. Some are clearly as 8-bit as the Z80, or even more so. But some have quite rich 16-bit instructions, such as the TLCS-90. The eZ80 even has 24-bit registers and quite some instructions that operate on 24-bit data (when in ADL mode - in Z80 mode they operate on 16-bit data instead). The Rabbits up to 3000A also have quite good support for working with 16-bit data. > * Padauk (pdk14, pdk15) The Padauk µC have an 8-bit wide RAM. Depending on the variant, the program and const data is stored in a PROM or flash that is 14 or 15 bits wide. > * STMicroelectronics STM8 Most instructions operate on 8-bit, a few operate on 16 bits. The RAM is connected to the CPU via an 8-bit data bus. The flash is connected to the CPU via a 32-bit data bus (and in some cases alignment affects timing when reading data or instructions from that flash). > * MOS 6502 and WDC 65C02 I think these are quite clearly 8 bit. > Work is in progress: > * Rabbit 4000, 5000, 6000 These are Z80 derivatives. But they also have quite some instructions that operate on 16 or 32 bits. Their data bus can be configured to 8 or 16 bits. > * Padauk pdk13 Has a 13 bits wide PROM, otherwise similar to the pdk14/pdk15 above. > and the f8 and f8l 8-bit or mixed 8/16 bit. > Unmaintained: > * Microchip PIC16 and PIC18 Probably 8 bit. > I know nothing about Rabbit and Padauk. The rest of architectures in > the list are '8-bit processors'. While I also often use that term, it is not entirely clear where the line should be drawn. Many '8-bit processors' could reasonably be considered 8/16 bit, 16 bit, 24 bit, 32 bit, or combinations thereof instead. But all SDCC targets can in some way address 8-bit bytes. Though for the pdk13, pdk14, pdk15 this means just ignoring the upper 5/6/7 bits when reading data from PROM/flash - maybe for pdk15, it would make sense to have some optimization for const _BitInt(N) (N <= 15) directly into that PROM/flash, as long as the address is never taken. If SDCC gets pdk16 support, it would probably emulate 8-bit addressing for the 16-bit PROM/flash. > Now, if you ask me, I don't understand why Waldek Hebisch considers > difference between 8-bit and [byte-addressable] 16-bit targets > important. As far as size of relevant C types goes, they look the same: > char - 8 bits > int - 16 bit > long - 32 bits > There is possibly difference in the size of 'short', but I don't > understand why it matters. If int is 16 bits, shorts is 16 bits, too. Philipp
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-30 13:10 +0000 |
| Message-ID | <10ghfn8$bgvr$2@dont-email.me> |
| In reply to | #395598 |
On 30/11/2025 09:51, Philipp Klaus Krause wrote: > Am 30.11.25 um 10:05 schrieb Michael S: >> * Zilog Z80 based MCUs > > This one gets complicated. The original Z80 had a 4-bit ALU, but is > widely considered 8-bit, and I'd agree. That's news to me. Are you thinking of the 4040 as the original? Z80 was a souped-up version of 8080: a superset with better technical specs. > It has an 8-bit data bus, a 16- > bit address bus. Most instructions operate on 8-bit data, but there are > some that operate on 16 bits. My first compiler for Z80 (not for C) supported u8, i16 and f24 types (in modern parlance). That f24 just happened to be simpler for emulating floating point. Later this became u8, i16, u32 (I think) and f32. I never had a need for odd sizes. (Although some of the memory used was only 4-bit or 6-bits wide, this was read or written via 8-bit data. For example 8KB of memory occupied a 16KB address range, because it was convenient for video. So there were savings in memory, but via different means!) I am looking at retargeting Z80 now (it'll be emulated), but I don't have plans for non-power-of-two types. If I wanted to emulate eZ80 with its 24-bit registers, then I'd need to consider how best to do that. It's not as simple as just bolting on an i24 or u24 type in the HLL, or (what's being discussed) employing an ambitious type that can have an arbitrary N bit size.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 15:26 +0100 |
| Message-ID | <10ghk63$tjbn$1@solani.org> |
| In reply to | #395610 |
Am 30.11.25 um 14:10 schrieb bart: > On 30/11/2025 09:51, Philipp Klaus Krause wrote: >> Am 30.11.25 um 10:05 schrieb Michael S: > >>> * Zilog Z80 based MCUs >> >> This one gets complicated. The original Z80 had a 4-bit ALU, but is >> widely considered 8-bit, and I'd agree. > > That's news to me. Are you thinking of the 4040 as the original? Z80 was > a souped-up version of 8080: a superset with better technical specs. Both the 4004 and the Z80 were designed by Masatoshi Shima. See this interview for details on the Z80 (he does call the Z80 an "8-bit microprocessor", just a few sentences before mentioning its 4-bit ALU): https://archive.computerhistory.org/resources/text/Oral_History/Zilog_Z80/102658073.05.01.pdf
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web