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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-30 15:09 +0000 |
| Message-ID | <10ghmmr$elod$1@dont-email.me> |
| In reply to | #395612 |
On 30/11/2025 14:26, Philipp Klaus Krause wrote: > 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 > OK, so the Z80 has a '4-bit pipelined' ALU. It's explained in more detailed here: https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html (It doesn't say why; presumably it uses fewer on-chip resources, or to make a point of difference from the 8080.) But that appears to be an implementation detail that is transparent to the user. Since it uses 8-bit registers, 8-bit instructions, and has an 8-bit databus, I think it can pass for an 8-bit CPU!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-30 17:26 +0100 |
| Message-ID | <10ghr7d$gb53$1@dont-email.me> |
| In reply to | #395613 |
On 30/11/2025 16:09, bart wrote: > On 30/11/2025 14:26, Philipp Klaus Krause wrote: >> 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 >> > > OK, so the Z80 has a '4-bit pipelined' ALU. It's explained in more > detailed here: > > https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html > > (It doesn't say why; presumably it uses fewer on-chip resources, or to > make a point of difference from the 8080.) > > But that appears to be an implementation detail that is transparent to > the user. > > Since it uses 8-bit registers, 8-bit instructions, and has an 8-bit > databus, I think it can pass for an 8-bit CPU! Indeed, it also has 16-bit register pairs and some 16-bit instructions - it is often classified as a 8/16-bit processor. At the other end of the scale, the COP8 microcontroller (which is maybe supported by SDCC? There are certainly other sort-of-C compilers for it) has a serial architecture internally. One instruction cycle is 10 clock cycles, and it uses a 1-bit ALU. But it is definitely an 8-bit microcontroller. And then you have the original 68000 device - it is a 32-bit processor with 32-bit registers and 32-bit instructions, but the first implementations had 16-bit ALUs, and on some members of the family you can happily use an external 8-bit bus. It's a 32-bit processor. So I'm with you on this one Bart - it's the user-visible ISA that matters, not the internal implementation details or the external connections.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-30 21:53 +0000 |
| Message-ID | <10giedg$1jo6h$1@paganini.bofh.team> |
| In reply to | #395595 |
Michael S <already5chosen@yahoo.com> wrote:
>
> 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.
Philip stated that _all_ SDCC targets round up _BitInt size to
next byte. This is obvious behaviour for 8-bit processors.
For non-8 bit machines there are various tradeoff and it would
be interesting if they choose byte granularity anyway.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-30 17:32 -0800 |
| Message-ID | <87ecpf9ec0.fsf@example.invalid> |
| In reply to | #395595 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> 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.
Given 16-bit int, short is almost certain to be 16 bits as well.
char is requires to be at least 8 bits, short and int at least 16, and
long at least 32 (and long long at least 64).
Or is 8-bit short used in some non-conforming mode?
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 08:36 +0100 |
| Message-ID | <10gjghp$12rjd$1@dont-email.me> |
| In reply to | #395621 |
On 01/12/2025 02:32, Keith Thompson wrote: > Michael S <already5chosen@yahoo.com> writes: > [...] >> 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. > > Given 16-bit int, short is almost certain to be 16 bits as well. > > char is requires to be at least 8 bits, short and int at least 16, and > long at least 32 (and long long at least 64). > > Or is 8-bit short used in some non-conforming mode? > Some C compilers for 8-bit devices have non-conforming modes with 8-bit int. (I've seen one that, by default, had 16-bit int but did not promote 8-bit types to int for arithmetic. That caused some subtle problems for us.) I don't know if SDCC has such a mode (avr-gcc does). Generally, "short" is not used on 8-bit targets - it's simply not a useful type.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 11:37 +0000 |
| Message-ID | <10gjulf$18gnk$2@dont-email.me> |
| In reply to | #395624 |
On 01/12/2025 07:36, David Brown wrote:
> On 01/12/2025 02:32, Keith Thompson wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>>> 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.
>>
>> Given 16-bit int, short is almost certain to be 16 bits as well.
>>
>> char is requires to be at least 8 bits, short and int at least 16, and
>> long at least 32 (and long long at least 64).
>>
>> Or is 8-bit short used in some non-conforming mode?
>>
>
> Some C compilers for 8-bit devices have non-conforming modes with 8-bit
> int. (I've seen one that, by default, had 16-bit int but did not
> promote 8-bit types to int for arithmetic. That caused some subtle
> problems for us.) I don't know if SDCC has such a mode (avr-gcc does).
That sounds sensible to me. It's how my language for Z80 worked (and
that carried on into x86 until I introduced promotions).
If performing arithmetic on two 8-bit variables, on a machine with poor
16-bit support, you don't want the inefficiency of promoting both to
16-bit (needing extra instructions), doing the operation at 16 bits
(which may need extra instructions), and then probably discarding the
high byte anyway.
There were some issues with that, that you had to be aware of:
byte a := 255
print a + 1
This would show 0 not 256.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 14:37 +0100 |
| Message-ID | <10gk5n9$1bg69$3@dont-email.me> |
| In reply to | #395627 |
On 01/12/2025 12:37, bart wrote: > On 01/12/2025 07:36, David Brown wrote: >> On 01/12/2025 02:32, Keith Thompson wrote: >>> Michael S <already5chosen@yahoo.com> writes: >>> [...] >>>> 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. >>> >>> Given 16-bit int, short is almost certain to be 16 bits as well. >>> >>> char is requires to be at least 8 bits, short and int at least 16, and >>> long at least 32 (and long long at least 64). >>> >>> Or is 8-bit short used in some non-conforming mode? >>> >> >> Some C compilers for 8-bit devices have non-conforming modes with >> 8-bit int. (I've seen one that, by default, had 16-bit int but did >> not promote 8-bit types to int for arithmetic. That caused some >> subtle problems for us.) I don't know if SDCC has such a mode >> (avr-gcc does). > > That sounds sensible to me. It's how my language for Z80 worked (and > that carried on into x86 until I introduced promotions). It is entirely sensible that a language designed for 8-bit devices should have 8-bit types for key arithmetic use. But we are not talking about a language designed for 8-bit devices, or any other language, we are talking about C. C has its language rules for how arithmetical operators work. You can question the wisdom of the integer promotions rules in C - I know that /I/ dislike some aspects of them. But like them or not, that is how C is defined. And a compiler that calls itself a C compiler but does not follow those rules is a broken tool that will cause unexpected problems with perfectly good C code. That is what I experienced with a particular so-called C compiler for an 8051 - it was expensive and pointlessly and dangerously non-conforming. I'd be happy if C did not have integer promotions. I'd be happy if it did not have implicit conversions between signed and unsigned types (as long as writing literals was still convenient) - or if conversions were always value preserving. But given the rules C has, I write my C code to be correct according to those rules - and I expect C compilers to implement according to those rules. I'm also happy with extra flags to change the behaviour (though I would often prefer pragmas, since those are tied tighter to the source code in question). If a compiler provides a "--ints-are-8-bit" or "--no-integer-promotions" flag, that's fair enough. But it should follow the standard rules unless told otherwise. (And yes, I /know/ that gcc does not follow all the rules of C by default and requires explicit flags to be conforming - that's a mistake on gcc's part IMHO.) > > If performing arithmetic on two 8-bit variables, on a machine with poor > 16-bit support, you don't want the inefficiency of promoting both to > 16-bit (needing extra instructions), doing the operation at 16 bits > (which may need extra instructions), and then probably discarding the > high byte anyway. I might not have been doing arithmetic on 8-bit systems /quite/ as long as you have, but this is not news to me. > > There were some issues with that, that you had to be aware of: > > byte a := 255 > print a + 1 > > This would show 0 not 256.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 14:14 +0000 |
| Message-ID | <10gk7sf$1cggk$1@dont-email.me> |
| In reply to | #395631 |
On 01/12/2025 13:37, David Brown wrote:
> I'd be happy if C did not have integer promotions.
Well, now it doesn't with _BitInt types. So this stores 0 in 'a', not 256:
int a;
unsigned _BitInt(8) b = 255, c = 1;
a = b + c;
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 16:28 +0100 |
| Message-ID | <10gkc68$1dvtp$2@dont-email.me> |
| In reply to | #395632 |
On 01/12/2025 15:14, bart wrote: > On 01/12/2025 13:37, David Brown wrote: > >> I'd be happy if C did not have integer promotions. > > Well, now it doesn't with _BitInt types. So this stores 0 in 'a', not 256: > > int a; > unsigned _BitInt(8) b = 255, c = 1; > a = b + c; > > Correct. There were a number of potential use-cases for _BitInt types that worked better without integer promotions, and it's easy enough to ask for the equivalent of integer promotions if you need them (by converting to int), so _BitInt types are exempt from integer promotions. Yes, I am glad there is now this choice in C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-30 12:39 +0100 |
| Message-ID | <10ghae1$8ooq$4@dont-email.me> |
| In reply to | #395580 |
On 29/11/2025 23:41, Waldek Hebisch wrote: > 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. > The "bit width" of the processor is not particularly important here (it's also not really a well-defined term). The three things that matter for the choice of "chunk size" are : 1. The minimum size of data that can be addresses. For all SDCC targets (AFAIK), as well as all gcc targets, that is 8-bit bytes. For some C targets, like some DSP's, it is bigger. 2. The size for maximum efficiency when working with larger data. For an 8051 (targeted by SDCC) or an AVR (the only 8-bit gcc target), that's 8 bits. For an x86-64 processor, it would be 64-bit. 3. How much users of the target are bothered about memory sizes. Clearly the chunk size cannot be smaller than the size from issue 1 - thus "unsigned char" will be the minimum. And there is nothing to be gained by going bigger than the size from issue 2. For most devices where you are concerned about saving a byte or two, you typically operate on 8-bit operands anyway, so your chunk size is 8 bits. And that's what I'd expect on the AVR too (noting that gcc for the AVR does not yet support _BitInt's, and I don't think clang has a working AVR backend as yet. At least, it is not on godbolt!).
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-24 14:10 +0200 |
| Message-ID | <20251124141033.00000628@yahoo.com> |
| In reply to | #395396 |
On Mon, 24 Nov 2025 00:30:46 +0000 bart <bc@freeuk.com> wrote: > > It is an unnecessary complication. There will be a lot of extra rules > that maybe partly 'implementation defined', so behaviour may vary. > And people WILL uses those types because they are there, and likely > they will be inefficient. > > What happens when a 391-bit type, even unsigned, overflows? These > larger types are likely to use a multiple of 64-bits, and for 391 > bits will need 7 x 64 bits, of which the last word will have 57 bits > of padding. It's very messy. To me, it does not sound as a problem at all, at least for unsigned types. Masking out unnecessary MS bits in MS word is easy. Even for signed, sign extension of MS word is not as easy, as masking out, but hardly a rocket science. The problem with signed is that signed overflow is a saint cow of the temple of worshipers of nazal demons. So, authors of proposal were afraid of touching it. > > Specifying a multiple of 64 bits is better; a power of two even > better. > I strongly disagree. Being able to specify, say, 192-bit integers is a useful thing. Esp. in context of multiplication and division.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 04:29 -0800 |
| Message-ID | <87ikez4ns0.fsf@example.invalid> |
| In reply to | #395396 |
bart <bc@freeuk.com> writes:
> On 23/11/2025 22:38, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 23/11/2025 13:32, Waldek Hebisch wrote:
>>>> Philipp Klaus Krause <pkk@spth.de> wrote:
>>>>> Am 22.10.25 um 14:45 schrieb Thiago Adams:
>>>>>> Is anyone using or planning to use this new C23 feature?
>>>>>> What could be the motivation?
>>>>>
>>>>> Saving memory by using the smallest multiple-of-8 N that will do.
>>>> IIUC nothing in the standard says that it is smallest multiple-of-8.
>>>> Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
>>>> while the number cound fit in 3 bytes.
>>>
>>> The rationale mentions a use-case where there is a custom processor
>>> that might actually have a 22-bit hardware types.
>> What rationale are you referring to? There hasn't been an official
>> ISO C Rationale document since C99.
>
> See Introduction and Rationale here:
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf
Thanks.
>>> Implementing such odd-size types on regular 8/16/32/64-bit hardware is
>>> full of problems if you want to do it without padding (in order to get
>>> the savings). On even with padding (to get the desired overflow
>>> semantics).
>>>
>>> Such as working out how pointers to them will work.
>> Why would pointers to _BitInt types be a problem? A _BitInt object
>> is a fixed-size chunk of memory, similar to a struct object.
>
> 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.
That part of the rationale appears to be specific to FPGA hardware, not
something I know much about.
> For example, an array of 1M 5-bit values would occupy 1M 8-bit bytes,
> but storing packed values means it would use only 625K bytes.
>
> Anyway, pointers to individual values, or to some arbitrary element or
> slice of such an array, would need some extra info.
On the implementations I have access to (gcc and clang), a _BitInt
object is an ordinary object, with a size that's whole number of bytes.
`unsigned _BitInt(4)`, for example, has 4 value bits and 4 padding bits.
(Unless it's a bit-field, but that doesn't give you packed arrays.)
I can see the benefit of tightly packing multiple bit-precise
integers into an array, but I don't see a way to do that, either
with the current gcc and llvm/clang implementations or with the C
memory model.
>>>>> Also being able to use bit-fields wider than int.
>>>> For me main gain is reasonably standard syntax for integers bigger
>>>> that 64 bits.
>>>
>>> Standard syntax I guess would be something like int128_t and
>>> int256_t. Such wider integers tend to be powers of two.
>>>
>>> But there are two problems with _BitInt:
>>>
>>> * Any odd sizes are allowed, such as _BitInt(391)
>> Why is that a problem? If you don't want odd-sized types, don't use
>> them.
>
> It is an unnecessary complication. There will be a lot of extra rules
> that maybe partly 'implementation defined', so behaviour may vary. And
> people WILL uses those types because they are there, and likely they
> will be inefficient.
Imposing arbitrary restrictions would introduce more unnecessary
complication. As far as I've been able to tell, odd-sized _BitInt types
are already implemented (though I've done very little testing).
> What happens when a 391-bit type, even unsigned, overflows? These
> larger types are likely to use a multiple of 64-bits, and for 391 bits
> will need 7 x 64 bits, of which the last word will have 57 bits of
> padding. It's very messy.
An unsigned _BitInt(391) value wraps around modulo 2**391. In the
current gcc and clang implementations, it has a size of 56 bytes, with
391 value bits and 57 value bits. It doesn't seem to be a problem in
practice.
> Specifying a multiple of 64 bits is better; a power of two even better.
Then by all means do so. Operations on _BitInt(448) or _BitInt(512)
might even be more efficient than operations on _BitInt(391).
If you want the language to restrict allowed widths, how exactly
would you specify it? Would you allow 32 but not 33? 64 but
not 65? 72? 80?
You can impose whatever restrictions you like in your own code.
>>> * There appears to be no upper limit on size, so _BitInt(2997901) is a
>>> valid type
>> The upper limit is specified by the implementation as
>> BITINT_MAXWIDTH, a macro defined in <limits.h>. For gcc 15.2.0 on
>> x86_64, BITINT_MAXWIDTH is 65535 (2**16-1). For clang 21.1.5 it's
>> 8388608 (2**23 bits, 1048576 bytes). clang seems to have some
>> problems with _BitInt(8388608). For example, this program: #include
>> <limits.h> _BitInt(BITINT_MAXWIDTH) n = 42;
>> int main(void) {
>> n *= n;
>> }
>> takes a *long* time to compile with clang. I believe it's generating
>> inline code to do the 8388608 by 8388608 bit multiplication.
>
> Now try it with two disparate sizes.
Why? llvm/clang currently has a known problem with multiplication
and division on very large _BitInt types. It shouldn't be too
difficult for them to correct it. Operations on disparate sizes
don't add much complexity (the narrower operand is promoted to the
wider type).
If you're curious, here's the bug report (I've commented on it),
but it's an implementation issue, not a language issue.
https://github.com/llvm/llvm-project/issues/126384
>>> So what is the result type of multiplying values of those two types?
>> _BitInt types are exempt from the integer promotion rules (so
>> _BitInt(3) doesn't promote to int), but the usual arithmetic
>> conversions apply. If you multiply values of two _BitInt types, the
>> result is the wider of the two types.
>
> So multiplying even two one-million-bit types could overflow!
Of course. These are fixed-width types, not arbitrary precision types.
If you want to multiply two _BitInt(1'000'000) values without overflow,
you can convert to _BitInt(2'000'000) -- if the compiler supports it.
(Don't expect the code to be efficient, at least for now.)
> Such limits for /fixed-width/ integers are ridiculous.
I acknowledge that you think so.
I honestly don't know why the gcc maintainers felt it was worthwhile
to support _BitInt types up to 65535 bits, or why the llvm/clang
maintainers decided to support up to 8388608 bits. But that's
what they've done, and again, you don't have to use it if you don't
want to. There could easily be a perfectly valid reason that you
and I are not aware of.
It's likely that implementing million-bit integers isn't
significantly harder than implementing thousand-bit integers.
Bit-precise integers up to, say, 128 or 256 bits seem to be
implemented reasonably efficiently. How exactly does the fact that
compilers support much wider types inconvenience you?
> You might say this is no different from defining an array of exactly
> 123,456 elements. But the use-cases are very different.
>
> I starting going into details but I guess you don't care about such
> matters or whether the feature makes much sense.
On the contrary, I'm curious about it. But if two different compiler
teams have already done the work of implementing bit-precise
integers with extremely large and/or odd widths, I can think of
no reason to complain about it. Even if it doesn't make sense,
I didn't have to do the work of implementing it.
Incidentally, something odd happens to quoted text in your followups.
Blank lines are lost, and paragraphs are reformatted oddly, often
with alternating long and short lines. Is your newsreader doing
that, or is it something else? Can you do something about it?
--
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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-23 21:39 -0600 |
| Message-ID | <10g0k70$22deu$1@dont-email.me> |
| In reply to | #395387 |
On 11/23/2025 7:59 AM, bart wrote:
> On 23/11/2025 13:32, Waldek Hebisch wrote:
>> Philipp Klaus Krause <pkk@spth.de> wrote:
>>> Am 22.10.25 um 14:45 schrieb Thiago Adams:
>>>>
>>>>
>>>> Is anyone using or planning to use this new C23 feature?
>>>> What could be the motivation?
>>>>
>>>>
>>>
>>> Saving memory by using the smallest multiple-of-8 N that will do.
>>
>> IIUC nothing in the standard says that it is smallest multiple-of-8.
>> Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
>> while the number cound fit in 3 bytes.
>
> The rationale mentions a use-case where there is a custom processor that
> might actually have a 22-bit hardware types.
>
> Implementing such odd-size types on regular 8/16/32/64-bit hardware is
> full of problems if you want to do it without padding (in order to get
> the savings). On even with padding (to get the desired overflow semantics).
>
> Such as working out how pointers to them will work.
>
In BGBCC, for any size <= 256 bits, it is padded to the next power-of-2
size. Although if the size is NPOT, some extra handling exists to
mask/extend it to the requested size.
Sizes larger than 256 are padded to the next multiple of 128 bits.
IIRC, GCC and Clang use smaller padding, but not looked into it.
>
>>> Also
>>> being able to use bit-fields wider than int.
>>
>> For me main gain is reasonably standard syntax for integers bigger
>> that 64 bits.
>
> Standard syntax I guess would be something like int128_t and int256_t.
> Such wider integers tend to be powers of two.
>
> But there are two problems with _BitInt:
>
> * Any odd sizes are allowed, such as _BitInt(391)
>
> * There appears to be no upper limit on size, so _BitInt(2997901) is a
> valid type
>
In BGBCC, there is a hard limit of IIRC 16384 bits.
As an extension, it also allows for very large literals, though
currently literals larger than 128 bits can only use hexadecimal or similar.
This is encoded via suffixes, eg:
I, L, LL, U, UI, UL, ULL: Normal 32/64 bit.
I128, UI128: 128-bit
I256, UI256: 256-bit
other odd sizes map to _BitInt or _UBitInt (unsigned _BitInt).
Larger decimal numbers could be supported, but for now I don't have a
strong need for decimal literals beyond 128 bits.
Implicitly, there is a limit of around 1K bits for literals mostly due
to normal tokens having a limit of 255 characters. Compound string
literals have a higher limit of 4096 (standard) or 65536 (implementation).
Possibly, as a little bit of wonk, internally large literals are
implemented in the compiler on top of Base85 strings.
Where, say, for integer literals:
48 bits or less: Stored directly in compiler-specific tagrefs;
49-64 bits: Encoded via an index into a lookup table.
65-128 bits: Split into a pair of 64-bit chunks as indices into a lookup
table;
129+: String cosplaying as an integer literal.
> So what is the result type of multiplying values of those two types?
>
Typically the max of either input type...
> Integer sizes greater than 1K or 2K bits should use an arbitrary
> precision type (which is how large _BitInts will likely be implemented
> anyway), where the precision is a runtime attribute.
>
Disagree, this would open up a whole big mess.
Can't have this for similar reasons to why one doesn't have
variable-sized structs.
Decided to leave out the whole VLA mess.
Better to just pretend VLAs don't exist.
...
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-24 11:45 +0000 |
| Message-ID | <10g1gge$2b2cf$2@dont-email.me> |
| In reply to | #395399 |
On 24/11/2025 03:39, BGB wrote: > On 11/23/2025 7:59 AM, bart wrote: >> On 23/11/2025 13:32, Waldek Hebisch wrote: >>> Philipp Klaus Krause <pkk@spth.de> wrote: >>>> Am 22.10.25 um 14:45 schrieb Thiago Adams: >>>>> >>>>> >>>>> Is anyone using or planning to use this new C23 feature? >>>>> What could be the motivation? >>>>> >>>>> >>>> >>>> Saving memory by using the smallest multiple-of-8 N that will do. >>> >>> IIUC nothing in the standard says that it is smallest multiple-of-8. >>> Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4, >>> while the number cound fit in 3 bytes. >> >> The rationale mentions a use-case where there is a custom processor >> that might actually have a 22-bit hardware types. >> >> Implementing such odd-size types on regular 8/16/32/64-bit hardware is >> full of problems if you want to do it without padding (in order to get >> the savings). On even with padding (to get the desired overflow >> semantics). >> >> Such as working out how pointers to them will work. >> > > In BGBCC, for any size <= 256 bits, it is padded to the next power-of-2 > size. Although if the size is NPOT, some extra handling exists to mask/ > extend it to the requested size. There are two kinds of BitInts: those smaller than 64 bits; and those larger than 64 bits, sometimes /much/ larger. I had been responding to the claim that those smaller types save memory, compared to using sizes 8/16/32 bits which are commonly available and have better hardware support. But if a _BitInt(17) is rounded up to 32 bits, there's not going to be any saving! Here, I wouldn't use the type system at all to define odd-sized fields. C already has bitfields within structs, that can be used to efficiently pack odd-sized data. But they have lots of restrictions, and are not an independent type. (In my stuff, I do the same, but with more control. I also have bitfield-operators that work within ordinary integers. And, in one language, arrays of 1/2/4 bits. But again none of these bitfields of sub-byte elements are proper types, although those u1/u2/u4 elements come close.) > In BGBCC, there is a hard limit of IIRC 16384 bits. > > > As an extension, it also allows for very large literals, though > currently literals larger than 128 bits can only use hexadecimal or > similar. > > This is encoded via suffixes, eg: > I, L, LL, U, UI, UL, ULL: Normal 32/64 bit. > I128, UI128: 128-bit > I256, UI256: 256-bit > other odd sizes map to _BitInt or _UBitInt (unsigned _BitInt). > > > Larger decimal numbers could be supported, but for now I don't have a > strong need for decimal literals beyond 128 bits. I did once have a very nice 128-bit type in my systems language, but it didn't get enough use to be worth supporting. It was awkward to implement too, since each value type took up two registers, or two stack slots (in some cases, one of each!) But my scripting language has an arbitrary-precision /decimal/ floating point type, which can also be used for pure integer calculations. I think the maximum range is 10**19000000000 (and a matching minimum). Precision is limited only by memory and runtime, but there are usually caps in place otherwise evaluating 1/3 would go on forever. This is one is actually more useful and a lot of fun.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-24 13:57 +0200 |
| Message-ID | <20251124135731.00006cc6@yahoo.com> |
| In reply to | #395404 |
On Mon, 24 Nov 2025 11:45:18 +0000 bart <bc@freeuk.com> wrote: > > But my scripting language has an arbitrary-precision /decimal/ > floating point type, which can also be used for pure integer > calculations. > Arbitrary-precision floating point? That sounds problematic, regardless of base. Unless you don't use the word 'arbitrary' in the same sense that it is used, for example, in GMP. Gnu MPFR is very careful to never call itself "arbitrary-precision" in official docs.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-24 12:56 +0000 |
| Message-ID | <10g1kmp$2deh9$2@dont-email.me> |
| In reply to | #395405 |
On 24/11/2025 11:57, Michael S wrote:
> On Mon, 24 Nov 2025 11:45:18 +0000
> bart <bc@freeuk.com> wrote:
>>
>> But my scripting language has an arbitrary-precision /decimal/
>> floating point type, which can also be used for pure integer
>> calculations.
>>
>
> Arbitrary-precision floating point? That sounds problematic, regardless
> of base. Unless you don't use the word 'arbitrary' in the same sense
> that it is used, for example, in GMP.
> Gnu MPFR is very careful to never call itself "arbitrary-precision" in
> official docs.
>
If you mean problems like repeated multiplies giving ever larger
numbers, then that will happen also with integers (or rationals).
If you mean the problems with a divide operation potentially carrying on
indefinitely, then a cap needs to be set on that.
I haven't attempted libraries for working out trancendental functions;
the problems there are in getting a particular precision even if you
know that in advance.
But for basic arithmetic, it works extremely well.
(While it is built-in to my scripting language, it was originally a
standalone library and has been ported to C. See the bignum.c and
bignum.h files here:
https://github.com/sal55/langs/tree/master/bignum
You can try out division like this:
#include <stdio.h>
#include "bignum.h"
int main() {
Bignum a, b, c;
a = bn_makeint(1);
b = bn_makeint(7);
c = bn_init();
bn_div(c, a, b, 1000);
bn_println(c);
}
(Build as 'gcc prog.c bignum.c' etc.)
You can see that 'bn_div' needs a precision argument: this is the number
of significant decimal digits. Using 100M here produced 100 million
digits and took about 6 seconds.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-24 15:17 +0200 |
| Message-ID | <20251124151749.00004b91@yahoo.com> |
| In reply to | #395410 |
On Mon, 24 Nov 2025 12:56:58 +0000
bart <bc@freeuk.com> wrote:
> On 24/11/2025 11:57, Michael S wrote:
> > On Mon, 24 Nov 2025 11:45:18 +0000
> > bart <bc@freeuk.com> wrote:
> >>
> >> But my scripting language has an arbitrary-precision /decimal/
> >> floating point type, which can also be used for pure integer
> >> calculations.
> >>
> >
> > Arbitrary-precision floating point? That sounds problematic,
> > regardless of base. Unless you don't use the word 'arbitrary' in
> > the same sense that it is used, for example, in GMP.
> > Gnu MPFR is very careful to never call itself "arbitrary-precision"
> > in official docs.
> >
>
> If you mean problems like repeated multiplies giving ever larger
> numbers, then that will happen also with integers (or rationals).
>
> If you mean the problems with a divide operation potentially carrying
> on indefinitely, then a cap needs to be set on that.
>
Yes, that what I meant.
> I haven't attempted libraries for working out trancendental
> functions; the problems there are in getting a particular precision
> even if you know that in advance.
>
> But for basic arithmetic, it works extremely well.
>
> (While it is built-in to my scripting language, it was originally a
> standalone library and has been ported to C. See the bignum.c and
> bignum.h files here:
>
> https://github.com/sal55/langs/tree/master/bignum
>
> You can try out division like this:
>
> #include <stdio.h>
> #include "bignum.h"
>
> int main() {
> Bignum a, b, c;
>
> a = bn_makeint(1);
> b = bn_makeint(7);
> c = bn_init();
>
> bn_div(c, a, b, 1000);
> bn_println(c);
> }
>
> (Build as 'gcc prog.c bignum.c' etc.)
>
> You can see that 'bn_div' needs a precision argument: this is the
> number of significant decimal digits. Using 100M here produced 100
> million digits and took about 6 seconds.)
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-24 15:59 +0100 |
| Message-ID | <10g1rst$2f8lb$5@dont-email.me> |
| In reply to | #395413 |
On 24/11/2025 14:17, Michael S wrote: > On Mon, 24 Nov 2025 12:56:58 +0000 > bart <bc@freeuk.com> wrote: > >> On 24/11/2025 11:57, Michael S wrote: >>> On Mon, 24 Nov 2025 11:45:18 +0000 >>> bart <bc@freeuk.com> wrote: >>>> >>>> But my scripting language has an arbitrary-precision /decimal/ >>>> floating point type, which can also be used for pure integer >>>> calculations. >>>> >>> >>> Arbitrary-precision floating point? That sounds problematic, >>> regardless of base. Unless you don't use the word 'arbitrary' in >>> the same sense that it is used, for example, in GMP. >>> Gnu MPFR is very careful to never call itself "arbitrary-precision" >>> in official docs. >>> >> >> If you mean problems like repeated multiplies giving ever larger >> numbers, then that will happen also with integers (or rationals). >> >> If you mean the problems with a divide operation potentially carrying >> on indefinitely, then a cap needs to be set on that. >> > > Yes, that what I meant. > I remember a fun programming task at university in a language similar to Haskell, which involved writing an arbitrary precision fixed-point decimal arithmetic package. It included support for an infinite polynomial expansion for arctan, and then use a Maclin-like formula to get a "value" for pi. It all worked well, as long as you remembered to limit how many digits you printed out...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 05:35 -0800 |
| Message-ID | <87tsyj3659.fsf@example.invalid> |
| In reply to | #395404 |
bart <bc@freeuk.com> writes:
[...]
> There are two kinds of BitInts: those smaller than 64 bits; and those
> larger than 64 bits, sometimes /much/ larger.
As far as I know, the standard makes no such distinction.
> I had been responding to the claim that those smaller types save
> memory, compared to using sizes 8/16/32 bits which are commonly
> available and have better hardware support.
I don't recall any such claim. Do you have a citation (other than
the FPGA-specific wording in N2709)?
> But if a _BitInt(17) is rounded up to 32 bits, there's not going to be
> any saving!
Correct.
[...]
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-24 14:21 +0000 |
| Message-ID | <10g1pl3$2fi66$1@dont-email.me> |
| In reply to | #395416 |
On 24/11/2025 13:35, Keith Thompson wrote: > bart <bc@freeuk.com> writes: > [...] >> There are two kinds of BitInts: those smaller than 64 bits; and those >> larger than 64 bits, sometimes /much/ larger. > > As far as I know, the standard makes no such distinction. *I* am making the distinction. From an implementation point of view (and assuming 64-bit hardware), they are quite different. And that leads to different kinds of language features. If the possibilities above 64 bits were less ambitious (say i128 and i256), then the concept might be stretched to cover both. But not when when you can also have i1234567. It would be having a GETBITS macro, which is not limited to a 1- to 63-bit bitfield of a u64 value, but could return a slice of an arbitrarily large array. > >> I had been responding to the claim that those smaller types save >> memory, compared to using sizes 8/16/32 bits which are commonly >> available and have better hardware support. > > I don't recall any such claim. Do you have a citation (other than > the FPGA-specific wording in N2709)? This is where it came up in this thread: On 23/11/2025 11:46, Philipp Klaus Krause wrote: > Am 22.10.25 um 14:45 schrieb Thiago Adams: >> >> >> Is anyone using or planning to use this new C23 feature? >> What could be the motivation? >> >> > > Saving memory by using the smallest multiple-of-8 N that will do. Also > being able to use bit-fields wider than int. > > Saving memory for two reasons: > > * On small embedded systems where there is very little memory > * For code that needs to be very fast on big systems to make data > structures fit into cache > Although this doesn't go as far as using odd bit-sizes: it would mean using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 bits. The savings would be sparse.
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web