Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #33009 > unrolled thread

Is Debian still good for GUI stuff in an over 12 yrs. old PC?

Started byant@zimage.comANT (Ant)
First post2021-08-30 18:22 -0500
Last post2021-09-16 08:02 +0000
Articles 20 on this page of 103 — 17 participants

Back to article view | Back to comp.os.linux.misc

Contents

  Is Debian still good for GUI stuff in an over 12 yrs. old PC? ant@zimage.comANT (Ant) - 2021-08-30 18:22 -0500
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Roger Blake <rogblake@iname.invalid> - 2021-08-31 00:14 +0000
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-08-30 17:57 -0700
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 04:39 +0100
      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-08-31 15:19 +0200
        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 14:34 +0100
          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-08-31 16:16 +0200
            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 15:47 +0100
              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-08-31 18:54 +0200
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 17:59 +0100
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-08-31 11:52 -0700
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-09-01 04:21 +0000
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-08-31 01:07 -0400
      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-08-31 11:01 +0200
        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-08-31 11:01 -0400
          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-01 11:07 +0200
            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Andreas Kohlbach <ank@spamfence.net> - 2021-09-01 07:55 -0400
              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-01 13:10 +0100
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-01 23:58 -0400
                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? "Carlos E. R." <robin_listas@es.invalid> - 2021-09-02 13:04 +0200
                    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-03 01:56 -0400
                      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-03 08:44 +0200
                        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? "Carlos E. R." <robin_listas@es.invalid> - 2021-09-03 11:22 +0200
                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-04 00:31 -0400
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-04 10:56 +0200
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-09-04 11:44 +0200
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-09-04 08:04 -0700
                              OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Rinaldi <rm@nunya.inv> - 2021-09-04 10:28 -0500
                                Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-09-04 08:41 -0700
                                  Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-04 18:33 +0100
                                  Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-05 00:53 -0400
                                    Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-09-05 08:57 +0200
                                      Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Andreas Kohlbach <ank@spamfence.net> - 2021-09-05 12:12 -0400
                                        Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-05 20:01 -0400
                                Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-09-04 08:42 -0700
                                Re: OT Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Bobbie Sellers <bliss@mouse-potato.com> - 2021-09-04 08:45 -0700
                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-04 18:32 +0100
                        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Andreas Kohlbach <ank@spamfence.net> - 2021-09-03 19:51 -0400
                        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-03 23:48 -0400
                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-04 08:44 +0100
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-05 00:07 -0400
                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-05 08:16 +0100
                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-05 09:36 +0100
                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-05 12:50 +0100
                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Dan Espen <dan1espen@gmail.com> - 2021-09-05 09:33 -0400
                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? "Carlos E. R." <robin_listas@es.invalid> - 2021-09-04 11:22 +0200
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Joerg Lorenz <hugybear@gmx.ch> - 2021-09-04 11:46 +0200
                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-04 17:47 +0000
                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-05 09:35 +0100
                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-05 19:34 -0400
                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? "Carlos E. R." <robin_listas@es.invalid> - 2021-09-06 02:14 +0200
                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-06 08:43 +0100
                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-06 08:45 +0100
                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-07 01:54 -0400
                                    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-07 08:44 +0100
                                      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-08 01:36 -0400
                                        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-08 07:46 +0100
                                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-09 01:53 -0400
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-09 07:41 +0100
                                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-10 01:52 -0400
                                        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-08 08:46 +0100
                                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-08 10:57 +0100
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-08 12:12 +0100
                                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-08 13:06 +0100
                                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-08 13:29 +0100
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-09-08 14:17 +0300
                                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-09 02:04 -0400
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-09 07:46 +0100
                                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-10 02:51 -0400
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-10 09:49 +0100
                                          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-11 02:03 -0400
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-11 07:19 +0100
                                            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-11 08:32 +0100
                                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-12 00:17 -0400
                                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-12 09:09 +0100
                                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-12 23:43 -0400
                                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-12 11:33 +0100
                              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-09-06 11:08 +0300
                                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-06 09:24 +0100
                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-09-06 12:38 +0300
                                    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-06 12:21 +0100
                                      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SevenOverSix <hae274c.net> - 2021-09-07 02:20 -0400
                                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Richard Kettlewell <invalid@invalid.invalid> - 2021-09-06 11:39 +0100
                                    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-06 12:22 +0100
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-02 09:29 +0200
                  Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-02 09:48 +0100
            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-01 23:32 -0400
              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-02 09:30 +0200
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-03 00:04 -0400
              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-04 17:58 +0000
                Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? SixOverFive <hae274c.net> - 2021-09-05 00:22 -0400
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-08-31 10:59 +0200
      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 10:46 +0100
        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 10:50 +0100
          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 10:57 +0100
        Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Marc Haber <mh+usenetspam1118@zugschl.us> - 2021-09-01 11:09 +0200
          Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-09-01 10:42 +0100
            Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? "Carlos E. R." <robin_listas@es.invalid> - 2021-09-01 13:47 +0200
              Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-04 18:09 +0000
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Andreas Kohlbach <ank@spamfence.net> - 2021-08-31 06:04 -0400
      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? The Natural Philosopher <tnp@invalid.invalid> - 2021-08-31 11:42 +0100
    Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? TJ <TJ@noneofyour.business> - 2021-09-14 22:42 -0400
      Re: Is Debian still good for GUI stuff in an over 12 yrs. old PC? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-09-16 08:02 +0000

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#33184

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-08 08:46 +0100
Message-ID<87o8938q6k.fsf@LkoBDZeT.terraraq.uk>
In reply to#33182
SevenOverSix <hae274c.net> writes:
> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>> Give me *some* credit for knowing how to code a multitasker and in
>> interrupt service routine
>
>   Oh, I'll give due credit. Your code IS a good byte-saver.
>   However I've always had a good sense of how bits of code
>   can go wrong. You code is perfectly good - but within a
>   certain context/environment. As I said, WHICH stack are
>   you popping from ?

TNP’s space optimization doesn’t affect the meaning of the code. POP
uses the same SP regardless of where the instruction is located. You are
talking nonsense.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33185

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-08 10:57 +0100
Message-ID<sha1ec$5h4$1@dont-email.me>
In reply to#33184
On 08/09/2021 08:46, Richard Kettlewell wrote:
> SevenOverSix <hae274c.net> writes:
>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>> Give me *some* credit for knowing how to code a multitasker and in
>>> interrupt service routine
>>
>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>    However I've always had a good sense of how bits of code
>>    can go wrong. You code is perfectly good - but within a
>>    certain context/environment. As I said, WHICH stack are
>>    you popping from ?
> 
> TNP’s space optimization doesn’t affect the meaning of the code. POP
> uses the same SP regardless of where the instruction is located. You are
> talking nonsense.
> 
Thanks Richard.

On the matter of caching, It's been bothering me...surely even if the 
instruction set is cached, a JMP instruction still takes time, or has 
the processor simply 'cut and pasted' the instruction block into the 
pipeline and elided the JMP altogether?


-- 
If I had all the money I've spent on drink...
..I'd spend it on drink.

Sir Henry (at Rawlinson's End)

[toc] | [prev] | [next] | [standalone]

#33186

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-08 12:12 +0100
Message-ID<87czpj8gnr.fsf@LkoBDZeT.terraraq.uk>
In reply to#33185
The Natural Philosopher <tnp@invalid.invalid> writes:
> On 08/09/2021 08:46, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You are
>> talking nonsense.
>>
> Thanks Richard.
>
> On the matter of caching, It's been bothering me...surely even if the
> instruction set is cached, a JMP instruction still takes time, or has
> the processor simply 'cut and pasted' the instruction block into the
> pipeline and elided the JMP altogether?

Suppose you have many consecutive functions with the common tail, and
you execute all of them once.

For each of those functions, the object code of the function must be
loaded from main memory into cache. The number of loads from main memory
is proportional to the sum of the sizes of the functions.

Now suppose all but one of the functions have that tail replaced by a
JMP to the first function’s version.

They do indeed incur a small extra cost for the JMP, but after the first
of them has executed, and _if_ the reduced size means you’ve reduced the
total amount of code that must be read, the number of loads from main
memory is reduced.

Loads from main memory are incredibly slow compared to executing single
instructions - think 10x or 100x as long. The extra cost of the JMP is
lost in the noise.

This is a very simple model; in reality you won’t notice the
sub-microsecond savings from eliminating a handful of memory reads.  The
real benefit comes when the space optimization squeezes the working set
of a long-running program down from a bit bigger than the total cache
size to a bit smaller.

The effect scales: if you can reduce the number of memory pages your
program takes, you reduce the number of disk reads, and those are
even slower.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33188

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-08 13:06 +0100
Message-ID<sha900$ooa$1@dont-email.me>
In reply to#33186
On 08/09/2021 12:12, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> On 08/09/2021 08:46, Richard Kettlewell wrote:
>>> SevenOverSix <hae274c.net> writes:
>>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>>> interrupt service routine
>>>>
>>>>     Oh, I'll give due credit. Your code IS a good byte-saver.
>>>>     However I've always had a good sense of how bits of code
>>>>     can go wrong. You code is perfectly good - but within a
>>>>     certain context/environment. As I said, WHICH stack are
>>>>     you popping from ?
>>>
>>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>>> uses the same SP regardless of where the instruction is located. You are
>>> talking nonsense.
>>>
>> Thanks Richard.
>>
>> On the matter of caching, It's been bothering me...surely even if the
>> instruction set is cached, a JMP instruction still takes time, or has
>> the processor simply 'cut and pasted' the instruction block into the
>> pipeline and elided the JMP altogether?
> 
> Suppose you have many consecutive functions with the common tail, and
> you execute all of them once.
> 
> For each of those functions, the object code of the function must be
> loaded from main memory into cache. The number of loads from main memory
> is proportional to the sum of the sizes of the functions.
> 
> Now suppose all but one of the functions have that tail replaced by a
> JMP to the first function’s version.
> 
> They do indeed incur a small extra cost for the JMP, but after the first
> of them has executed, and _if_ the reduced size means you’ve reduced the
> total amount of code that must be read, the number of loads from main
> memory is reduced.
> 
> Loads from main memory are incredibly slow compared to executing single
> instructions - think 10x or 100x as long. The extra cost of the JMP is
> lost in the noise.
> 
> This is a very simple model; in reality you won’t notice the
> sub-microsecond savings from eliminating a handful of memory reads.  The
> real benefit comes when the space optimization squeezes the working set
> of a long-running program down from a bit bigger than the total cache
> size to a bit smaller.
> 
> The effect scales: if you can reduce the number of memory pages your
> program takes, you reduce the number of disk reads, and those are
> even slower.
> 
Thanks. That makes it clear.  So in fact lots of very small often used 
subroutines might be faster than inline coding?

Rather counter intuitive, that.

-- 
When plunder becomes a way of life for a group of men in a society, over 
the course of time they create for themselves a legal system that 
authorizes it and a moral code that glorifies it.

  Frédéric Bastiat

[toc] | [prev] | [next] | [standalone]

#33189

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-08 13:29 +0100
Message-ID<877dfr8d3b.fsf@LkoBDZeT.terraraq.uk>
In reply to#33188
The Natural Philosopher <tnp@invalid.invalid> writes:
> Thanks. That makes it clear.  So in fact lots of very small often used
> subroutines might be faster than inline coding?
>
> Rather counter intuitive, that.

It can happen, yes - it will be very dependent on what the code does,
the relationship between its size and cache sizes, etc. Same with data:
if you can make its representation smaller, enough so that it takes less
cache lines (or pages, etc) then overall performance can be better even
though you’re doing more work to unpack it.

A good concrete example of this (much higher up the memory hierarchy) is
that compressed man pages are quicker to render than uncompressed ones
(and have been since at least the 1990s) - gzip decompression is enough
faster than disk read that you can easily measure the difference.

(Granted I’ve not rechecked this against NVMe or other modern ultra-fast
storage.)

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33187

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2021-09-08 14:17 +0300
Message-ID<sha646$6o1$1@dont-email.me>
In reply to#33185
On 8.9.21 12.57, The Natural Philosopher wrote:
> On 08/09/2021 08:46, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You are
>> talking nonsense.
>>
> Thanks Richard.
> 
> On the matter of caching, It's been bothering me...surely even if the 
> instruction set is cached, a JMP instruction still takes time, or has 
> the processor simply 'cut and pasted' the instruction block into the 
> pipeline and elided the JMP altogether?


A transfer of control usually causes a flush of the instruction
pipeline and, dependent on cache size and alignment with respect
to the transfer, also a cache miss. An exception may be a processor
with several speculative execution paths.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#33194

FromSevenOverSix <hae274c.net>
Date2021-09-09 02:04 -0400
Message-ID<KqednWdLw4dsPqT8nZ2dnUU7-anNnZ2d@earthlink.com>
In reply to#33184
On 9/8/21 3:46 AM, Richard Kettlewell wrote:
> SevenOverSix <hae274c.net> writes:
>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>> Give me *some* credit for knowing how to code a multitasker and in
>>> interrupt service routine
>>
>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>    However I've always had a good sense of how bits of code
>>    can go wrong. You code is perfectly good - but within a
>>    certain context/environment. As I said, WHICH stack are
>>    you popping from ?
> 
> TNP’s space optimization doesn’t affect the meaning of the code. POP
> uses the same SP regardless of where the instruction is located. You are
> talking nonsense.

   ONLY if you use sub-less programs. Try that shit
   with threads/subs/ISRs and you'll get burnt.
   Absolutely guaranteed. Been there. Debugging
   was a total bitch.

   It's all CONTEXT - the environment, the hardware, how
   YOU set up the program. GOTO shortcuts can be great,
   or a great disaster.

   But nobody liked Cassandra ......  :-)

[toc] | [prev] | [next] | [standalone]

#33196

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-09 07:46 +0100
Message-ID<shcak4$bpi$1@dont-email.me>
In reply to#33194
On 09/09/2021 07:04, SevenOverSix wrote:
> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You are
>> talking nonsense.
> 
>    ONLY if you use sub-less programs. Try that shit
>    with threads/subs/ISRs and you'll get burnt.
>    Absolutely guaranteed. Been there. Debugging
>    was a total bitch.
> 

Why would you be using that code fragment *without* it being part of a 
subroutine?

I've written reams of code to operate under context switched 
multitaskers and interrupt service routines, using subroutines

As long as you only use memory relative the the contexts stack frame, 
they are thread safe, If you modify memory outside of that it had better 
not be modified by anyone else or you are in trouble




>    It's all CONTEXT - the environment, the hardware, how
>    YOU set up the program. GOTO shortcuts can be great,
>    or a great disaster.
> 
No, it isnt

Its about actually understanding how multitasking works

>    But nobody liked Cassandra ......  :-)
> 


-- 
“The ultimate result of shielding men from the effects of folly is to 
fill the world with fools.”

Herbert Spencer

[toc] | [prev] | [next] | [standalone]

#33199

FromSevenOverSix <hae274c.net>
Date2021-09-10 02:51 -0400
Message-ID<yaWdnahbeecWnab8nZ2dnUU7-NnNnZ2d@earthlink.com>
In reply to#33196
On 9/9/21 2:46 AM, The Natural Philosopher wrote:
> On 09/09/2021 07:04, SevenOverSix wrote:
>> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>>> SevenOverSix <hae274c.net> writes:
>>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>>> interrupt service routine
>>>>
>>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>>    However I've always had a good sense of how bits of code
>>>>    can go wrong. You code is perfectly good - but within a
>>>>    certain context/environment. As I said, WHICH stack are
>>>>    you popping from ?
>>>
>>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>>> uses the same SP regardless of where the instruction is located. You are
>>> talking nonsense.
>>
>>    ONLY if you use sub-less programs. Try that shit
>>    with threads/subs/ISRs and you'll get burnt.
>>    Absolutely guaranteed. Been there. Debugging
>>    was a total bitch.
>>
> 
> Why would you be using that code fragment *without* it being part of a 
> subroutine?

   Your fragment was sold as a fix for subroutineS. For
   ISR(s).

   In SOME carefully crafted software IT WILL WORK FINE.
   But not ALL.

   Especially for microcontrollers, "sub-less", GOTO-structured,
   code may be the BEST choice - smaller, faster, simpler. Been
   there, done it, not sorry.

   But when you move up to microprocessors/OSs/multi-thread-core
   ... then things can get very weird. If you MUST have tippy-top
   performance then it's NOT WikiPedia simple - you have to really
   KNOW how that little black square thing THINKS.

> I've written reams of code to operate under context switched 
> multitaskers and interrupt service routines, using subroutines

   Good.

   But shit CAN go very wrong ......

   A little bumblebee starts buzzing in the back of
   my head - saying *something* may not be accomodated.

> As long as you only use memory relative the the contexts stack frame, 
> they are thread safe, If you modify memory outside of that it had better 
> not be modified by anyone else or you are in trouble

   Ah .. "So Long As" ...  :-)

   You see, THAT'S the rub I'm talking about.

   We're just not speaking the exact same language here.
   I learned this shit entirely on my own over 30+ years
   and think of it MY way, in MY terms. You took some
   slightly different paths and think of it YOUR way,
   in YOUR terms. I don't think we're ACTUALLY in so
   much disagreement as it seems.

> 
>>    It's all CONTEXT - the environment, the hardware, how
>>    YOU set up the program. GOTO shortcuts can be great,
>>    or a great disaster.
>>
> No, it isnt

   Yes, it VERY much is - at least as I think of "context".

> Its about actually understanding how multitasking works

   Multi-tasking can work in several ways , depending on
   the CPU and the app you craft. Intel/AMD are NOT the
   alpha and omega of the universe.

   This is an -ix group, but a lot of us also craft apps
   for things with NO OS at all. Weird chips. Weird apps.
   Wrote anything for an Epson 4-bit chip lately ?
   How's your Atmel/Arduino ? 8051 ? PIC ? Those kinds of
   chips are in *everything* the world wants, all the little
   conveniences. Make your Mr. Coffee work. Your microwave.
   Your TV remote. Your home alarm. Your A/C thermostat.
   What makes your 'woke' solar panels charge the damned
   batteries right. One of those weather monitors. Your
   car ignition. They ain't DOS or Winders or Linux - but
   they make the real world work.

   The "higher level" systems "Make Use Of Them" ... but
   they have to deliver, often with ultra-limited resources,
   in the first place.

   See where I'm coming from ?


>>    But nobody liked Cassandra ......  :-)
>>
> 
>

[toc] | [prev] | [next] | [standalone]

#33200

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-10 09:49 +0100
Message-ID<87sfyc7r37.fsf@LkoBDZeT.terraraq.uk>
In reply to#33194
SevenOverSix <hae274c.net> writes:
> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You
>> are talking nonsense.
>
>   ONLY if you use sub-less programs. Try that shit
>   with threads/subs/ISRs and you'll get burnt.
>   Absolutely guaranteed. Been there. Debugging
>   was a total bitch.

TNP’s code is x86; you can easily find the x86 instruction set reference
online. There is nothing to support your counterfactual argument there.
If you want to argue about some other ISA we can look at that instead.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33201

FromSevenOverSix <hae274c.net>
Date2021-09-11 02:03 -0400
Message-ID<lNCdneRKtaNN26H8nZ2dnUU7-U_NnZ2d@earthlink.com>
In reply to#33184
On 9/8/21 3:46 AM, Richard Kettlewell wrote:
> SevenOverSix <hae274c.net> writes:
>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>> Give me *some* credit for knowing how to code a multitasker and in
>>> interrupt service routine
>>
>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>    However I've always had a good sense of how bits of code
>>    can go wrong. You code is perfectly good - but within a
>>    certain context/environment. As I said, WHICH stack are
>>    you popping from ?
> 
> TNP’s space optimization doesn’t affect the meaning of the code. POP
> uses the same SP regardless of where the instruction is located. You are
> talking nonsense.

   Doesn't even MATTER if it's the same SP ... WHO has
   pushed their crap ONTO it at the instant ?

   I'm really concerned that you can't see how
     GOTO :
       pop
       pop
       pop
   any/everywhere in a program can go horribly wrong.

[toc] | [prev] | [next] | [standalone]

#33202

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-11 07:19 +0100
Message-ID<shhhp4$evh$1@dont-email.me>
In reply to#33201
On 11/09/2021 07:03, SevenOverSix wrote:
> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You are
>> talking nonsense.
> 
>    Doesn't even MATTER if it's the same SP ... WHO has
>    pushed their crap ONTO it at the instant ?
> 
>    I'm really concerned that you can't see how
>      GOTO :
>        pop
>        pop
>        pop
>    any/everywhere in a program can go horribly wrong.
> 
Im really concrened that you cannot see how

      GOTO :
         pop
         pop
         pop

Is different from just

         pop
         pop
         pop

-- 
It is the folly of too many to mistake the echo of a London coffee-house 
for the voice of the kingdom.

Jonathan Swift

[toc] | [prev] | [next] | [standalone]

#33203

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-11 08:32 +0100
Message-ID<87mtoj7ekn.fsf@LkoBDZeT.terraraq.uk>
In reply to#33201
SevenOverSix <hae274c.net> writes:
> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>> interrupt service routine
>>>
>>>    Oh, I'll give due credit. Your code IS a good byte-saver.
>>>    However I've always had a good sense of how bits of code
>>>    can go wrong. You code is perfectly good - but within a
>>>    certain context/environment. As I said, WHICH stack are
>>>    you popping from ?
>>
>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>> uses the same SP regardless of where the instruction is located. You are
>> talking nonsense.
>
>   Doesn't even MATTER if it's the same SP ... WHO has
>   pushed their crap ONTO it at the instant ?

Nobody has. Introducing a JMP doesn’t affect the stack at all.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33204

FromSevenOverSix <hae274c.net>
Date2021-09-12 00:17 -0400
Message-ID<TKudnQ5n3K_d4qD8nZ2dnUU7-IXNnZ2d@earthlink.com>
In reply to#33203
On 9/11/21 3:32 AM, Richard Kettlewell wrote:
> SevenOverSix <hae274c.net> writes:
>> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>>> SevenOverSix <hae274c.net> writes:
>>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>>> interrupt service routine
>>>>
>>>>     Oh, I'll give due credit. Your code IS a good byte-saver.
>>>>     However I've always had a good sense of how bits of code
>>>>     can go wrong. You code is perfectly good - but within a
>>>>     certain context/environment. As I said, WHICH stack are
>>>>     you popping from ?
>>>
>>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>>> uses the same SP regardless of where the instruction is located. You are
>>> talking nonsense.
>>
>>    Doesn't even MATTER if it's the same SP ... WHO has
>>    pushed their crap ONTO it at the instant ?
> 
> Nobody has. Introducing a JMP doesn’t affect the stack at all.

   It's not the JMP ... it's what your JMP-ing FROM and TO.

   The provided example popped x-number of items off
   the stack, regardless of the situation you jumped
   FROM. IF your code/subs/isr's are all PERFECTLY
   regular, ALWAYS put the exact same number of items
   on the stack, then you can do the JMP/POP trick safely.

   You can always keep track of what was added to the
   stack in a variable and POP accordingly - but then
   you're inserting addition/subtraction plus a counting
   loop and negate the perks of the trick - basically
   replicating what the processor normally does when it
   returns from a sub - but SLOWER.

   All I'm saying is that the example was a special case.
   There ARE ways to get away with it, but it's rarely
   THAT simple. IF you can possibly spare the memory
   and cycles, do it more conventionally with every
   sub cleaning up its own mess in the order created.
   I've done a lot of microcontroller projects and
   I know that sometimes you CAN'T spare the memory
   or cycles. Very very careful programming and
   optimization is then required. Often what you
   originally did in 20 instructions can be done
   in 10 IF ...

   Mr. Philosopher seems to think I'm dissing him. I'm not.
   His fix IS clever - but you can't use it EVERYWHERE on
   EVERYTHING.

[toc] | [prev] | [next] | [standalone]

#33205

FromRichard Kettlewell <invalid@invalid.invalid>
Date2021-09-12 09:09 +0100
Message-ID<871r5u2p13.fsf@LkoBDZeT.terraraq.uk>
In reply to#33204
SevenOverSix <hae274c.net> writes:
> It's not the JMP ... it's what your JMP-ing FROM and TO.
>
> The provided example popped x-number of items off the stack,
> regardless of the situation you jumped FROM.

Nope. The example replaced a specific sequence of POPs and RET with a
JMP to the same sequence of POPs and RET.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#33208

FromSevenOverSix <hae274c.net>
Date2021-09-12 23:43 -0400
Message-ID<-NudnfTq2-1UVaP8nZ2dnUU7-WvNnZ2d@earthlink.com>
In reply to#33205
On 9/12/21 4:09 AM, Richard Kettlewell wrote:
> SevenOverSix <hae274c.net> writes:
>> It's not the JMP ... it's what your JMP-ing FROM and TO.
>>
>> The provided example popped x-number of items off the stack,
>> regardless of the situation you jumped FROM.
> 
> Nope. The example replaced a specific sequence of POPs and RET with a
> JMP to the same sequence of POPs and RET.

   That'll work - WITHIN that context. I'm referring to
   the example being used as prototype GENERAL fix for
   every little problem.

   Not mentioning the limitations amounts to defective
   programming advice. Many (most) of us use cut-n-paste
   bits from advice forums these days. Like science and
   medicine, the compuverse has become SO vast there are
   no such things as all-purpose experts. Specialization
   has crept in. Oft we need to cut-n-paste stuff WE do
   not fully understand. So, it'd better be GOOD stuff.

[toc] | [prev] | [next] | [standalone]

#33207

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-12 11:33 +0100
Message-ID<shkl1v$6pn$1@dont-email.me>
In reply to#33204
On 12/09/2021 05:17, SevenOverSix wrote:
> On 9/11/21 3:32 AM, Richard Kettlewell wrote:
>> SevenOverSix <hae274c.net> writes:
>>> On 9/8/21 3:46 AM, Richard Kettlewell wrote:
>>>> SevenOverSix <hae274c.net> writes:
>>>>> On 9/7/21 3:44 AM, The Natural Philosopher wrote:
>>>>>> Give me *some* credit for knowing how to code a multitasker and in
>>>>>> interrupt service routine
>>>>>
>>>>>     Oh, I'll give due credit. Your code IS a good byte-saver.
>>>>>     However I've always had a good sense of how bits of code
>>>>>     can go wrong. You code is perfectly good - but within a
>>>>>     certain context/environment. As I said, WHICH stack are
>>>>>     you popping from ?
>>>>
>>>> TNP’s space optimization doesn’t affect the meaning of the code. POP
>>>> uses the same SP regardless of where the instruction is located. You 
>>>> are
>>>> talking nonsense.
>>>
>>>    Doesn't even MATTER if it's the same SP ... WHO has
>>>    pushed their crap ONTO it at the instant ?
>>
>> Nobody has. Introducing a JMP doesn’t affect the stack at all.
> 
>    It's not the JMP ... it's what your JMP-ing FROM and TO.
> 
>    The provided example popped x-number of items off
>    the stack, regardless of the situation you jumped
>    FROM. IF your code/subs/isr's are all PERFECTLY
>    regular, ALWAYS put the exact same number of items
>    on the stack, then you can do the JMP/POP trick safely.
> 
Well of course they are!

Why on earth would one not make sure of that?

>    You can always keep track of what was added to the
>    stack in a variable and POP accordingly - but then
>    you're inserting addition/subtraction plus a counting
>    loop and negate the perks of the trick - basically
>    replicating what the processor normally does when it
>    returns from a sub - but SLOWER.
> 
>    All I'm saying is that the example was a special case.
>    There ARE ways to get away with it, but it's rarely
>    THAT simple. IF you can possibly spare the memory
>    and cycles, do it more conventionally with every
>    sub cleaning up its own mess in the order created.
>    I've done a lot of microcontroller projects and
>    I know that sometimes you CAN'T spare the memory
>    or cycles. Very very careful programming and
>    optimization is then required. Often what you
>    originally did in 20 instructions can be done
>    in 10 IF ...
> 
>    Mr. Philosopher seems to think I'm dissing him. I'm not.
>    His fix IS clever - but you can't use it EVERYWHERE on
>    EVERYTHING.
> 

You can use it anywhere you have the same sequence of POPS followed by a RET

And in the case in point the original designer simply always used the 
same registers - AX, BX, CX, DX - as scratch storage in any subroutine.

And because I was modifying and extending his BIOS code, I followed the 
same convention as well.

When you needed to cram more into an already full 2K EEPROM it was a way 
to do it.


-- 
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?

Josef Stalin

[toc] | [prev] | [next] | [standalone]

#33157

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2021-09-06 11:08 +0300
Message-ID<sh4iaa$v75$1@dont-email.me>
In reply to#33119
On 5.9.2021 11:35 AM, The Natural Philosopher wrote:
> On 04/09/2021 18:47, Stéphane CARPENTIER wrote:
>> Le 04-09-2021, SixOverFive <hae274c.net> a écrit :
>>>
>>>     SOMETIMES though, you can CHEAT. Change the properties of
>>>     your symlink so even root can't edit/change/replace it.
>>>     The installer may bitch, but SO WHAT.
>>
>> Cheating on your installer can't be a good advice. If you don't like
>> what it does, use another installer, install everything manually,
>> whatever. But cheating is the better way to have an unstable system
>> without being able to understand why at some point.
>>
>> You do what you want on your computer: I don't care, it's your computer.
>> But pretending others should do the same is just plain wrong.
>>
> You are really simply echoing te dichotomy between a personal computer, 
> which does what *I* want, and a corporate system, which has to do what 
> your *employer* wants, subject to maintainability and reliability and 
> security constraints.
> 
> I would suggest that they are neither te same case, nor indicate the 
> same solutions.
> 
> 
> One may do a 5 minute hack to prove a principle and get some code 
> working, but *if* it is going to be replicated or maintained by others 
> it behoves one to rework it into whatever is expected by e.g. other 
> engineers, installation scripts and the like.
> 
> On the other hand, if it is *not*, so what? Typically embedded systems 
> that are neither subject to maintenance or upgrade can so whatever they 
> like.
> 
> Faced with lack of space in a 2K EPROM, I replaced all instances of
> POP AX
> POP BX
> POP CX
> POP DX
> RET
> 
> with
> JMP STDEXIT
> 
> 
> STDEXIT:
> POP AX
> POP BX
> POP CX
> POP DX
> RET
> 
> and gained the 64 bytes of PROM space I needed to include an extended BIOS.
> 
> I am sure those who are imbued with 'never use a goto' would be 
> horrified. But it worked, the customer got his extended bios without 
> having to change his bios and I got paid. And really, as we used to say, 
> in the end its all 'bits, in silicon'.
> 

It is a method called 'tail-ending' in compilers. Any reasonably recent
version of the GNU GCC is able to do it without programmer assistance,
except selecting high enough optimization levele when compiling.

-- 

TV

[toc] | [prev] | [next] | [standalone]

#33158

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2021-09-06 09:24 +0100
Message-ID<sh4j86$60q$1@dont-email.me>
In reply to#33157
On 06/09/2021 09:08, Tauno Voipio wrote:
> On 5.9.2021 11:35 AM, The Natural Philosopher wrote:
>> On 04/09/2021 18:47, Stéphane CARPENTIER wrote:
>>> Le 04-09-2021, SixOverFive <hae274c.net> a écrit :
>>>>
>>>>     SOMETIMES though, you can CHEAT. Change the properties of
>>>>     your symlink so even root can't edit/change/replace it.
>>>>     The installer may bitch, but SO WHAT.
>>>
>>> Cheating on your installer can't be a good advice. If you don't like
>>> what it does, use another installer, install everything manually,
>>> whatever. But cheating is the better way to have an unstable system
>>> without being able to understand why at some point.
>>>
>>> You do what you want on your computer: I don't care, it's your computer.
>>> But pretending others should do the same is just plain wrong.
>>>
>> You are really simply echoing te dichotomy between a personal 
>> computer, which does what *I* want, and a corporate system, which has 
>> to do what your *employer* wants, subject to maintainability and 
>> reliability and security constraints.
>>
>> I would suggest that they are neither te same case, nor indicate the 
>> same solutions.
>>
>>
>> One may do a 5 minute hack to prove a principle and get some code 
>> working, but *if* it is going to be replicated or maintained by others 
>> it behoves one to rework it into whatever is expected by e.g. other 
>> engineers, installation scripts and the like.
>>
>> On the other hand, if it is *not*, so what? Typically embedded systems 
>> that are neither subject to maintenance or upgrade can so whatever 
>> they like.
>>
>> Faced with lack of space in a 2K EPROM, I replaced all instances of
>> POP AX
>> POP BX
>> POP CX
>> POP DX
>> RET
>>
>> with
>> JMP STDEXIT
>>
>>
>> STDEXIT:
>> POP AX
>> POP BX
>> POP CX
>> POP DX
>> RET
>>
>> and gained the 64 bytes of PROM space I needed to include an extended 
>> BIOS.
>>
>> I am sure those who are imbued with 'never use a goto' would be 
>> horrified. But it worked, the customer got his extended bios without 
>> having to change his bios and I got paid. And really, as we used to 
>> say, in the end its all 'bits, in silicon'.
>>
> 
> It is a method called 'tail-ending' in compilers. Any reasonably recent
> version of the GNU GCC is able to do it without programmer assistance,
> except selecting high enough optimization levele when compiling.
> 
I am sure that optimizing for size would use something like that. It is 
fractionally *slower*

-- 
“when things get difficult you just have to lie”

― Jean Claud Jüncker

[toc] | [prev] | [next] | [standalone]

#33160

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2021-09-06 12:38 +0300
Message-ID<sh4nhs$2id$2@dont-email.me>
In reply to#33158
On 6.9.2021 11:24 AM, The Natural Philosopher wrote:
> On 06/09/2021 09:08, Tauno Voipio wrote:
>> On 5.9.2021 11:35 AM, The Natural Philosopher wrote:
>>> On 04/09/2021 18:47, Stéphane CARPENTIER wrote:
>>>> Le 04-09-2021, SixOverFive <hae274c.net> a écrit :
>>>>>
>>>>>     SOMETIMES though, you can CHEAT. Change the properties of
>>>>>     your symlink so even root can't edit/change/replace it.
>>>>>     The installer may bitch, but SO WHAT.
>>>>
>>>> Cheating on your installer can't be a good advice. If you don't like
>>>> what it does, use another installer, install everything manually,
>>>> whatever. But cheating is the better way to have an unstable system
>>>> without being able to understand why at some point.
>>>>
>>>> You do what you want on your computer: I don't care, it's your 
>>>> computer.
>>>> But pretending others should do the same is just plain wrong.
>>>>
>>> You are really simply echoing te dichotomy between a personal 
>>> computer, which does what *I* want, and a corporate system, which has 
>>> to do what your *employer* wants, subject to maintainability and 
>>> reliability and security constraints.
>>>
>>> I would suggest that they are neither te same case, nor indicate the 
>>> same solutions.
>>>
>>>
>>> One may do a 5 minute hack to prove a principle and get some code 
>>> working, but *if* it is going to be replicated or maintained by 
>>> others it behoves one to rework it into whatever is expected by e.g. 
>>> other engineers, installation scripts and the like.
>>>
>>> On the other hand, if it is *not*, so what? Typically embedded 
>>> systems that are neither subject to maintenance or upgrade can so 
>>> whatever they like.
>>>
>>> Faced with lack of space in a 2K EPROM, I replaced all instances of
>>> POP AX
>>> POP BX
>>> POP CX
>>> POP DX
>>> RET
>>>
>>> with
>>> JMP STDEXIT
>>>
>>>
>>> STDEXIT:
>>> POP AX
>>> POP BX
>>> POP CX
>>> POP DX
>>> RET
>>>
>>> and gained the 64 bytes of PROM space I needed to include an extended 
>>> BIOS.
>>>
>>> I am sure those who are imbued with 'never use a goto' would be 
>>> horrified. But it worked, the customer got his extended bios without 
>>> having to change his bios and I got paid. And really, as we used to 
>>> say, in the end its all 'bits, in silicon'.
>>>
>>
>> It is a method called 'tail-ending' in compilers. Any reasonably recent
>> version of the GNU GCC is able to do it without programmer assistance,
>> except selecting high enough optimization levele when compiling.
>>
> I am sure that optimizing for size would use something like that. It is 
> fractionally *slower*


It does. The GCC switch is -Os. In practice the speed difference in not
noticeable.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web