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

Groups > comp.lang.c > #58632 > unrolled thread

no stack

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

Contents

  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

Page 1 of 4  [1] 2 3 4  Next page →

#58632 — no stack

'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 
2) faster
3) smaller
4) more potent for some usable techniques

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)

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)

[fir]

[toc] | [next] | [standalone]

#58636

Am Sonntag, 22. März 2015 18:09:08 UTC+9 schrieb fir:
> '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 
> 2) faster
> 3) smaller
> 4) more potent for some usable techniques
> 
> 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)
> 
> 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)

There is no obligation for a C compiler to allocate anything "on the stack", as long as the
behavior described in the standard is maintained.

If you disagree with the behavior mandated in the standard, then go make your own
programming language. That would be better than spamming this newsgroup.

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

#58639

W dniu niedziela, 22 marca 2015 10:52:23 UTC+1 użytkownik wss...@gmail.com napisał:
> Am Sonntag, 22. März 2015 18:09:08 UTC+9 schrieb fir:
> > '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 
> > 2) faster
> > 3) smaller
> > 4) more potent for some usable techniques
> > 
> > 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)
> > 
> > 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)
> 
> There is no obligation for a C compiler to allocate anything "on the stack", as long as the
> behavior described in the standard is maintained.
> 
> If you disagree with the behavior mandated in the standard, then go make your own
> programming language. That would be better than spamming this newsgroup.

this is not spamming, and your 'advice' is obviously very stupid,

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

#58667

On 22/03/15 10:04, fir wrote:
> W dniu niedziela, 22 marca 2015 10:52:23 UTC+1 użytkownik wss...@gmail.com napisał:

<snip>

>> There is no obligation for a C compiler to allocate anything "on the stack", as long as the
>> behavior described in the standard is maintained.

wssimms is correct about this.

>>
>> If you disagree with the behavior mandated in the standard, then go make your own
>> programming language. That would be better than spamming this newsgroup.

He's right about this, too, except that he's misusing the word 
'spamming'. I think he probably means 'flooding'.

> this is not spamming, and your 'advice' is obviously very stupid,

It isn't stupid, and therefore it can't be very stupid, and therefore it 
can't be obviously very stupid, and therefore you are mistaken.

You may not agree with his advice, but that is not a proof that the 
advice is even wrong, let alone stupid.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#58672

W dniu niedziela, 22 marca 2015 14:15:52 UTC+1 użytkownik Richard Heathfield napisał:
> On 22/03/15 10:04, fir wrote:
> > W dniu niedziela, 22 marca 2015 10:52:23 UTC+1 użytkownik wss...@gmail.com napisał:
> 
> <snip>
> 
> >> There is no obligation for a C compiler to allocate anything "on the stack", as long as the
> >> behavior described in the standard is maintained.
> 
> wssimms is correct about this.
> 
> >>
> >> If you disagree with the behavior mandated in the standard, then go make your own
> >> programming language. That would be better than spamming this newsgroup.
> 
> He's right about this, too, except that he's misusing the word 
> 'spamming'. I think he probably means 'flooding'.
> 
> > this is not spamming, and your 'advice' is obviously very stupid,
> 
> It isn't stupid, and therefore it can't be very stupid, and therefore it 
> can't be obviously very stupid, and therefore you are mistaken.
> 
> You may not agree with his advice, but that is not a proof that the 
> advice is even wrong, let alone stupid.
> 
it is stupid, what is wise here?
 it is worse than meaningless.. not on point .. it only shows that the poster dislike my post and stupidly calls it a spam.. etc etc drown in stupidity of
this content.. drowned
if you call it a flod* it will not be much wiser, (oh wait, thing seems fitt, insulters simpletons gets angry ;i )

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

#58640

Certainly you have heard of recursion, haven't you?
Usually, the compiler cannot expect that the function it is compiling
won't be called recursively again by a function it calls.

extern void bar ();

void foo ()
{
     int local_variable;

     bar ();
}

here 'bar' might or might not call 'foo', we cannot tell,
so 'local_variable' has to be put on the stack.

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

#58645

W dniu niedziela, 22 marca 2015 11:10:55 UTC+1 użytkownik Lőrinczy Zsigmond napisał:
> Certainly you have heard of recursion, haven't you?
> Usually, the compiler cannot expect that the function it is compiling
> won't be called recursively again by a function it calls.
> 
> extern void bar ();
> 
> void foo ()
> {
>      int local_variable;
> 
>      bar ();
> }
> 
> here 'bar' might or might not call 'foo', we cannot tell,
> so 'local_variable' has to be put on the stack.

imo you could assume that most code will not be called recursivelly and if you want to call it recursively you could make "auto" keyword such auto ram will be populated

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

#58642

Le 22/03/2015 10:09, fir a écrit :
> 1) significently simpler
> 2) faster
> 3) smaller
> 4) more potent for some usable techniques

Finally someone who sees the benefits of such implementation. 
Brilliant minds think alike ( :-) ).

LCC has such feature planned for next version. The reason why it still 
has the old way in is because of compatibility with other libraries 
which use a stack. When only code is used that you compiled with LCC 
you can have very small fast and simple code. One problem with stacks 
is that they are not well defined. push and pop, it always causes 
confusion and nobody really know which one is which. This can lead to 
undefined behavior and I think that stack based programs have this 
problem always because not all compiler programmers (gcc) know this 
all the time. They get it right most of the time, but when they don't 
you have undefined behavior.

jacob

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

#58643

Le 22/03/2015 11:15, jacob navia a écrit :

This is again a forged message damm it!

The objective of this guy is to make me say nonsense.
If this continues I will be forced to stop posting here, what is what 
this guy wants

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

#58644

Le 22/03/2015 11:23, jacob navia a écrit :
> Le 22/03/2015 11:15, jacob navia a écrit :
>
> This is again a forged message damm it!
>
> The objective of this guy is to make me say nonsense.
> If this continues I will be forced to stop posting here, what is what
> this guy wants
>
>

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

#58646

Le 22/03/2015 11:24, jacob navia a écrit :

I am NOT the one who posted that rubbish.

It is forged message again! Anyone can see that I am not the message 
forger because of my correct mail address in the subject line 
(jacob@jacob.remcomp.fr).

jacob

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

#58683

jacob navia <jacob@jacob.remcomp.fr> writes:
> Le 22/03/2015 11:24, jacob navia a écrit :
> I am NOT the one who posted that rubbish.
>
> It is forged message again! Anyone can see that I am not the message
> forger because of my correct mail address in the subject line
> (jacob@jacob.remcomp.fr).

I don't know whether I'm replying to a forged message or not,
but I am addressing this to the real jacob.

The forger is now posting forged messages with your real e-mail
address, and you can prove it by replying to e-mail messages sent
to that address.  I suggest you contact aioe.org again.  They may
now be willing to trace the forger's IP address and take action.

Or you might consider changing Usenet providers.
eternal-september.org is also free of charge, and it requires
username/password authentication.  Forgeries would still be possible
(it's easy to fake headers), but they might be possible to detect
by examining the Path: header.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#58684

On Sun, 22 Mar 2015 12:18:14 -0700
Keith Thompson <kst-u@mib.org> wrote:

> jacob navia <jacob@jacob.remcomp.fr> writes:
> > Le 22/03/2015 11:24, jacob navia a écrit :
> > I am NOT the one who posted that rubbish.
> >
> > It is forged message again! Anyone can see that I am not the message
> > forger because of my correct mail address in the subject line
> > (jacob@jacob.remcomp.fr).
> 
> I don't know whether I'm replying to a forged message or not,
> but I am addressing this to the real jacob.
> 
> The forger is now posting forged messages with your real e-mail
> address, and you can prove it by replying to e-mail messages sent
> to that address.  I suggest you contact aioe.org again.  They may
> now be willing to trace the forger's IP address and take action.
> 
> Or you might consider changing Usenet providers.
> eternal-september.org is also free of charge, and it requires
> username/password authentication.  Forgeries would still be possible
> (it's easy to fake headers), but they might be possible to detect
> by examining the Path: header.
> 

Or albasani or solani. With account, one can report forgery.

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

#58767

On 22-Mar-15 05:23, jacob navia wrote:
> Le 22/03/2015 11:15, jacob navia a écrit :
> 
> This is again a forged message damm it!
> 
> The objective of this guy is to make me say nonsense.

You do that just fine on your own.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#58771

On 03/22/2015 06:23 AM, jacob navia wrote:
> Le 22/03/2015 11:15, jacob navia a écrit :
> 
> This is again a forged message damm it!
> 
> The objective of this guy is to make me say nonsense.
> If this continues I will be forced to stop posting here, what is what 
> this guy wants

Despite all of my disagreements with you, and despite the fact that I
would actively prefer it if you moved your lcc-win posts to the lcc
newsgroup, I don't think you should let this kind of attack drive you
off. If you let them drive you out of here, you've established the
principle that they can drive you out of any other usenet newsgroup, and
indeed, any other forum that is sufficiently open to the public. I won't
pretend that I would miss you, but I don't like seeing anyone give in to
this kind of pressure.

Remember - since they don't get any real world benefit from harassing
you - sooner or later they'll get bored. Help them get bored, by
treating them as a boring annoyance, not as an exciting menace. They'll
come back again - boredom isn't the perfect solution - but such
infestations are survivable, if you develop a sufficiently thick skin.

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

#58648

On 22/03/2015 09:09, fir 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

So exactly the same as now, except that local variables are static? Not 
exactly 'no stack'.

> explicitely will denote some data as auto
> and such variable would be created/dropped on stack) - if it will not make

> 1) significently simpler

It what way? Now you have to be constantly on the guard for functions 
that could be called recursively.

> 2) faster

My experiments suggest that static locals make it slower. Try it 
yourself: take any program, stick 'static' in front of each local 
declaration, and see what happens.

> 3) smaller

Not really. Now each access to a local variable needs a 32 or 64-bit 
absolute address, instead of an 8-bit offset. Plus you need static 
memory space for all the local variables of *all* functions in the 
application at the same time, whether or not they are active.

This larger memory requirement will also be spread out more, instead of 
being more localised on the stack, and may hit memory performance.

> 4) more potent for some usable techniques

You've got that back to front. Having local variables on a stack is more 
versatile.

-- 
Bartc

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

#58649

W dniu niedziela, 22 marca 2015 12:13:11 UTC+1 użytkownik Bart napisał:
> On 22/03/2015 09:09, fir 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
> 
> So exactly the same as now, except that local variables are static? Not 
> exactly 'no stack'.
> 
not exactly as im saying abouth both local variables and args (args make a bigger change compaired to present state of the things)

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

#58650

W dniu niedziela, 22 marca 2015 12:13:11 UTC+1 użytkownik Bart napisał:
> On 22/03/2015 09:09, fir wrote:
> 
> > 1) significently simpler
> 
> It what way? Now you have to be constantly on the guard for functions 
> that could be called recursively.
> 

no need to be constatntly guarded as 
in c programming you will use recursive
callings once a year or less or never
(and if you are using it you can denote it explicitely by auto keyword)

mainly binary representation will be simpler, you will be nit bothered by 
push/pop stack frame, just reference
static data and thats all, some layer 
will be not present

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

#58652

W dniu niedziela, 22 marca 2015 12:13:11 UTC+1 użytkownik Bart napisał:
> > 2) faster
> 
> My experiments suggest that static locals make it slower. Try it 
> yourself: take any program, stick 'static' in front of each local 
> declaration, and see what happens.
> 

i was doing some old experiments with static locals but right now i do not remember clearly the results (it was more
like no big difference or small gain,
not remember and dubt if i will notice
slowdown)
more deal is by turning stack passing at all and measure static argument passing
(can be somewhat simulated on c or hand assembly level 
but more real test would be compare
the whole work of unexistant compiler
that would copile to static, imo probably compiler working on static fields could probably better optymise things)

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

#58653

> > 3) smaller
> 
> Not really. Now each access to a local variable needs a 32 or 64-bit 
> absolute address, instead of an 8-bit offset. Plus you need static 
> memory space for all the local variables of *all* functions in the 
> application at the same time, whether or not they are active.
> 
there would be needed ram for all okal variables stored as static but this is no
big amout i think, how many you could have it in average 100klines program,
few thousands of ints/floats probably
(of mostly uninitialised ram)

probably you will got some spare of code on all those pushes and pops/stack pointer manipulations 

as to offset when storing locals as statick you could also use 8 bit offset
why no, you could also use it probably more than in stack version, as you probably could offset all args/variables in whole program with say 16 bit offset
as this is completely static

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web