Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #81289 > unrolled thread
| Started by | c186282 <c186282@nnada.net> |
|---|---|
| First post | 2026-01-18 23:10 -0500 |
| Last post | 2026-01-21 04:14 +0000 |
| Articles | 20 on this page of 158 — 19 participants |
Back to article view | Back to comp.os.linux.misc
Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-18 23:10 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-01-19 11:00 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-19 17:33 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-01-20 12:05 +0000
Re: Python: A Little Trick For Every Need Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-20 19:01 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-01-20 20:42 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-20 18:22 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-20 18:05 -0500
Re: Python: A Little Trick For Every Need Steve Hayes <hayesstw@telkomsa.net> - 2026-01-20 05:04 +0200
Re: Python: A Little Trick For Every Need Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-20 03:11 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-19 23:21 -0500
Re: Python: A Little Trick For Every Need John Bokma <contact@johnbokma.com> - 2026-01-20 14:25 +0100
Re: Python: A Little Trick For Every Need candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-01-20 14:30 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-19 22:59 -0500
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-01-20 08:42 +0000
Re: Python: A Little Trick For Every Need Steve Hayes <hayesstw@telkomsa.net> - 2026-01-20 12:17 +0200
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-01-20 17:13 +0000
Re: Python: A Little Trick For Every Need ram@zedat.fu-berlin.de (Stefan Ram) - 2026-01-20 17:40 +0000
Re: Python: A Little Trick For Every Need Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-01-20 19:01 +0000
Re: Python: A Little Trick For Every Need John Ames <commodorejohn@gmail.com> - 2026-01-20 10:18 -0800
Re: Python: A Little Trick For Every Need Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-20 20:16 +0000
Re: Python: A Little Trick For Every Need Steve Hayes <hayesstw@telkomsa.net> - 2026-01-21 07:55 +0200
Re: Python: A Little Trick For Every Need Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-21 08:25 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-21 22:47 -0500
Re: Python: A Little Trick For Every Need John Ames <commodorejohn@gmail.com> - 2026-01-22 08:42 -0800
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-01-20 21:33 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-20 18:27 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-20 18:02 -0500
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-01-21 06:50 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-21 22:49 -0500
Re: Python: A Little Trick For Every Need Rich <rich@example.invalid> - 2026-02-02 14:50 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-02 15:07 +0000
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-02-02 21:19 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-02 21:03 -0500
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-03 08:52 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-03 12:57 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-03 13:53 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 11:51 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 22:09 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-02 20:50 -0500
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-02-03 02:58 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-02 22:23 -0500
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-02-03 19:57 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 11:52 +0000
Re: Python: A Little Trick For Every Need Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2026-02-02 20:20 -0800
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-03 00:18 -0500
Re: Python: A Little Trick For Every Need Robert Riches <spamtrap42@jacob21819.net> - 2026-02-04 04:18 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-03 23:45 -0500
Re: Python: A Little Trick For Every Need Robert Riches <spamtrap42@jacob21819.net> - 2026-02-04 05:14 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 00:51 -0500
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-04 08:24 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 11:56 +0000
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-04 14:50 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 16:44 +0000
Re: Python: A Little Trick For Every Need John Ames <commodorejohn@gmail.com> - 2026-02-04 09:15 -0800
Re: Python: A Little Trick For Every Need Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-04 19:26 +0000
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 22:00 +0000
Re: Python: A Little Trick For Every Need Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-05 08:32 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 23:02 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 21:58 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 22:34 -0500
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-04 19:58 +0000
Re: Python: A Little Trick For Every Need Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-04 15:09 -0500
Re: Python: A Little Trick For Every Need Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2026-02-04 13:05 -0800
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 22:04 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 23:54 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-04 22:03 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 23:49 -0500
Re: Python: A Little Trick For Every Need Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-05 08:29 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-02-05 14:06 +0000
Re: Python: A Little Trick For Every Need Pancho <Pancho.Jones@protonmail.com> - 2026-02-05 14:59 +0000
C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-05 08:06 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-05 16:33 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-05 18:12 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:40 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-06 04:54 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-05 17:33 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-05 09:57 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-06 04:12 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-06 00:03 -0500
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-06 11:28 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-06 20:03 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-06 20:59 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-06 13:55 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-06 22:29 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-06 14:43 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-07 15:36 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-07 20:49 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-07 21:26 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-07 22:00 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-09 06:53 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-08 01:55 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Nuno Silva <nunojsilva@invalid.invalid> - 2026-02-08 08:30 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-09 06:53 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-08 11:04 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-08 20:07 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-13 11:30 -0800
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-13 21:40 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-13 21:48 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-14 07:06 -0500
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-14 00:41 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-02-14 07:16 -0500
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-07 11:53 +0000
Re: C/C++ timeline (was Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-09 09:21 -0800
Re: Python: A Little Trick For Every Need Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-05 22:38 +0000
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-02-06 05:05 +0000
Re: Python: A Little Trick For Every Need Andreas Eder <a_eder_muc@web.de> - 2026-02-05 15:55 +0100
Re: Python: A Little Trick For Every Need rbowman <bowman@montana.com> - 2026-02-05 17:26 +0000
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-04 22:12 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 23:35 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 22:16 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 22:13 -0500
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-02-04 21:42 -0500
Re: Python: A Little Trick For Every Need Richard Kettlewell <invalid@invalid.invalid> - 2026-02-05 09:28 +0000
Memory Safety (Re: Python: A Little Trick For Every Need) Lars Poulsen <lars@beagle-ears.com> - 2026-02-05 13:45 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-05 14:14 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Pancho <Pancho.Jones@protonmail.com> - 2026-02-05 15:09 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-05 16:03 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Pancho <Pancho.Jones@protonmail.com> - 2026-02-06 22:32 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-07 01:12 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-06 21:59 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-07 12:15 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-07 16:01 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Richard Kettlewell <invalid@invalid.invalid> - 2026-02-07 11:09 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-07 12:10 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-05 19:27 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-05 20:51 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-06 10:45 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-06 21:44 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-07 12:29 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-07 16:31 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-08 10:25 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-08 20:13 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-08 22:39 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-09 04:58 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-09 10:04 -0800
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-09 23:39 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-10 08:00 -0800
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-10 23:02 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-11 06:57 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-11 20:22 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-12 04:48 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-12 01:04 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-12 12:52 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) rbowman <bowman@montana.com> - 2026-02-12 21:36 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-02-13 00:02 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-13 00:09 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-13 10:18 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) John Ames <commodorejohn@gmail.com> - 2026-02-09 09:56 -0800
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-05 20:48 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-06 10:42 +0000
Re: Memory Safety (Re: Python: A Little Trick For Every Need) c186282 <c186282@nnada.net> - 2026-02-06 21:31 -0500
Re: Memory Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-07 12:23 +0000
Memory Allocatiuon Safety (Re: Python: A Little Trick For Every Need) Lars Poulsen <lars@beagle-ears.com> - 2026-02-05 13:37 +0000
Re: Memory Allocatiuon Safety (Re: Python: A Little Trick For Every Need) The Natural Philosopher <tnp@invalid.invalid> - 2026-02-05 14:03 +0000
Re: Python: A Little Trick For Every Need Nuno Silva <nunojsilva@invalid.invalid> - 2026-01-20 10:16 +0000
Re: Python: A Little Trick For Every Need c186282 <c186282@nnada.net> - 2026-01-20 17:58 -0500
Re: Python: A Little Trick For Every Need The Natural Philosopher <tnp@invalid.invalid> - 2026-01-21 04:14 +0000
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-06 21:59 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <lrqcnbCdO-AWNxv0nZ2dnZfqn_WdnZ2d@giganews.com> |
| In reply to | #81808 |
On 2/6/26 20:12, Lawrence D’Oliveiro wrote: > On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote: > >> I was assuming the hardware stack was more than just a register, and >> memory. i.e. I assumed there were specific pop/push instructions >> which were optimised to get data and adjust a register stack pointer >> as a single instruction. > > Some common architectures have no hardware stack: the stack convention > comes purely from the software ABI. E.g. POWER/PowerPC. > >> So there would be a performance hit in a software stack where >> multiple instructions would be needed. > > I remember, back in the days of the VAX, which was the classic machine > with the “kitchen-sink” instruction set in the 1980s -- an instruction > for just about everything, including pushing and popping stack > elements. You could save the lowest 6 general-purpose registers with > just one PUSHR instruction (2 bytes), or you could do it with 6 > separate PUSHL instructions (2 × 6 = 12 bytes). Guess which was > faster? The TMS-9900 had a couple of similar instructions so you could shove ALL the registers onto a stack before branching or whatever. Odd chip - sort of a hardware solution to multiple users.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-07 12:15 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m7ace$10ebk$5@dont-email.me> |
| In reply to | #81812 |
On 07/02/2026 02:59, c186282 wrote: > On 2/6/26 20:12, Lawrence D’Oliveiro wrote: >> On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote: >> >>> I was assuming the hardware stack was more than just a register, and >>> memory. i.e. I assumed there were specific pop/push instructions >>> which were optimised to get data and adjust a register stack pointer >>> as a single instruction. >> >> Some common architectures have no hardware stack: the stack convention >> comes purely from the software ABI. E.g. POWER/PowerPC. >> >>> So there would be a performance hit in a software stack where >>> multiple instructions would be needed. >> >> I remember, back in the days of the VAX, which was the classic machine >> with the “kitchen-sink” instruction set in the 1980s -- an instruction >> for just about everything, including pushing and popping stack >> elements. You could save the lowest 6 general-purpose registers with >> just one PUSHR instruction (2 bytes), or you could do it with 6 >> separate PUSHL instructions (2 × 6 = 12 bytes). Guess which was >> faster? > > The TMS-9900 had a couple of similar instructions > so you could shove ALL the registers onto a stack > before branching or whatever. Odd chip - sort of > a hardware solution to multiple users. > Yes indeed. A context switch was enormously efficient. It wasn't so much (IIRC) a question of having all the registers pushed into a stack so much as not having registers in the first place - these being instead locations in memory pointed to by a master register, which you could change and thereby have a completely new context. Thus general instructions were slow, but context switches were blindingly fast. a real minicomputer architecture I may be wrong about that., Its been a long time. -- “It is not the truth of Marxism that explains the willingness of intellectuals to believe it, but the power that it confers on intellectuals, in their attempts to control the world. And since...it is futile to reason someone out of a thing that he was not reasoned into, we can conclude that Marxism owes its remarkable power to survive every criticism to the fact that it is not a truth-directed but a power-directed system of thought.” Sir Roger Scruton
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-07 16:01 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <tY-cnVdrWaOuNRr0nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #81820 |
On 2/7/26 07:15, The Natural Philosopher wrote: > On 07/02/2026 02:59, c186282 wrote: >> On 2/6/26 20:12, Lawrence D’Oliveiro wrote: >>> On Fri, 6 Feb 2026 22:32:14 +0000, Pancho wrote: >>> >>>> I was assuming the hardware stack was more than just a register, and >>>> memory. i.e. I assumed there were specific pop/push instructions >>>> which were optimised to get data and adjust a register stack pointer >>>> as a single instruction. >>> >>> Some common architectures have no hardware stack: the stack convention >>> comes purely from the software ABI. E.g. POWER/PowerPC. >>> >>>> So there would be a performance hit in a software stack where >>>> multiple instructions would be needed. >>> >>> I remember, back in the days of the VAX, which was the classic machine >>> with the “kitchen-sink” instruction set in the 1980s -- an instruction >>> for just about everything, including pushing and popping stack >>> elements. You could save the lowest 6 general-purpose registers with >>> just one PUSHR instruction (2 bytes), or you could do it with 6 >>> separate PUSHL instructions (2 × 6 = 12 bytes). Guess which was >>> faster? >> >> The TMS-9900 had a couple of similar instructions >> so you could shove ALL the registers onto a stack >> before branching or whatever. Odd chip - sort of >> a hardware solution to multiple users. >> > Yes indeed. A context switch was enormously efficient. > > It wasn't so much (IIRC) a question of having all the registers pushed > into a stack so much as not having registers in the first place - these > being instead locations in memory pointed to by a master register, which > you could change and thereby have a completely new context. > Thus general instructions were slow, but context switches were > blindingly fast. a real minicomputer architecture > > I may be wrong about that., Its been a long time. Ditto. The 9900 kept all the working registers in RAM (which was about as fast as on-chip at the time. Context switches were just re-pointing the "right now" register to another set of in-RAM registers. In principle it's not SO different from what is done now to support concurrent users, however putting it into a chip that small so long back was unique.
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <invalid@invalid.invalid> |
|---|---|
| Date | 2026-02-07 11:09 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <wwvh5rs6ca8.fsf@LkoBDZeT.terraraq.uk> |
| In reply to | #81806 |
Pancho <Pancho.Jones@protonmail.com> writes: > On 2/5/26 16:03, Richard Kettlewell wrote: >> Pancho <Pancho.Jones@protonmail.com> writes: >>> On 2/5/26 14:14, The Natural Philosopher wrote: >>>> The first is of course implementation specific. C can specify a data >>>> stack separate from a program stack and avoid code corruption, >>>> leaving only data corruption... >>> >>> Can it? Naively, I would have thought C was normally built on top of >>> native assembler function calls, which dictates a shared stack. >>> Obviously you could implement a function call independent of >>> assembler, but does anyone, in practice? >> >> You’d leave the call stack as it is (i.e. CALL and RET, on x86) and >> use another register to manage the data stack (maybe rbp on >> x86). I’ve never heard of anyone doing it for C but I don’t think >> there’s any fundamental obsctacle to it. It’d be a distinct ABI, so >> not particularly convenient to integrate into existing systems. > > I was assuming the hardware stack was more than just a register, and > memory. i.e. I assumed there were specific pop/push instructions which > were optimised to get data and adjust a register stack pointer as a > single instruction. So there would be a performance hit in a software > stack where multiple instructions would be needed. The call stack _does_ have specialized instructions: CALL and RET on x86. If you wanted to build your own call stack, replacing CALL would mean: - get return address into a register - decrement call stack pointer - store it to your call stack - jump to call target Four instructions instead of one, with dependencies on the first two. Emulating RET would take three instructions. For the data stack the situation is different. On x86 PUSH and POP exist, but even with the regular stack you don’t have to use them: you can adjust the stack pointer by the maximum amount needed on entry and exit and then use normal load/store instructions with relative addressing modes. That works just as well with any register. Compilers generally mix this strategy with PUSHes and POPs to some degree. As an example, https://godbolt.org/z/ac1rj9aGe: - PUSH/POP are used to preserve callee-saved registers (L2-5 and L31-34) - it directly modifies ESP to create/discard a stack frame (L6, L30) - it uses ESP-relative indirect addressing to store/retrieve d (L19, L26) - it also uses ESP-relative addressing to set the argument to report (L23, L28), rather than using PUSH, perhaps because it removes the need for a POP after the call. The above is quite x86-centric. - Some architectures have pre-increment and post-decrement address modes, in which case the emulated CALL/RET are each one instruction shorter and there are no special PUSH/POP instructions. Essentially you can use any register (or at least, any address register) as a stack pointer, although there is usually a platform convention about which you choose. - Some architectures use a link register for the most recent return address, meaning that calls to ‘leaf’ functions don’t touch call stack memory at all. -- https://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-07 12:10 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m7a3r$10ebk$4@dont-email.me> |
| In reply to | #81806 |
On 06/02/2026 22:32, Pancho wrote: > On 2/5/26 16:03, Richard Kettlewell wrote: >> Pancho <Pancho.Jones@protonmail.com> writes: >>> On 2/5/26 14:14, The Natural Philosopher wrote: >>>> The first is of course implementation specific. C can specify a data >>>> stack separate from a program stack and avoid code corruption, >>>> leaving only data corruption... >>> >>> Can it? Naively, I would have thought C was normally built on top of >>> native assembler function calls, which dictates a shared stack. >>> Obviously you could implement a function call independent of >>> assembler, but does anyone, in practice? >> >> You’d leave the call stack as it is (i.e. CALL and RET, on x86) and use >> another register to manage the data stack (maybe rbp on x86). I’ve never >> heard of anyone doing it for C but I don’t think there’s any fundamental >> obsctacle to it. It’d be a distinct ABI, so not particularly convenient >> to integrate into existing systems. >> > > I was assuming the hardware stack was more than just a register, and > memory. i.e. I assumed there were specific pop/push instructions which > were optimised to get data and adjust a register stack pointer as a > single instruction. So there would be a performance hit in a software > stack where multiple instructions would be needed. > Probably. Depends on the architecture "In Motorola 68000 (68k) assembly, Address Register Indirect with Pre-decrement is a powerful addressing mode used to point to data and automatically decrease the address pointer before access. This is commonly used for stack operations or iterating backward through memory (e.g., from end to beginning). " 8086 doesn't have such a feature: you would do a specific move register to address location and decrement address pointer. Or to be excessively arcane, swap the stack pointer with another register, push every thing into the data stack,m and then swap the pointer back before issuing a call. Or use the stack pointer as the data pointer using another register to store return addresses, Nothing about the C language itself specifies intermixing of the code space with the data space. > Looking at Google, it appears my simplistic view of pushing arguments > onto the stack is wrong anyway. There seems to be optimisations > involving using registers for the first few arguments (x86/64), more so > with RISK_V, only using the stack when necessary. I guess there are also > parallel instructions to push multiple registers onto a hardware stack > in one go. > Indeed. Gcc and pals will use all registers first and often avoid creating intermediate variables at all, If optimising for code space you can create subroutine stubs like STUB: POP CX STUB1: POP BX STUB2: POP AX RET and finish subroutines with a JMP to one of those labels. i,e have the compiler look for any sequence of the same instructions preceding a RET and replace then with a JMP ... > But I take your point about the protection of execute permission on > memory areas etc. Hardware is something most coders do not really understand and that's why they make mistakes. -- Religion is regarded by the common people as true, by the wise as foolish, and by the rulers as useful. (Seneca the Younger, 65 AD)
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-05 19:27 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m2qvk$3g6mr$1@dont-email.me> |
| In reply to | #81774 |
On 05/02/2026 15:09, Pancho wrote: > On 2/5/26 14:14, The Natural Philosopher wrote: > >> The first is of course implementation specific. C can specify a data >> stack separate from a program stack and avoid code corruption, leaving >> only data corruption... >> > > Can it? Naively, I would have thought C was normally built on top of > native assembler function calls, which dictates a shared stack. > Obviously you could implement a function call independent of assembler, > but does anyone, in practice? > You simply use a register as a second stack [data] pointer. Assign all your mem variables on that stack, and increment it at function end. The assembler is trivial. Making C do it that way would not be hard, either.. -- Religion is regarded by the common people as true, by the wise as foolish, and by the rulers as useful. (Seneca the Younger, 65 AD)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-05 20:51 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <AzqdneEsHuuI1Bj0nZ2dnZfqn_qdnZ2d@giganews.com> |
| In reply to | #81783 |
On 2/5/26 14:27, The Natural Philosopher wrote: > On 05/02/2026 15:09, Pancho wrote: >> On 2/5/26 14:14, The Natural Philosopher wrote: >> >>> The first is of course implementation specific. C can specify a data >>> stack separate from a program stack and avoid code corruption, >>> leaving only data corruption... >>> >> >> Can it? Naively, I would have thought C was normally built on top of >> native assembler function calls, which dictates a shared stack. >> Obviously you could implement a function call independent of >> assembler, but does anyone, in practice? >> > You simply use a register as a second stack [data] pointer. > > Assign all your mem variables on that stack, and increment it at > function end. > > The assembler is trivial. Making C do it that way would not be hard, > either.. I actually searched on that a little, could not see any civil way to specify a stack in a new segment in 'C'. ASM, yea, easier - you have total control (and total responsibility).
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-06 10:45 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m4go5$2gva$3@dont-email.me> |
| In reply to | #81789 |
On 06/02/2026 01:51, c186282 wrote:
> On 2/5/26 14:27, The Natural Philosopher wrote:
>> On 05/02/2026 15:09, Pancho wrote:
>>> On 2/5/26 14:14, The Natural Philosopher wrote:
>>>
>>>> The first is of course implementation specific. C can specify a data
>>>> stack separate from a program stack and avoid code corruption,
>>>> leaving only data corruption...
>>>>
>>>
>>> Can it? Naively, I would have thought C was normally built on top of
>>> native assembler function calls, which dictates a shared stack.
>>> Obviously you could implement a function call independent of
>>> assembler, but does anyone, in practice?
>>>
>> You simply use a register as a second stack [data] pointer.
>>
>> Assign all your mem variables on that stack, and increment it at
>> function end.
>>
>> The assembler is trivial. Making C do it that way would not be hard,
>> either..
>
> I actually searched on that a little, could
> not see any civil way to specify a stack in
> a new segment in 'C'.
>
Oh sure. You would have to modify the compiler
But IIRC the first PDP I worked on had 64k data and 64k code in entirely
different bits of RAM.
> ASM, yea, easier - you have total control (and
> total responsibility).
>
Of course. That's what it teaches you....
--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."
George Santayana
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-06 21:44 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <o4ydnXhp5LaBOhv0nZ2dnZfqnPednZ2d@giganews.com> |
| In reply to | #81795 |
On 2/6/26 05:45, The Natural Philosopher wrote: > On 06/02/2026 01:51, c186282 wrote: >> On 2/5/26 14:27, The Natural Philosopher wrote: >>> On 05/02/2026 15:09, Pancho wrote: >>>> On 2/5/26 14:14, The Natural Philosopher wrote: >>>> >>>>> The first is of course implementation specific. C can specify a >>>>> data stack separate from a program stack and avoid code corruption, >>>>> leaving only data corruption... >>>>> >>>> >>>> Can it? Naively, I would have thought C was normally built on top >>>> of native assembler function calls, which dictates a shared stack. >>>> Obviously you could implement a function call independent of >>>> assembler, but does anyone, in practice? >>>> >>> You simply use a register as a second stack [data] pointer. >>> >>> Assign all your mem variables on that stack, and increment it at >>> function end. >>> >>> The assembler is trivial. Making C do it that way would not be hard, >>> either.. >> >> I actually searched on that a little, could >> not see any civil way to specify a stack in >> a new segment in 'C'. >> > Oh sure. You would have to modify the compiler Ah .... no problems then ....... > But IIRC the first PDP I worked on had 64k data and 64k code in entirely > different bits of RAM. Works. Of course actual 'segments' are kind of passe' these days - an olde-dayz artifact everyone hated. >> ASM, yea, easier - you have total control (and >> total responsibility). >> > Of course. That's what it teaches you.... Gen X/Y/Z/A2 "programmers" - have any EVER done a thing in ASM ? Even microcontrollers are now normally done in 'C' or MicroPython.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-07 12:29 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m7b6c$10ebk$7@dont-email.me> |
| In reply to | #81810 |
On 07/02/2026 02:44, c186282 wrote: > On 2/6/26 05:45, The Natural Philosopher wrote: >> On 06/02/2026 01:51, c186282 wrote: >>> On 2/5/26 14:27, The Natural Philosopher wrote: >>>> On 05/02/2026 15:09, Pancho wrote: >>>>> On 2/5/26 14:14, The Natural Philosopher wrote: >>>>> >>>>>> The first is of course implementation specific. C can specify a >>>>>> data stack separate from a program stack and avoid code >>>>>> corruption, leaving only data corruption... >>>>>> >>>>> >>>>> Can it? Naively, I would have thought C was normally built on top >>>>> of native assembler function calls, which dictates a shared stack. >>>>> Obviously you could implement a function call independent of >>>>> assembler, but does anyone, in practice? >>>>> >>>> You simply use a register as a second stack [data] pointer. >>>> >>>> Assign all your mem variables on that stack, and increment it at >>>> function end. >>>> >>>> The assembler is trivial. Making C do it that way would not be hard, >>>> either.. >>> >>> I actually searched on that a little, could >>> not see any civil way to specify a stack in >>> a new segment in 'C'. >>> >> Oh sure. You would have to modify the compiler > > Ah .... no problems then ....... > >> But IIRC the first PDP I worked on had 64k data and 64k code in >> entirely different bits of RAM. > > Works. > > Of course actual 'segments' are kind of > passe' these days - an olde-dayz artifact > everyone hated. > Isn't it all handled by a memory manager? >>> ASM, yea, easier - you have total control (and >>> total responsibility). >>> >> Of course. That's what it teaches you.... > > Gen X/Y/Z/A2 "programmers" - have any EVER done > a thing in ASM ? Even microcontrollers are now > normally done in 'C' or MicroPython. > Precisely. But at least inveterate tinkerers are leaning about things like response times... My Picos will not output anything to the USB port for quite a few milliseconds after it has been initialised. Juts be patient and use the sleep function -- Religion is regarded by the common people as true, by the wise as foolish, and by the rulers as useful. (Seneca the Younger, 65 AD)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-07 16:31 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <tY-cnVZrWaOxMhr0nZ2dnZfqnPudnZ2d@giganews.com> |
| In reply to | #81822 |
On 2/7/26 07:29, The Natural Philosopher wrote: > On 07/02/2026 02:44, c186282 wrote: >> On 2/6/26 05:45, The Natural Philosopher wrote: >>> On 06/02/2026 01:51, c186282 wrote: >>>> On 2/5/26 14:27, The Natural Philosopher wrote: >>>>> On 05/02/2026 15:09, Pancho wrote: >>>>>> On 2/5/26 14:14, The Natural Philosopher wrote: >>>>>> >>>>>>> The first is of course implementation specific. C can specify a >>>>>>> data stack separate from a program stack and avoid code >>>>>>> corruption, leaving only data corruption... >>>>>>> >>>>>> >>>>>> Can it? Naively, I would have thought C was normally built on top >>>>>> of native assembler function calls, which dictates a shared stack. >>>>>> Obviously you could implement a function call independent of >>>>>> assembler, but does anyone, in practice? >>>>>> >>>>> You simply use a register as a second stack [data] pointer. >>>>> >>>>> Assign all your mem variables on that stack, and increment it at >>>>> function end. >>>>> >>>>> The assembler is trivial. Making C do it that way would not be >>>>> hard, either.. >>>> >>>> I actually searched on that a little, could >>>> not see any civil way to specify a stack in >>>> a new segment in 'C'. >>>> >>> Oh sure. You would have to modify the compiler >> >> Ah .... no problems then ....... >> >>> But IIRC the first PDP I worked on had 64k data and 64k code in >>> entirely different bits of RAM. >> >> Works. >> >> Of course actual 'segments' are kind of >> passe' these days - an olde-dayz artifact >> everyone hated. >> > Isn't it all handled by a memory manager? These days, yes. Anyway, having to cope with those registers, which weren't that wide way back, was a pain in the ass. The 68000 looked like blue heaven by comparison. >>>> ASM, yea, easier - you have total control (and >>>> total responsibility). >>>> >>> Of course. That's what it teaches you.... >> >> Gen X/Y/Z/A2 "programmers" - have any EVER done >> a thing in ASM ? Even microcontrollers are now >> normally done in 'C' or MicroPython. >> > Precisely. > > But at least inveterate tinkerers are leaning about things like response > times... > > My Picos will not output anything to the USB port for quite a few > milliseconds after it has been initialised. Hardware doesn't come up instantly. USB ports are a sub-DEVICE and it has to be started and warmed up so to speak and then takes x-time to get from zero to sixty. Dealing with flash memory on a uC is educational, takes x-number of cycles before anything is actually written so you can't really proceed with anything using the data for a little while. 'sleep' delays are the standard fix. This prompted me to try ferroelectric memory, which is much much faster. Built a dozen field-project boards using that. Could save a bunch of relevant vars and values into that mem more often without slowing down the rest of the app. > Juts be patient and use the sleep function The latter gens don't seem to understand the underlying hardware very well. As fast as it is these days that usually doesn't matter, software complexity is what's dragging down performance. Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and some little dev boards and jumper wires and what looks to be a super-tiny LCD display of some kind. Gotta check to see if I have a compatible power supply. Have the instructions for adding the 'C' dev junk to my system (and there's always MicroPython). Also came across a "BreadVolt" - a 2-output regulator with a tiny backup battery inside to deal with brief power blinks - a teeny weenie UPS :-) Now for a not-quite-so-small I2C display ...
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-02-08 10:25 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <10m9oaq$1rh0e$6@dont-email.me> |
| In reply to | #81837 |
On 07/02/2026 21:31, c186282 wrote:
> Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and
> some little dev boards and jumper wires and what looks to be a
> super-tiny LCD display of some kind. Gotta check to see if I have a
> compatible power supply.
I think anything from 3 to 5.5V. Draws a couple of hundred mA max when
shouting radio.
> Have the instructions for adding the 'C' dev junk to my system (and
> there's always MicroPython).
Took me a long time to figure out the C toolkit. And cmake.
Scream for help if you get stymied.
--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."
- Stephen Vizinczey
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-02-08 20:13 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <mus93dF1318U4@mid.individual.net> |
| In reply to | #81855 |
On Sun, 8 Feb 2026 10:25:30 +0000, The Natural Philosopher wrote: > On 07/02/2026 21:31, c186282 wrote: >> Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and >> some little dev boards and jumper wires and what looks to be a >> super-tiny LCD display of some kind. Gotta check to see if I have a >> compatible power supply. Does the display look something like amazon.com/dp/B0CDWXFCN2/ They're a little classier than the old two line LCDs, particularly the ones that don't have the I2C module and need most of the GPIO lines.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-08 22:39 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <ngqdnRi2YLlByxT0nZ2dnZfqn_oAAAAA@giganews.com> |
| In reply to | #81855 |
On 2/8/26 05:25, The Natural Philosopher wrote: > On 07/02/2026 21:31, c186282 wrote: >> Bought a 'Pico starter kit' recently. Still in the box. A Pico2w and >> some little dev boards and jumper wires and what looks to be a >> super-tiny LCD display of some kind. Gotta check to see if I have a >> compatible power supply. > > I think anything from 3 to 5.5V. Draws a couple of hundred mA max when > shouting radio. > > >> Have the instructions for adding the 'C' dev junk to my system (and >> there's always MicroPython). > > Took me a long time to figure out the C toolkit. And cmake. > > Scream for help if you get stymied. I'll see what the online docs can do for me, there are a fair number, maybe they'll do it. Alas there always seem to be weird syntax traps in some of the utilities. Would rather not use MicroPython and degrade the performance. This IS one place where the Arduino team has a big advantage. Their IDE takes care of all that twiddly background shit transparently, you just compile and xfer. Pico has better/more performance than most Ard products however, and for cheaper, so it looks worth learning. Now to find that perfect I2C video display. Looking to make an all new weather center, so one PicoW out of doors to gather the data and one indoors to capture and display. I've done these before with Ards, but none were doing wireless. Yea, you can buy canned solutions cheap enough, but where's the fun in that ? :-)
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-02-09 04:58 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <mut7riF62ruU1@mid.individual.net> |
| In reply to | #81872 |
On Sun, 8 Feb 2026 22:39:06 -0500, c186282 wrote: > I'll see what the online docs can do for me, there are a fair number, > maybe they'll do it. Alas there always seem to be weird syntax traps > in some of the utilities. I would suggest VS Code with the Raspberry Pi Pico extension. https://vscodium.com/ https://github.com/microsoft/vscode Codium and Code-OSS may not have some of the Microsoft extensions but you won't need that for the Pi. 'New C/C++ Project' will set up the build environment or you can select from the examples. It also handles MicroPython projects. I haven't tried Rust or Zephyr. If you expect to print to the console make sure you select 'Console over USB'. If you miss it you can fix it in CMakeLists.txt. Make sure you select the right board. Pico and Pico 2 aren't the same and the W variants require a different approach for the Blinky test.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2026-02-09 10:04 -0800 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <20260209100449.0000348a@gmail.com> |
| In reply to | #81837 |
On Sat, 7 Feb 2026 16:31:24 -0500 c186282 <c186282@nnada.net> wrote: > This prompted me to try ferroelectric memory, which is much much > faster. Built a dozen field-project boards using that. Could save a > bunch of relevant vars and values into that mem more often without > slowing down the rest of the app. Been meaning to poke around with that for ages. Obviously the intended application is as an alternative to flash memory for persistent storage of firmware and/or settings, but it's interesting to consider a small homebrew system where it's used as main memory, directly analogous to core - free and indefinite-ish "suspend" with no battery drain! (Volatility of main memory is such a baked-in assumption to every form of computing post-mini era...of course mobile devices have had suspend/ resume for ages, but our OSes are still designed around the assumption that the computer starts with a blank slate and every process starts by getting loaded from disk. It'd be interesting to seriously re-examine that way of thinking...)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-09 23:39 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <nE6dnVQFUoLxKxf0nZ2dnZfqn_adnZ2d@giganews.com> |
| In reply to | #81883 |
On 2/9/26 13:04, John Ames wrote: > On Sat, 7 Feb 2026 16:31:24 -0500 > c186282 <c186282@nnada.net> wrote: > >> This prompted me to try ferroelectric memory, which is much much >> faster. Built a dozen field-project boards using that. Could save a >> bunch of relevant vars and values into that mem more often without >> slowing down the rest of the app. > > Been meaning to poke around with that for ages. Obviously the intended > application is as an alternative to flash memory for persistent storage > of firmware and/or settings, but it's interesting to consider a small > homebrew system where it's used as main memory, directly analogous to > core - free and indefinite-ish "suspend" with no battery drain! > > (Volatility of main memory is such a baked-in assumption to every form > of computing post-mini era...of course mobile devices have had suspend/ > resume for ages, but our OSes are still designed around the assumption > that the computer starts with a blank slate and every process starts by > getting loaded from disk. It'd be interesting to seriously re-examine > that way of thinking...) Ferro is FAST. Alas it's not 'dense' ... ie the chips don't hold THAT much info in comparison to typical flash. I think you can find 512kb ferro chips, and that's about it. GREAT for lower-end/microcontroller/field devices. But yer not gonna be buffering video frames. Anyway, look on Mouser and DigiKey ... I2C examples are most common but there do seem to be a few more, maybe faster, options. Could ferro BE 'dense' ? Maybe. However that takes R&D money which may not exist.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2026-02-10 08:00 -0800 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <20260210080035.000048d0@gmail.com> |
| In reply to | #81890 |
On Mon, 9 Feb 2026 23:39:05 -0500 c186282 <c186282@nnada.net> wrote: > Alas it's not 'dense' ... ie the chips don't hold THAT much info in > comparison to typical flash. I think you can find 512kb ferro chips, > and that's about it. > > GREAT for lower-end/microcontroller/field devices. But yer not gonna > be buffering video frames. > > Anyway, look on Mouser and DigiKey ... I2C examples are most common > but there do seem to be a few more, maybe faster, options. Actually have a coupla parts hanging around, from the period where it was new enough they'd hand out samples to anyone passing themselves off as a researcher ;) Think I've got a meg or two of the second-generation stuff (and another 64KB of first-gen, but the read/rewrite life on that is specced an order or two of magnitude lower.) Had the notion to use old cache SRAMs as a 1:1 write-through cache to keep wear to a minimum; just haven't gotten around to *doing* it yet. Well, oneathesedays...
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-02-10 23:02 -0500 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <azKdnRYU0p7XYhb0nZ2dnZfqnPWdnZ2d@giganews.com> |
| In reply to | #81908 |
On 2/10/26 11:00, John Ames wrote: > On Mon, 9 Feb 2026 23:39:05 -0500 > c186282 <c186282@nnada.net> wrote: > >> Alas it's not 'dense' ... ie the chips don't hold THAT much info in >> comparison to typical flash. I think you can find 512kb ferro chips, >> and that's about it. >> >> GREAT for lower-end/microcontroller/field devices. But yer not gonna >> be buffering video frames. >> >> Anyway, look on Mouser and DigiKey ... I2C examples are most common >> but there do seem to be a few more, maybe faster, options. > > Actually have a coupla parts hanging around, from the period where it > was new enough they'd hand out samples to anyone passing themselves off > as a researcher ;) Think I've got a meg or two of the second-generation > stuff (and another 64KB of first-gen, but the read/rewrite life on that > is specced an order or two of magnitude lower.) > > Had the notion to use old cache SRAMs as a 1:1 write-through cache to > keep wear to a minimum; just haven't gotten around to *doing* it yet. > Well, oneathesedays... Well, we all have Great Ideas ... but not enough time/energy to actually implement :-) I just bought a Pico2w "starter kit". Dunno if I really NEED a Pico for anything but it does look to be good cool tech so I'm gonna put in the effort. Ards are also good, have used them for many things and the IDE really makes stuff easier, but they're not as zippy as a Pico and adding wi-fi, or even wired networking, do NOT expect any useful speed. Oddly, I did make a very minimal web page - linked to a reserve company domain - using a basic Ard and wired-net add-on. Slow as shit, don't try to move much, but DID get it to work for a few years and even do some VERY rough character graphics. Basically it showed a little page and a link to the REAL web site. Not bad for the slow CPU and very minimal mem ! One advert for Ards ... the 2560 esp ... the low-power library works very well - makes it easy to do solar-powered field projects with just a 5W panel and lipo charger (Seeed !).
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-02-11 06:57 +0000 |
| Subject | Re: Memory Safety (Re: Python: A Little Trick For Every Need) |
| Message-ID | <mv2nj3F326tU1@mid.individual.net> |
| In reply to | #81929 |
On Tue, 10 Feb 2026 23:02:15 -0500, c186282 wrote: > I just bought a Pico2w "starter kit". Dunno if I really NEED a Pico > for anything but it does look to be good cool tech so I'm gonna put > in the effort. Ards are also good, have used them for many things and > the IDE really makes stuff easier, > but they're not as zippy as a Pico and adding wi-fi, or even wired > networking, do NOT expect any useful speed. If you haven't found them yet... https://pip-assets.raspberrypi.com/categories/610-raspberry-pi-pico/ documents/RP-008276-DS-1-getting-started-with-pico.pdf? https://pip-assets.raspberrypi.com/categories/609-microcontroller-boards/ documents/RP-009085-KB-1-raspberry-pi-pico-c-sdk.pdf The first one describes setting up VS Code and the Pico extension. The second gets into more detail. Beware the DHT-11 in the appendix. If you want a temperature/humidity sensor get the DHT-20. The DHT-11 requires very time sensitive bit-banging and the DHT-20 is I2C. The Arduino and MicroPython DHT-11 libraries work, the Pico C/C++ example code not so much. I finally did find something that worked on github. www.toptechboy.com has some decent videos. He digs into how the sensors work and the math behind it rather than copypasta.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web