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

Groups > comp.lang.c++ > #68773 > unrolled thread

alloca()-support

Started byBonita Montero <Bonita.Montero@gmail.com>
First post2019-09-30 14:02 +0200
Last post2019-10-05 14:08 -0700
Articles 20 on this page of 110 — 21 participants

Back to article view | Back to comp.lang.c++

Contents

  alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 14:02 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-09-30 07:02 -0700
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:09 +0200
        Re: alloca()-support Bo Persson <bo@bo-persson.se> - 2019-09-30 17:29 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:33 +0200
      Re: alloca()-support gazelle@shell.xmission.com (Kenny McCormack) - 2019-09-30 16:26 +0000
    Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:12 +0300
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:16 +0200
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:30 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:44 +0200
            Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 00:36 +0300
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:08 +0300
                  Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:42 +0200
      Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 14:30 +0000
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:33 +0300
          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-09-30 16:56 +0200
      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-30 15:29 +0000
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:31 +0200
          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 07:03 +0000
            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 10:57 +0200
              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:49 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:20 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:39 +0000
                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:15 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:29 +0000
      Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:14 -0700
    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:04 +0200
      Re: alloca()-support William Ahern <william@25thandClement.com> - 2019-09-30 11:01 -0700
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:19 +0200
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-30 22:26 +0300
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:46 +0000
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:32 +0200
        Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-01 09:08 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 08:35 +0200
    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:48 +0200
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:51 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:55 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:58 +0200
            Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:53 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:13 -0700
              Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:38 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:41 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 15:19 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 17:31 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:58 +0000
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:24 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:28 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:30 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:36 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:01 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:42 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:10 +0200
                                  Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:13 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 21:10 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:25 +0200
                          Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:44 +0000
                          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 23:26 +0200
                            Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-01 21:08 -0600
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:19 +0200
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:39 +0200
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:34 +0200
                          Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:14 +0200
                      Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:18 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:21 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 04:09 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:48 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 05:49 +0000
                                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:52 +0200
                                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 06:46 +0000
                                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 10:59 +0200
                Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 13:39 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 13:23 +0000
                  Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-03 15:38 +0200
                    Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 14:51 +0000
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:49 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:47 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:53 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:52 +0200
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:39 +0200
          Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 21:36 -0400
        Re: alloca()-support Philipp Klaus Krause <pkk@spth.de> - 2019-09-30 19:14 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:16 +0200
            Re: alloca()-support Robert Wessel <robertwessel2@yahoo.com> - 2019-10-01 00:18 -0500
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:43 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-01 02:42 -0700
                Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-01 08:11 -0400
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 14:53 +0200
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 17:52 +0000
      Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 11:20 -0600
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:42 +0200
          Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:02 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:54 +0200
          Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 14:28 -0600
            Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 09:38 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:01 +0200
          Re: alloca()-support Manfred <noname@add.invalid> - 2019-10-01 17:45 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 00:03 -0700
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-02 11:30 +0300
      Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:34 +1300
        Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 01:36 -0700
          Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:41 +1300
            Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:28 -0700
    Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 02:35 -0700
      Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:43 -0700
      Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:26 +0300
        Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 12:33 -0700
          Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 01:47 +0300
            Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-05 14:08 -0700

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

#68890

FromDavid Brown <david.brown@hesbynett.no>
Date2019-10-02 10:19 +0200
Message-ID<qn1mjg$jjc$1@dont-email.me>
In reply to#68876
On 02/10/2019 05:08, Joe Pfeiffer wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 01/10/2019 21:25, Bonita Montero wrote:
>>>> I don't know this case, but typically on modern cpus "complex"
>>>> instructions like "leave" are slower than manual expanding the
>>>> instructions using "pop", "ret", etc.
>>>
>>> That's wrong.
>>
>> As a general point, I don't think it is wrong - but from your posting it
>> looks like it does not apply in the case of "leave".  At least, gcc uses
>> it, which is a reasonable indicator that it is more efficient than
>> separate instructions.
>>
>> A little googling suggests that the "enter" instruction is slower than
>> the individual instructions, but that "leave" is quite fast.  There are
>> plenty of other legacy CISC instructions that are slower than breaking
>> them apart into equivalent simpler instructions, such as the "LOOP"
>> instructions.  I'm sure x86 assembly experts could give you more.
>>
>> I've seen the same thing on other processors too.  IIRC, on the 68060
>> the hardware integer division instruction was slower than a software
>> division routine.
> 
> There was a time when it was true.  I'd be pretty surprised if it still
> were.
> 

I'm not quite sure what you mean by that.  You are surely not saying the
68060 hardware division has got faster recently, or that software
division code for it has got slower!

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

#68884

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-02 06:39 +0200
Message-ID<qn19mf$1u1$1@news.albasani.net>
In reply to#68874
>> That's wrong.

> As a general point, I don't think it is wrong - ...

CISC-like instructions that are used often in x86 are usually mapped to
the same uOPS, but they use only one slot in the decoder.

> A little googling suggests that the "enter" instruction is slower
> than the individual instructions, but that "leave" is quite fast.

ENTER isn't used because it is used to allocate static stack-frames,
i.e. stack-frames without variable parts like VLAs or alloca()-frames.
But static stack-frames are used by the compilers without EBP, so ENTER
isn't needed. But that doesn't mean that it is not efficient.

> There are plenty of other legacy CISC instructions that are slower
> than breaking them apart into equivalent simpler instructions, such
> as the "LOOP" instructions. ...

My Ryzen needs 2 clock-cycles for LOOP if the branch is taken; that's
the same number of clock cycles if you would assemble it from simpler
instructions.

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

#68893

FromDavid Brown <david.brown@hesbynett.no>
Date2019-10-02 10:34 +0200
Message-ID<qn1nfi$prp$1@dont-email.me>
In reply to#68884
On 02/10/2019 06:39, Bonita Montero wrote:
>>> That's wrong.
> 
>> As a general point, I don't think it is wrong - ...
> 
> CISC-like instructions that are used often in x86 are usually mapped to
> the same uOPS, but they use only one slot in the decoder.
> 
>> A little googling suggests that the "enter" instruction is slower
>> than the individual instructions, but that "leave" is quite fast.
> 
> ENTER isn't used because it is used to allocate static stack-frames,
> i.e. stack-frames without variable parts like VLAs or alloca()-frames.
> But static stack-frames are used by the compilers without EBP, so ENTER
> isn't needed. But that doesn't mean that it is not efficient.
> 

"enter" is only potentially useful when you have a fixed stack frame but
want a frame pointer - that is true.  And usually you don't bother with
a frame pointer (they used to be popular for debuggers, but debuggers
are smarter these days).

But "enter" is not used even when it could be used, because it is very
slow.  It is microcoded, and takes 12 micro-ops on modern x86 devices -
far more than "push ebp", "mov ebp, esp", "sub esp, xxxx" that replace it.

>> There are plenty of other legacy CISC instructions that are slower
>> than breaking them apart into equivalent simpler instructions, such
>> as the "LOOP" instructions. ...
> 
> My Ryzen needs 2 clock-cycles for LOOP if the branch is taken; that's
> the same number of clock cycles if you would assemble it from simpler
> instructions.

Interesting.  On an Intel Skylake it is 7 µ-ops for a "loop" and 11 for
a "loopne".

<https://www.agner.org/optimize/instruction_tables.pdf>
<https://www.agner.org/optimize/>


This is why I rely on the compiler to generate good code for particular
chips.  The x86 assembly world is too chaotic for my liking.

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

#68908

FromMel <mel@zzzzz.com>
Date2019-10-02 15:14 +0200
Message-ID<almarsoft.328863032598644212@news.albasani.net>
In reply to#68868
On Tue, 1 Oct 2019 21:25:12 +0200, Bonita Montero 
<Bonita.Montero@gmail.com> wrote:
> > I don't know this case, but typically on modern cpus "complex"
> > instructions like "leave" are slower than manual expanding the
> > instructions using "pop", "ret", etc.


> That's wrong.

Experience with x86 tells opozite. Obvious example is loop 
instruction...

-- 
Press any key to continue or any other to quit

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

#68909

FromMel <mel@zzzzz.com>
Date2019-10-02 15:18 +0200
Message-ID<almarsoft.6100292897320709739@news.albasani.net>
In reply to#68856
On Tue, 1 Oct 2019 17:31:09 +0200, Bonita Montero 
<Bonita.Montero@gmail.com> wrote:
> >> The compiler usually uses RPB to remember the 
frame-pointer-address
> >> at the prolog of the function. EBP is more suitable because it 
can
> >> be restored in one step by the x86 LEAVE-instruction.


> > So what?  The RSP is restored automatically by the ret 
instruction.


> Yes, but LEAVE does three instructions in one step. Usually this
> results in the same uOPs, but it is only one slot in the decoder.

Problem is that you need rbp only for debugging purpose... One common 
option is omit-frame-pointer... Redusing bloat significantly....

-- 
Press any key to continue or any other to quit

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

#68910

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-02 15:21 +0200
Message-ID<qn287u$bsv$1@news.albasani.net>
In reply to#68909
> Problem is that you need rbp only for debugging purpose... One common 
> option is omit-frame-pointer... Redusing bloat significantly....

We're talking about dynamic stack-frames with alloca() or VLAs.
In this case EBP is usually used to store the frame-pointer even
with optimized code.

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

#68930

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-03 04:09 +0000
Message-ID<UvelF.740490$HWr.718838@fx36.am4>
In reply to#68910
On 2019-10-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Problem is that you need rbp only for debugging purpose... One common 
>> option is omit-frame-pointer... Redusing bloat significantly....
>
> We're talking about dynamic stack-frames with alloca() or VLAs.
> In this case EBP is usually used to store the frame-pointer even
> with optimized code.

So, alloca works against optimizations...
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#68931

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-03 07:48 +0200
Message-ID<qn423b$uuv$1@news.albasani.net>
In reply to#68930
>> We're talking about dynamic stack-frames with alloca() or VLAs.
>> In this case EBP is usually used to store the frame-pointer even
>> with optimized code.

> So, alloca works against optimizations...

alloca() is an optimization.

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

#68932

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-03 05:49 +0000
Message-ID<wZflF.2169158$c8w1.1690421@fx08.am4>
In reply to#68931
On 2019-10-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> We're talking about dynamic stack-frames with alloca() or VLAs.
>>> In this case EBP is usually used to store the frame-pointer even
>>> with optimized code.
>
>> So, alloca works against optimizations...
>
> alloca() is an optimization.

What optimization as it slows down code?
>
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#68933

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-03 07:52 +0200
Message-ID<qn42bn$tbb$1@news.albasani.net>
In reply to#68932
>> alloca() is an optimization.

> What optimization as it slows down code?

Boy, you're so stupid.

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

#68935

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-03 06:46 +0000
Message-ID<2PglF.746850$HWr.432054@fx36.am4>
In reply to#68933
On 2019-10-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> alloca() is an optimization.
>
>> What optimization as it slows down code?
>
> Boy, you're so stupid.

Look into mirror...
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#68943

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-03 10:59 +0200
Message-ID<qn4da1$7o2$1@news.albasani.net>
In reply to#68935
Your comments are very often stupid.

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

#68950

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2019-10-03 13:39 +0200
Message-ID<qn4mlg$3f4$2@dont-email.me>
In reply to#68818
On 30/09/2019 21:38, Scott Lurndal wrote:
> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>> On 30/09/2019 18:58, Bonita Montero wrote:
>>>>>> Since when (if at any time) was variable size automatic
>>>>>> array supported ?
>>>
>>>>> Since C99.
>>>
>>>> for curiosity, this feature has one or more of the
>>>> limitations I feared ... or even none of them ?
>>>
>>> Yes, you could run out of stack-space, maybe hitting a
>>> guard-page
>>> in the best case so that you wouldn't corrupt any other data.
>>
>> uhm, I didn't mean THAT kind of risk (unavoidable), but the
>> possible difficulties in defining variables beyond the point
>> of declaration of the variable-size array.
>>
>> I can't figure out how the compiler would reference them in
>> standard efficient ways (use of registers).
> 
> 
>       mov %rsp, %rax     # rax now has starting address of alloca() region
>       sub %rcx, %rsp     # rcx is the number of bytes being allocated.
> 
> ....
> 
>       mov %rsp, %rbx     # rbx now has starting address of second alloca() region
>       sub %rdx, %rsp     # rdx is the number of bytes being allocated
> ....
>       ret                # all alloca storage is deallocated
> 


I guess this disassembly does not correspond with the 
minimal example I asked for.
I actually do not have a compiler supporting this, so I 
cannot try myself


the code I'd like to see in .asm intermediate code (NO 
OPTIMIZATION ACTIVE) was



int Funz (int A, int B)
{
int C = 3;
int Buf [A];
int D = 2;
Buf [A-1] = B;
return (A + B * D - C);
}

int main (void)
{
return Funz (4, 3);
}

could you print the .asm generated for this, if your 
compiler supports variable arrays on stack ?

TNX




> (AT&T form)
> 
> It can always spill rax or rbx to the stack under register pressure.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#68956

Fromscott@slp53.sl.home (Scott Lurndal)
Date2019-10-03 13:23 +0000
Message-ID<cDmlF.9601$KB2.8901@fx02.iad>
In reply to#68950
Soviet_Mario <SovietMario@CCCP.MIR> writes:
>On 30/09/2019 21:38, Scott Lurndal wrote:
>> Soviet_Mario <SovietMario@CCCP.MIR> writes:
>>> On 30/09/2019 18:58, Bonita Montero wrote:
>>>>>>> Since when (if at any time) was variable size automatic
>>>>>>> array supported ?

>the code I'd like to see in .asm intermediate code (NO 
>OPTIMIZATION ACTIVE) was
>
>
>
>int Funz (int A, int B)
>{
>int C = 3;
>int Buf [A];
>int D = 2;
>Buf [A-1] = B;
>return (A + B * D - C);
>}
>
00000000004004f0 <Funz>:
  4004f0:	55                   	push   %rbp
  4004f1:	48 89 e5             	mov    %rsp,%rbp
  4004f4:	53                   	push   %rbx
  4004f5:	48 83 ec 38          	sub    $0x38,%rsp           // Reserve frame
  4004f9:	89 7d cc             	mov    %edi,-0x34(%rbp)
  4004fc:	89 75 c8             	mov    %esi,-0x38(%rbp)
  4004ff:	48 89 e0             	mov    %rsp,%rax
  400502:	48 89 c6             	mov    %rax,%rsi
  400505:	c7 45 ec 03 00 00 00 	movl   $0x3,-0x14(%rbp)
  40050c:	8b 45 cc             	mov    -0x34(%rbp),%eax
  40050f:	48 63 f8             	movslq %eax,%rdi
  400512:	48 83 ef 01          	sub    $0x1,%rdi
  400516:	48 89 7d e0          	mov    %rdi,-0x20(%rbp)
  40051a:	48 63 f8             	movslq %eax,%rdi
  40051d:	49 89 f8             	mov    %rdi,%r8
  400520:	41 b9 00 00 00 00    	mov    $0x0,%r9d
  400526:	48 63 f8             	movslq %eax,%rdi
  400529:	48 89 fa             	mov    %rdi,%rdx
  40052c:	b9 00 00 00 00       	mov    $0x0,%ecx
  400531:	48 98                	cltq   
  400533:	48 c1 e0 02          	shl    $0x2,%rax
  400537:	48 8d 50 03          	lea    0x3(%rax),%rdx
  40053b:	b8 10 00 00 00       	mov    $0x10,%eax
  400540:	48 83 e8 01          	sub    $0x1,%rax
  400544:	48 01 d0             	add    %rdx,%rax
  400547:	bb 10 00 00 00       	mov    $0x10,%ebx
  40054c:	ba 00 00 00 00       	mov    $0x0,%edx
  400551:	48 f7 f3             	div    %rbx
  400554:	48 6b c0 10          	imul   $0x10,%rax,%rax
  400558:	48 29 c4             	sub    %rax,%rsp           // Allocate Buf[A]
  40055b:	48 89 e0             	mov    %rsp,%rax           // %rax = &Buf[0]
  40055e:	48 83 c0 03          	add    $0x3,%rax           // dword align pointer
  400562:	48 c1 e8 02          	shr    $0x2,%rax
  400566:	48 c1 e0 02          	shl    $0x2,%rax
  40056a:	48 89 45 d8          	mov    %rax,-0x28(%rbp)    // Save Buf addr in frame
  40056e:	c7 45 d4 02 00 00 00 	movl   $0x2,-0x2c(%rbp)
  400575:	8b 45 cc             	mov    -0x34(%rbp),%eax
  400578:	8d 50 ff             	lea    -0x1(%rax),%edx
  40057b:	48 8b 45 d8          	mov    -0x28(%rbp),%rax
  40057f:	48 63 d2             	movslq %edx,%rdx
  400582:	8b 4d c8             	mov    -0x38(%rbp),%ecx
  400585:	89 0c 90             	mov    %ecx,(%rax,%rdx,4)
  400588:	8b 45 c8             	mov    -0x38(%rbp),%eax
  40058b:	0f af 45 d4          	imul   -0x2c(%rbp),%eax
  40058f:	89 c2                	mov    %eax,%edx
  400591:	8b 45 cc             	mov    -0x34(%rbp),%eax
  400594:	01 d0                	add    %edx,%eax
  400596:	2b 45 ec             	sub    -0x14(%rbp),%eax
  400599:	48 89 f4             	mov    %rsi,%rsp
  40059c:	48 8b 5d f8          	mov    -0x8(%rbp),%rbx
  4005a0:	c9                   	leaveq 
  4005a1:	c3                   	retq

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

#68958

FromDavid Brown <david.brown@hesbynett.no>
Date2019-10-03 15:38 +0200
Message-ID<qn4tki$j48$1@dont-email.me>
In reply to#68950
On 03/10/2019 13:39, Soviet_Mario wrote:

> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
> ACTIVE) was
> 

Examining generated assembly code with no optimisation is usually
pointless.  If you care about the efficiency of the assembly, you will
have optimisation enabled on the compiler.  Looking at the assembly
generated with optimisation off tells you practically nothing.

The tool you want here is the webpage <https://godbolt.org>.  It is an
online compiler site, letting you type small bits of code and compile it
with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
not the only choice) and using whatever options you want (like "-x c
-std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).

Use that site to see the generated code, and perhaps these newsgroups to
ask /why/ you get particular code.  It's better than asking people in
these groups to compile code snippets for you, at least for standard
compilers.

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

#68969

Fromscott@slp53.sl.home (Scott Lurndal)
Date2019-10-03 14:51 +0000
Message-ID<qVnlF.37800$iJ2.34840@fx47.iad>
In reply to#68958
David Brown <david.brown@hesbynett.no> writes:
>On 03/10/2019 13:39, Soviet_Mario wrote:
>
>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>> ACTIVE) was
>> 
>
>Examining generated assembly code with no optimisation is usually
>pointless.  If you care about the efficiency of the assembly, you will
>have optimisation enabled on the compiler.  Looking at the assembly
>generated with optimisation off tells you practically nothing.

Although the example he provided optimizes (-O3) down to:

0000000000400400 <main>:
  400400:       b8 07 00 00 00          mov    $0x7,%eax
  400405:       c3                      retq

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

#69021

FromDavid Brown <david.brown@hesbynett.no>
Date2019-10-04 09:49 +0200
Message-ID<qn6thq$dv4$4@dont-email.me>
In reply to#68969
On 03/10/2019 16:51, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 03/10/2019 13:39, Soviet_Mario wrote:
>>
>>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>>> ACTIVE) was
>>>
>>
>> Examining generated assembly code with no optimisation is usually
>> pointless.  If you care about the efficiency of the assembly, you will
>> have optimisation enabled on the compiler.  Looking at the assembly
>> generated with optimisation off tells you practically nothing.
> 
> Although the example he provided optimizes (-O3) down to:
> 
> 0000000000400400 <main>:
>   400400:       b8 07 00 00 00          mov    $0x7,%eax
>   400405:       c3                      retq   
> 

Yes.  You need to write code that actually /does/ something, then
compile it with optimisation enabled, if you want to see how the
compiler handles particular code constructs.  Usually you do that by
having a function whose output depends on an input (either with
parameters and return values, or using file-scope variables).

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

#69000

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2019-10-03 21:47 +0200
Message-ID<qn5j9d$au$1@dont-email.me>
In reply to#68958
On 03/10/2019 15:38, David Brown wrote:
> On 03/10/2019 13:39, Soviet_Mario wrote:
> 
>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>> ACTIVE) was
>>
> 
> Examining generated assembly code with no optimisation is usually
> pointless.  If you care about the efficiency of the assembly, you will
> have optimisation enabled on the compiler.  Looking at the assembly
> generated with optimisation off tells you practically nothing.
> 
> The tool you want here is the webpage <https://godbolt.org>.  It is an
> online compiler site, letting you type small bits of code and compile it
> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
> not the only choice) and using whatever options you want (like "-x c
> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).

amazing ! Didn't know that

> 
> Use that site to see the generated code, and perhaps these newsgroups to
> ask /why/ you get particular code.  It's better than asking people in
> these groups to compile code snippets for you, at least for standard
> compilers.

sorry but I was not aware of that site. Thanks

TNX also to Scott Lurndall who got me the code.

I'm trying to understand sth out of it but I'm very rusty 
with asm


> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

#69022

FromDavid Brown <david.brown@hesbynett.no>
Date2019-10-04 09:53 +0200
Message-ID<qn6tpp$grd$1@dont-email.me>
In reply to#69000
On 03/10/2019 21:47, Soviet_Mario wrote:
> On 03/10/2019 15:38, David Brown wrote:
>> On 03/10/2019 13:39, Soviet_Mario wrote:
>>
>>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>>> ACTIVE) was
>>>
>>
>> Examining generated assembly code with no optimisation is usually
>> pointless.  If you care about the efficiency of the assembly, you will
>> have optimisation enabled on the compiler.  Looking at the assembly
>> generated with optimisation off tells you practically nothing.
>>
>> The tool you want here is the webpage <https://godbolt.org>.  It is an
>> online compiler site, letting you type small bits of code and compile it
>> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
>> not the only choice) and using whatever options you want (like "-x c
>> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).
> 
> amazing ! Didn't know that
> 
>>
>> Use that site to see the generated code, and perhaps these newsgroups to
>> ask /why/ you get particular code.  It's better than asking people in
>> these groups to compile code snippets for you, at least for standard
>> compilers.
> 
> sorry but I was not aware of that site. Thanks

I'm glad to help.  Once you start using that site, you will quickly get
addicted.

> 
> TNX also to Scott Lurndall who got me the code.
> 
> I'm trying to understand sth out of it but I'm very rusty with asm
> 

The more you play with godbolt.org, the more you'll get used to it.

One tip when generating x86 assembly on the site - there is a checkbox
labelled "Intel" that lets you choose between Intel format assembly, and
AT&T format assembly.  People with *nix backgrounds often find the AT&T
format more familiar, people with Windows backgrounds often prefer the
Intel format.  Some people get /really/ worked up about it and think
anyone who doesn't agree with their personal opinions on the choice, are
clearly insane.  I recommend trying both and using the one that looks
clearer to you.

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

#69001

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2019-10-03 21:52 +0200
Message-ID<qn5jhq$3jg$1@dont-email.me>
In reply to#68958
On 03/10/2019 15:38, David Brown wrote:
> On 03/10/2019 13:39, Soviet_Mario wrote:
> 
>> the code I'd like to see in .asm intermediate code (NO OPTIMIZATION
>> ACTIVE) was
>>
> 
> Examining generated assembly code with no optimisation is usually
> pointless.  If you care about the efficiency of the assembly, you will
> have optimisation enabled on the compiler.  Looking at the assembly
> generated with optimisation off tells you practically nothing.
> 
> The tool you want here is the webpage <https://godbolt.org>.  It is an
> online compiler site, letting you type small bits of code and compile it
> with a wide variety of compilers ("x86-64 gcc (trunk)" is popular, but
> not the only choice) and using whatever options you want (like "-x c
> -std=c11 -O2 -Wall -Wpedantic" as a reasonable starting point).

wow it does also colorize the output and flashes the areas 
corresponding to the cursor ! Very invaluable feature. Molto 
obbligato !
Ciao

> 
> Use that site to see the generated code, and perhaps these newsgroups to
> ask /why/ you get particular code.  It's better than asking people in
> these groups to compile code snippets for you, at least for standard
> compilers.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

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

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

Back to top | Article view | comp.lang.c++

csiph-web