Re: no stack

From	Melzzzzz <mel@zzzzz.com>
Newsgroups	comp.lang.c
Subject	Re: no stack
Date	2015-03-22 13:23 +0100
Organization	albasani.net
Message-ID	<20150322132315.785d669c@maxa-pc> (permalink)
References	<347790b0-5f11-4008-b254-5b5d5229a387@googlegroups.com> <20150322123753.653bc1b7@maxa-pc> <8bdbff2a-eea1-47a6-99ff-65152d93dc72@googlegroups.com>

Show all headers | View raw

On Sun, 22 Mar 2015 05:06:27 -0700 (PDT)
fir <profesor.fir@gmail.com> wrote:

> W dniu niedziela, 22 marca 2015 12:38:03 UTC+1 użytkownik Melzzzzz
> napisał:
> > On Sun, 22 Mar 2015 02:09:00 -0700 (PDT)
> > fir <profesor.fir@gmail.com> wrote:
> > 
> > > 'no stack' is a bit hype/slogan (could be good to easier
> > > remembering the subject postulate)
> > > 
> > > I mean here that i wonder if c compiler 
> > > would just not use stack for args and locals 
> > > and just used static data everywhere by default (axcept the rere
> > > thing where you explicitely will denote some data as auto
> > > and such variable would be created/dropped on stack) - if it will
> > > not make 1) significently simpler 
> > 
> > No. Stack managing is simpler
> > 
> 
> why? i dont see it .. 

There is no linking problems with stack management.
One only adjust stack pointer.

> 
> > > 2) faster
> > 
> > Show example where global data is faster?
> > Actually stack is almost all the time in cache.
> > 
> stack has its cost of its managment,

but far less than managing global variables...
That's why it is preferred.

> also if you use the same ram lines for
> reading and writing one args/locals 
> a while later for other args/locals 
> you must revrite it etc (acceses are 
> dependant in time), with static you
> may just leave one and go to another
> not waiting

You forgot that accessing cache is much
more faster than DRAM.

> 
> thode local and args areas probably 
> willbe also in cache, some differences my
> differ but i dont see right now clear reason 
> for this to work worse

Nope. They will not be in cache.

> 
> > > 3) smaller
> > 
> > Nope. Maintaining global variables is bigger.
> > 
>  weak answer, (almost like untorelably weak as on my standards of
> discussion) (do you counted it to say "nope"? do you forget about the
> push pop in your calulation ?

You forgot that executable will be bloated with large amount
of data.

 (you do not mention it)), also how
> bigger you get it by adresing not a big amount of .bss (for very
> small system it could be sparing of couple hundreds of ints - but
> this is special case you can explicitely make args and locals work on
> stack by u8sing 'auto')

Complexity of linking and finding right address far outweighs
anything even remotely ...

> 
> > 
> > > 4) more potent for some usable techniques
> > 
> > What are these?
> > 
> probably many techniques that could 
> work only when you have locals/args
> static, this is side depth topic here
> and i probably will say on this but
> on another ocassion

Name one?

> 
> > > 
> > > executables
> > > 
> > > (stack would be used for call ret adresses
> > > and for rare data explicitely denoted as auto (though i wonder if
> > > such auto data shouldnt be placed on speparate stack, not the
> > > same as ret/call one)
> > 
> > Why? This is almost surely slower.
> > 
> > > 
> > > I seem to being convinced that this static no stack version
> > > should be considered as a default implementation in c programs)
> > > (nearly sure that this would be better options, though test
> > > should be done to prove this, and such test are burdensome a bit)
> > 
> > Hm, what about reentrancy and threads?
> > 
> what do you mean exactly?

I mean multi threaded programs, how they would work with static locals
and god forbid args?

> 
> > > 
> > > [fir]
> > >

Thread

no stack fir <profesor.fir@gmail.com> - 2015-03-22 02:09 -0700
  Re: no stack wssimms@gmail.com - 2015-03-22 02:52 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:04 -0700
      Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 13:15 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:37 -0700
  Re: no stack Lőrinczy Zsigmond <nospam@for.me> - 2015-03-22 11:10 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 03:30 -0700
  Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:15 +0100
    Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:23 +0100
      Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:24 +0100
      Re: no stack jacob navia <jacob@jacob.remcomp.fr> - 2015-03-22 11:41 +0100
        Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-22 12:18 -0700
          Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 20:25 +0100
      Re: no stack Stephen Sprunk <stephen@sprunk.org> - 2015-03-23 12:17 -0500
      Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-23 13:22 -0400
  Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 11:13 +0000
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:29 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:33 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:39 -0700
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:46 -0700
      Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:16 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:25 -0700
          Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 12:59 +0000
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:15 -0700
              Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:39 +0100
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 19:47 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:18 -0700
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 11:21 +0000
                Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-23 11:35 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:07 -0700
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:28 -0700
                Re: no stack Bartc <bc@freeuk.com> - 2015-03-23 14:56 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 08:13 -0700
                Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:01 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-23 13:14 +0100
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:30 -0700
        Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:15 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 04:49 -0700
  Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 12:37 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:06 -0700
      Re: no stack Melzzzzz <mel@zzzzz.com> - 2015-03-22 13:23 +0100
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:48 -0700
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 08:51 -0700
          Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:39 -0700
            Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:54 -0700
      Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 14:45 +0100
        Re: no stack Richard Heathfield <rjh@cpax.org.uk> - 2015-03-22 14:20 +0000
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 15:43 +0100
          Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:09 -0700
            Re: no stack Bartc <bc@freeuk.com> - 2015-03-22 20:38 +0000
              Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 13:54 -0700
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 02:08 -0700
                Re: no stack Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-23 12:07 +0000
                Re: no stack fir <profesor.fir@gmail.com> - 2015-03-23 07:13 -0700
              Re: no stack Kaz Kylheku <kaz@kylheku.com> - 2015-03-22 20:59 +0000
        Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 07:35 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 16:27 +0100
    Re: no stack fir <profesor.fir@gmail.com> - 2015-03-22 05:10 -0700
  Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-22 13:56 +0100
  Re: no stack John Bode <jfbode1029@gmail.com> - 2015-03-24 09:01 -0700
    Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-24 12:30 -0700
      Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 09:16 +0100
        Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 09:00 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 17:33 +0100
            Re: no stack James Kuyper <jameskuyper@verizon.net> - 2015-03-25 13:35 -0400
            Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:22 -0700
              Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 08:54 +0100
                Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-26 08:48 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-26 23:00 +0100
                Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:15 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-28 18:17 +0100
                Re: no stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 12:36 -0700
                Re: no stack Richard Damon <Richard@Damon-Family.org> - 2015-03-28 17:33 -0400
                Re: no stack Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 08:04 -0700
                Re: no stack David Brown <david.brown@hesbynett.no> - 2015-04-07 00:39 +0200
              Re: no stack fir <profesor.fir@gmail.com> - 2015-03-26 01:21 -0700
        Re: no stack Keith Thompson <kst-u@mib.org> - 2015-03-25 10:57 -0700
          Re: no stack David Brown <david.brown@hesbynett.no> - 2015-03-25 21:55 +0100

csiph-web