Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106314 > unrolled thread
| Started by | Prashant Shah <pshah.mumbai@gmail.com> |
|---|---|
| First post | 2017-03-16 22:58 -0700 |
| Last post | 2017-03-19 13:26 +0100 |
| Articles | 13 on this page of 113 — 26 participants |
Back to article view | Back to comp.lang.c
Array allocated on stack or heap Prashant Shah <pshah.mumbai@gmail.com> - 2017-03-16 22:58 -0700
Re: Array allocated on stack or heap Barry Schwarz <schwarzb@dqel.com> - 2017-03-16 23:57 -0700
Re: Array allocated on stack or heap Mark Storkamp <mstorkamp@yahoo.com> - 2017-03-17 12:44 -0500
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 11:26 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:38 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:08 -0400
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:03 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 20:54 -0400
Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 12:15 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 20:22 +0100
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:45 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-17 12:59 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 21:01 +0100
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:12 +0100
Re: Array allocated on stack or heap jameskuyper@verizon.net - 2017-03-17 16:25 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 17:08 -0700
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-17 17:37 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 12:30 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 12:12 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:52 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:51 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 10:44 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 12:01 +0000
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 06:02 -0700
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:54 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 07:28 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 16:43 +0100
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-20 09:02 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 10:11 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:48 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:19 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:17 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-21 09:06 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 17:32 +0100
Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:14 -0500
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-25 16:05 -0700
Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 23:53 -0500
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 12:30 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-26 14:09 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 22:17 +0100
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 21:52 -0500
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-27 13:06 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-27 10:10 -0700
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:56 -0500
Re: Array allocated on stack or heap bartc <bc@freeuk.com> - 2017-03-27 22:48 +0100
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 19:58 -0500
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:56 +0100
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 15:34 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 09:28 -0700
Re: Array allocated on stack or heap bart4858@gmail.com - 2017-03-20 13:05 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 13:53 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 14:26 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 22:24 +0000
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 15:44 -0700
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:44 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 11:15 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 11:12 +0000
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 04:23 -0700
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:13 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 13:38 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 15:33 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:38 -0700
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:35 -0700
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 15:09 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:05 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:27 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:26 +0100
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:34 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:35 +0100
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:36 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 14:00 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 19:00 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 19:24 +0000
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 08:45 +1300
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 14:32 -0700
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:16 +1300
Re: Array allocated on stack or heap Gareth Owen <gwowen@gmail.com> - 2017-03-20 18:58 +0000
Re: Array allocated on stack or heap raltbos@xs4all.nl (Richard Bos) - 2017-03-24 09:17 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 20:50 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:10 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:38 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:49 +0100
Re: Array allocated on stack or heap luser droog <luser.droog@gmail.com> - 2017-03-20 07:59 -0700
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 10:57 -0400
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:14 +0000
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 15:53 -0400
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 20:37 +0000
Re: Array allocated on stack or heap Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-19 23:09 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:38 +0000
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 16:21 -0700
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:18 +1300
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:06 +0100
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:00 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-19 08:53 -0700
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:11 -0400
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 13:35 -0700
Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-17 14:00 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:57 +0100
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:42 +1300
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:45 +0100
Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-18 14:17 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 19:21 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-19 15:00 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:16 +0000
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 23:57 +0100
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 16:15 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 12:24 +0100
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:24 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:21 +0100
Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 14:30 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:59 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 21:02 -0400
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:26 +0100
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2017-03-18 14:17 -0700 |
| Message-ID | <f9f50c16-af70-4b1a-b8db-bfcddcd3c914@googlegroups.com> |
| In reply to | #106397 |
On Friday, March 17, 2017 at 3:57:40 PM UTC-7, jacobnavia wrote:
> Le 17/03/2017 à 22:00, Chad a écrit :
> > The one machine that I have uses a register based stack instead of a regular stack. As a result, there is really no such thing as pushing and popping numbers.
> >
>
> Most machines have up to 32 registers, maybe some have more.
>
> So, your register stack has place for 32 quantities, rather short for
> any serious problem or serious C software.
>
> Then, you will agree with me, there is a portion of memory that must be
> addressed in a stack like fashion each time you make a function call,
> for instance.
>
> Suppose this program:
>
> int fn1(int a)
> {
> return 25.87/3.14159 + a;
> }
>
>
> int main(void)
> {
> int a = 67;
> a += fn(1);
> printf("result=%d¡n",a);
> }
>
> When you enter the expression fn(1), and inside the fn function, a is
> assigned the value 1. The old value is pushed into the stack and is
> inaccessible until the called function pops the stack and returns into
> the main function with a result of the calculations done in the inner scope.
>
> This result is added to the old value of a that was popped when the
> function returned. We agree that within main the variable "a" has
> nothing to do with the value it had within "fn()".
>
> Calling a procedure or function means pushing into a conceptual stack
> all the values held by the current scope, operation that is balanced by
> a pop when the function returns.
>
> By the way your machine with a dedicated register stack is caching the
> top of this stack into machine registers, but that doesn't change the
> conceptual form of the data processing structure you are using: a stack.
>
> And what is the name of your mysterious machine?
Samsung on5 phone that runs Android.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-19 19:21 +0100 |
| Message-ID | <oami10$539$1@dont-email.me> |
| In reply to | #106453 |
Le 18/03/2017 à 22:17, Chad a écrit : > Samsung on5 phone that runs Android. But that's the KRAIT processor of Samsung! It is a ARM v7 architecture with the stack pointer in r15... Gosh, look the instruction set for your machine before you say that "there is no stack". There is no push and pop instruction but you use the equivalent instructions
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2017-03-19 15:00 -0700 |
| Message-ID | <01036705-6fe5-4262-8fd0-86eb5ef5f449@googlegroups.com> |
| In reply to | #106501 |
On Sunday, March 19, 2017 at 8:21:21 PM UTC+2, jacobnavia wrote: > Le 18/03/2017 à 22:17, Chad a écrit : > > Samsung on5 phone that runs Android. > > But that's the KRAIT processor of Samsung! First, it's Krait (lower case). Second, Krait is made by Qualcomm rather than Samsung. Third, Samsung Galaxy On5 does not contain Krait processor. It's main SoC called Exynos 3475, made by Samsung itself and contains 4 ARM Cortex A7 cores. > > It is a ARM v7 architecture with the stack pointer in r15... > > Gosh, look the instruction set for your machine before you say that > "there is no stack". There is no push and pop instruction but you use > the equivalent instructions It's true that ARMv7 contains something called 'stack pointer" in R13 (not R15). But it's also true that in ARMv7 in-memory stack is just a software convention. For example, there is no CALL instruction that decrements (or increments) R13 and then stores return address in location, pointed by R13. And there is nor RETURN instruction that loads value, pointed by R13 and then increments (or decrements) R13. PUSH and POP instruction do exist, but they are not functionally different from STM/LDM. So, may be, Chad didn't use the clearest wording, but in principle he is correct.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-19 22:16 +0000 |
| Message-ID | <oamvq8$mec$1@dont-email.me> |
| In reply to | #106518 |
On 19/03/2017 22:00, already5chosen@yahoo.com wrote: > On Sunday, March 19, 2017 at 8:21:21 PM UTC+2, jacobnavia wrote: >> Le 18/03/2017 à 22:17, Chad a écrit : >>> Samsung on5 phone that runs Android. >> >> But that's the KRAIT processor of Samsung! > > First, it's Krait (lower case). > Second, Krait is made by Qualcomm rather than Samsung. > Third, Samsung Galaxy On5 does not contain Krait processor. It's main SoC called Exynos 3475, made by Samsung itself and contains 4 ARM Cortex A7 cores. > >> >> It is a ARM v7 architecture with the stack pointer in r15... >> >> Gosh, look the instruction set for your machine before you say that >> "there is no stack". There is no push and pop instruction but you use >> the equivalent instructions > > It's true that ARMv7 contains something called 'stack pointer" in R13 (not R15). > But it's also true that in ARMv7 in-memory stack is just a software convention. > For example, there is no CALL instruction that decrements (or increments) R13 and then stores return address in location, pointed by R13. And there is nor RETURN instruction that loads value, pointed by R13 and then increments (or decrements) R13. > PUSH and POP instruction do exist, but they are not functionally different from STM/LDM. My ARM manual (for ARM1176JZF-S whatever that means) calls R13 a 'Stack Pointer'. > So, may be, Chad didn't use the clearest wording, but in principle he is correct. > He mentioned a register-based stack, which doesn't really mean anything, except suggesting the entire stack is contained within registers. That seems extraordinarily unlikely for a processor powering a smartphone. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-19 23:57 +0100 |
| Message-ID | <oan28a$tm6$1@dont-email.me> |
| In reply to | #106520 |
Le 19/03/2017 à 23:16, BartC a écrit : > He mentioned a register-based stack, which doesn't really mean anything, > except suggesting the entire stack is contained within registers. > > That seems extraordinarily unlikely for a processor powering a smartphone. Yes. :-) Unix like Android variety of smart phone... Why this eternal discussion? Again: In most CPUs there is a stack pointer and a hardware stack, that is mapped by the language to stacked function scopes. Except small micro-computers and weird old hardware, most microprocessors have a hardware stack. This allows to teach newcomers simple rules for developing software like: Automatic variables are in the stack and get freed automatically with just a machine instruction. All the temporary workspace we declare in local variables need not be freed after usage. Stack space is not unlimited however, and use with care. But with modern CPUs, this just doesn't matter. All depends on the application and some applications are constrained by RAM usage, for instance, and stack variables are to be avoided. By following simple rules you can avoid them, or indicate the compiler how to avoid them. But that is the exception to the rule: Local variables are thread safe by design and allocation/deallocation is not needed. They are used in a stack-like fashion, what is easy to conceptualize.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-19 16:15 -0700 |
| Message-ID | <lnk27kdfje.fsf@kst-u.example.com> |
| In reply to | #106522 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 19/03/2017 à 23:16, BartC a écrit :
[Sorry if the accented characters show up in correctly. jacob's article
has charset=utf-8, but for some reason my newsreader still doesn't
handle the accented characters correctly. For example an 'e' with an
accute accent shows up as \303\251, though can still enter é correctly.
It is a puzzlement.]
[...]
> Why this eternal discussion?
Yes, why?
> Again:
>
> In most CPUs there is a stack pointer and a hardware stack, that is
> mapped by the language to stacked function scopes.
(Quibble: lifetimes, not scopes. Scope refers only to compile-time
visibility of identifiers, not to memory allocation or lifetime.)
Yes, most, not all. The standard specifies that objects with
automatic storage duration are allocated in a stack-like last-in
first-out manner. The most common, but not universal, way to
implement that is via a hardware stack, where allocation takes
place within a contiguous region of memory typically managed by a
"stack pointer". The standard does not specify this implementation.
Other implementations are possible, but rare.
I think everyone who has discussed this here understands all
that. What exactly are you still arguing about? Do you object
to acknowledging that implementations other than a contiguous
hardware stack are both possible and actually used in the real world?
If so, why? Do you understand that the word "stack" has (at least)
two distinct meanings, and that some of us are simply trying to
keep that distinction clear?
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-20 12:24 +0100 |
| Message-ID | <oaoe00$c5o$1@dont-email.me> |
| In reply to | #106522 |
On 19/03/17 23:57, jacobnavia wrote:
> Le 19/03/2017 à 23:16, BartC a écrit :
>> He mentioned a register-based stack, which doesn't really mean anything,
>> except suggesting the entire stack is contained within registers.
>>
>> That seems extraordinarily unlikely for a processor powering a
>> smartphone.
>
> Yes. :-)
>
> Unix like Android variety of smart phone...
>
> Why this eternal discussion?
>
> Again:
>
> In most CPUs there is a stack pointer and a hardware stack, that is
> mapped by the language to stacked function scopes.
Yes. For some cpus, like ARM (other than Thumb) and PPC, there is no
dedicated stack pointer - there is merely the convention that one of the
registers is usually used for a stack, and there are no dedicated PUSH,
POP, CALL, RETURN instructions that use a specific register. But in
practice, they are used in much the same way as a cpu with a dedicated
stack pointer (like x86). This is something the compiler implementer
must understand, but makes little difference to the user.
>
> Except small micro-computers and weird old hardware, most
> microprocessors have a hardware stack.
Agreed. But it is still an important exception, and it is the reason
that the C standards do not mention a stack.
>
> This allows to teach newcomers simple rules for developing software like:
>
> Automatic variables are in the stack and get freed automatically with
> just a machine instruction.
A good many automatic variables are /not/ on the stack - they are in
registers, or optimised away entirely. And how and when they get freed
is dependent on the implementation and the code in question.
Simplifications can be very useful for teaching - but it makes most
sense to stick to /accurate/ simplifications. "Automatic variables are
allocated when they are defined within the function, and deallocated at
the end of their scope". There is no need to mention a stack at all.
> All the temporary workspace we declare in
> local variables need not be freed after usage.
>
> Stack space is not unlimited however, and use with care. But with modern
> CPUs, this just doesn't matter.
Stack space is usually much more limited than dynamic storage ("heap"
storage - though again, the standards don't use that word). Depending
on the OS and the settings, the stack can be easily overrun by big local
arrays. Unlike dynamic storage, there is no standard way to determine
when there is space on the stack - it depends on the OS and possibly
compiler flags or extensions.
So I would be very wary of suggesting to a beginner that stack space
limitations do not matter - even when programming for PC's.
>
> All depends on the application and some applications are constrained by
> RAM usage, for instance, and stack variables are to be avoided. By
> following simple rules you can avoid them, or indicate the compiler how
> to avoid them. But that is the exception to the rule:
>
> Local variables are thread safe by design and allocation/deallocation is
> not needed.
Be careful there too - local variables are only thread safe when used
within the same thread. If you export them (by passing their address)
to code that runs from a different thread, you can quickly have a great
deal of trouble.
> They are used in a stack-like fashion, what is easy to
> conceptualize.
>
True - though often it is easy to conceptualise them without referring
to a stack at all. But I don't think it is unreasonable to talk about
"in a stack-like fashion" or a "logical stack".
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-03-20 13:24 +0000 |
| Message-ID | <aKQzA.95277$Bp6.2825@fx36.iad> |
| In reply to | #106520 |
BartC <bc@freeuk.com> writes: >On 19/03/2017 22:00, already5chosen@yahoo.com wrote: >> So, may be, Chad didn't use the clearest wording, but in principle he is correct. >> > >He mentioned a register-based stack, which doesn't really mean anything, >except suggesting the entire stack is contained within registers. > >That seems extraordinarily unlikely for a processor powering a smartphone. > I expect that Chad was referring to the calling sequence, in which the first N arguments are passed in registers rather than being pushed on the stack. x86_64 and aarch64 work the same way, as do most RISC architectures (sparc, 88100, et alia).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-19 13:21 +0100 |
| Message-ID | <oalsuq$c24$1@dont-email.me> |
| In reply to | #106397 |
On 17/03/17 23:57, jacobnavia wrote:
> Le 17/03/2017 à 22:00, Chad a écrit :
>> The one machine that I have uses a register based stack instead of a
>> regular stack. As a result, there is really no such thing as pushing
>> and popping numbers.
>>
>
> Most machines have up to 32 registers, maybe some have more.
Most processors have a great deal fewer than 32 registers. There are
common microcontrollers with only perhaps 3 registers, and one popular
one with a single register. I know of a microcontroller architecture
with no registers at all, in the normal sense of the word. Then there
are architectures with 64 or 128 registers, and architectures with
implementation-dependent register counts that are often view through
"windows".
There are also small microcontrollers with a "hardware return stack" -
no software data stack at all, and a fixed size stack for function call
return addresses. These stacks can be as small as 3 entries deep. And
yes, in some cases people program them in C - and while they are not
/large/ C programs, they are certainly /serious/ C programs.
>
> So, your register stack has place for 32 quantities, rather short for
> any serious problem or serious C software.
>
> Then, you will agree with me, there is a portion of memory that must be
> addressed in a stack like fashion each time you make a function call,
> for instance.
>
> Suppose this program:
>
> int fn1(int a)
> {
> return 25.87/3.14159 + a;
> }
>
>
> int main(void)
> {
> int a = 67;
> a += fn(1);
> printf("result=%d¡n",a);
> }
>
> When you enter the expression fn(1), and inside the fn function, a is
> assigned the value 1. The old value is pushed into the stack and is
> inaccessible until the called function pops the stack and returns into
> the main function with a result of the calculations done in the inner
> scope.
>
> This result is added to the old value of a that was popped when the
> function returned. We agree that within main the variable "a" has
> nothing to do with the value it had within "fn()".
This is a particularly bad example - since the main variable "a" has
nothing to do with the parameter to "fn1", there is no specific need to
preserve anything on a stack. But other examples could be constructed
that show the need to preserve data in some way.
C implementations which cannot store data in some logical stack system
(whether it be based on a stack pointer register, a linked-list of stack
frames, or some other mechanism) will be more limited - they will have
trouble with recursion or re-entrant functions, for example.
>
> Calling a procedure or function means pushing into a conceptual stack
> all the values held by the current scope, operation that is balanced by
> a pop when the function returns.
>
> By the way your machine with a dedicated register stack is caching the
> top of this stack into machine registers, but that doesn't change the
> conceptual form of the data processing structure you are using: a stack.
>
> And what is the name of your mysterious machine?
>
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2017-03-17 14:30 -0700 |
| Message-ID | <d3e8b241-cc5f-4434-be10-466630612e2c@googlegroups.com> |
| In reply to | #106383 |
On Friday, March 17, 2017 at 2:45:19 PM UTC-5, jacobnavia wrote: > Le 17/03/2017 à 20:15, John Bode a écrit : > > The real-world implementations I know of would try to place it on the > > runtime stack, but that's strictly a function of the implementation, not > > the language definition. All the language definition specifies is *when* > > and for how long memory is to be set aside for the object, not *where*. > > The language definition defines a logical stack of nested scopes. > > You enter a scope and push the old contents of the workspace to make > place for a new scope with new data. You do your calculations and exit > the scope with (or without) result. You pop the old context and you > continue. > > You can enter a scope and exit it in a stack-like manner. Now, it is > obvious since almost all CPUs have a machine stack, that the best thing > to do is to implement the C stack using the machine's stack pointer. > > Obviously. > > I never thought somebody would discuss such obvious facts. > > The C language does imply a stack, and most implementations use the > machine stack since it is built for doing exactly that: a stack. Which is basically what I said in my post: >> Having said that, the C language was developed on a system that used a >> runtime stack, and the rules for "auto" objects *strongly* encourage the >> use of a stack. Now, to address the points made by David and Jerry - there are systems out there that *don't* use a hardware stack to manage memory. How should implementations on those machines handle it?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-17 23:59 +0100 |
| Message-ID | <oahpju$904$2@dont-email.me> |
| In reply to | #106395 |
Le 17/03/2017 à 22:30, John Bode a écrit : > Now, to address the points made by David and Jerry - there are systems > out there that *don't* use a hardware stack to manage memory. How should > implementations on those machines handle it? > They have to store the information in a stack. You can do a stack using any simple software construct, its not a very complicated data structure anyway! But at the exit of a function call, the current scope must be destroyed, storage reclaimed and a return to the execution point just after the call must be done, popping the stack.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-17 21:02 -0400 |
| Message-ID | <oai0pk$1a9$1@jstuckle.eternal-september.org> |
| In reply to | #106395 |
On 3/17/2017 5:30 PM, John Bode wrote: > On Friday, March 17, 2017 at 2:45:19 PM UTC-5, jacobnavia wrote: >> Le 17/03/2017 à 20:15, John Bode a écrit : >>> The real-world implementations I know of would try to place it on the >>> runtime stack, but that's strictly a function of the implementation, not >>> the language definition. All the language definition specifies is *when* >>> and for how long memory is to be set aside for the object, not *where*. >> >> The language definition defines a logical stack of nested scopes. >> >> You enter a scope and push the old contents of the workspace to make >> place for a new scope with new data. You do your calculations and exit >> the scope with (or without) result. You pop the old context and you >> continue. >> >> You can enter a scope and exit it in a stack-like manner. Now, it is >> obvious since almost all CPUs have a machine stack, that the best thing >> to do is to implement the C stack using the machine's stack pointer. >> >> Obviously. >> >> I never thought somebody would discuss such obvious facts. >> >> The C language does imply a stack, and most implementations use the >> machine stack since it is built for doing exactly that: a stack. > > Which is basically what I said in my post: > >>> Having said that, the C language was developed on a system that used a >>> runtime stack, and the rules for "auto" objects *strongly* encourage the >>> use of a stack. > > Now, to address the points made by David and Jerry - there are systems > out there that *don't* use a hardware stack to manage memory. How should > implementations on those machines handle it? > IBM mainframes use a set of linked list of save areas. A new save area is allocated on each call and linked to the previous one. Each function determines the size of its save area. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-19 13:26 +0100 |
| Message-ID | <oalt84$ee2$1@dont-email.me> |
| In reply to | #106395 |
On 17/03/17 22:30, John Bode wrote: > Now, to address the points made by David and Jerry - there are systems > out there that *don't* use a hardware stack to manage memory. How should > implementations on those machines handle it? > On small systems which have no efficient "register + offset" addressing mode for stack data, it is common to use static addresses instead of a stack. Function local data and function parameters are allocated statically. The compiler can be smart about sharing these addresses between functions (since ram is usually at a premium on such devices). For re-entrant or recursive functions, the compiler has to work harder - in such cases, it may have to use a software stack to preserve data, or it may clone or duplicate functions.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web