On Thu, Oct 6, 2011 at 2:03 AM, David Brown <da...@westcontrol.com> wrote:
> On 05/10/2011 18:05, JMGross wrote:
> >
> >
> >
> >
> > ----- Ursprüngliche Nachricht -----
> > Von: David Brown
> > Gesendet am: 04 Okt 2011 16:22:18
> >
> >> On 04/10/2011 15:59, Peter Bigot wrote:
> >
> >>> The words "stack" and "heap" do not appear in the C standard. There
> >>> is only static and automatic storage duration.[...]
> >>> JM's answer is relevant for somebody who could encounter more unusual
> >>> architectures.
> >
> >> However, the original question was from someone who knew very little
> >> about how memory is organised in C - I don't think it helps to talk
> >> about how it works on a poor-quality pseudo-C compiler for a very
> >> limited processor. Almost all C compilers, including mspgcc, organise
> >> their memory in the same way, so I think it is fair to consider that the
> >> "generic" answer and leave it there.
> >
> > Surely, the most usual answer is what usually answers most.
> > However, I don't appreciate the approach to tell only the necessary and
> leave
> > people under the impression that this is the oen and only thruth (unless
> it
> > really is).
> > So giving an (apparently) authoritative answer that only fits for 99%,
> will bring
> > these people in trouble if they encounter the remaining 1%.
> >
>
> I can appreciate that, and I generally like to give complete answers
> myself (or at least mention that the answer given is incomplete). My
> point was not that the stack, heap and registers are the only way to
> organise memory in C - merely that the stack, heap and registers is a
> perfectly good, valid generic answer. Any other implementation is a
> rarity, usually due to limitations of the underlying hardware. It's
> just a difference of emphasis, really.
>
I originally answered the question with the generic response with a nod to
their being other possible implementations. JM responded with a question
about my experience with the rather primative PIC. And off to the races we
went.
>
> > Just like the idea that you need to have sex to get pregnant. Correct for
> the very
> > most occurrences but not for all. And not knowing that there are
> exceptions to
> > the rule makes you more prone to be avictim of these exceptions.
> >
>
> Perhaps I don't get out of the office enough, but I can't think how one
> could get accidentally pregnant without sex!
>
I beleive this a nod to the religious concept of immaculent conception.
>
> This makes it a close analogy - if you "do the usual thing" with C
> programming, using proper processors with proper C compilers, then the
> generic answer is perfectly sufficient. You will only meet exceptions
> to the stack, heap, registers arrangement if you go out of your way to
> use outdated microcontrollers with expensive non-standard tools and
> choose to delve into the technical details of them.
>
Perhaps. But it certainly is something that dealing with a different
architecture requires looking at. I started out wanting to do computer
architecture and actually played with it quite a bit as I used to turn new
machines on. I then went off and did routers.
>
> >> On re-reading what I wrote, the tone of my reply was perhaps a bit
> >> crass, however - and for that I apologise.
> >
> > I didn't take it as offense.
> >
> > As for the PIC: I don't like it, never liked it and I'm happy that I
> never had to do
> > a project with it. All I had to do (and that was enough) was some
> bugfixing on
> > existing projects and migrating two PIC projects to the MSP430F1232.
> > That was enough for my lifetime.
> >
>
> I've only programmed them in assembly. It was fun, in a perverse sort
> of way.
>
Definitely perverse. I used to write micro-code (the stuff below
assembly), but then again I used to design 180 bit wide horizontal custom
processors too.
Talk about perverse.
>
> > Anyway, it makes no difference whether PIC means "programmable interrupt
> controller" or
> > "peripheral interface controller". It is programmable and of peripheral
> usesfulness only.
> > It has one interrupt and has one interface (at least the earlier series).
> > And it is no processor at all.
>
Depends on the definition of processor.
> >
> > However, looking at acronym finder
> > http://www.acronymfinder.com/Information-Technology/PIC.html
> > the programmable interrupt controller comes out first, the peripheral
> interface controller
> > is only third place :)
> > But you're right, the Microchip acronym officially means the second. Yet
> the first definition
> > is much older and I'm pretty sure it was the source when Microchip picked
> their name.
> >
>
> Well, "Programmable Interrupt Controller" is a particular type of
> peripheral device - either as a standalone chip (especially the 8259A
> from PC's) or as an integrated peripheral within a microcontroller. The
> Microchip PIC is totally different, and was not named after these
> devices - the chips had nothing to do with interrupts. The PIC name
> used by Microchip was an abbreviation for "Peripheral Interface
> Controller", because that's what the architecture was first used for.
>
> Not that it really matters much, except to pendants like me...
>
oh and me and me and me. me too!
:-)
And now back to our regularily scheduled program... :-)
something of a weird mood tonight.
>
> mvh.,
>
> David
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
