Re: [Mspgcc-users] .data initialization not working
Hello, On Mon, 8 Dec 2014 08:42:28 -0600 Peter Bigot big...@acm.org wrote: Unfortunately this list doesn't support attachments. Perhaps somebody could put it on E2E and add a pointer. Or maybe RedHat even has version control system, maybe even with web interface? Interesting that TI proposed a solution that doesn't work for ROM resident applications, which are all but the most infinitesimal subset of the applications that use an MSP430. (It's so implausible I'm half convinced I don't understand exactly what's happened here.) Peter, can you please consider maintaining mspgcc for couple years more, while dear esteemed vendors sort out issue how to teleport application code out of thin air into RAM? Peter On Mon, Dec 8, 2014 at 8:36 AM, Nicholas Clifton ni...@redhat.com wrote: Hi Guys, I have attached a patch which will restore the old movedata functionality to the toolchain. Strange - the attachment disappeared. Here it is again. Cheers Nick -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- Best regards, Paul mailto:pmis...@gmail.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspg++ and c++ includes
Hello, On Mon, 10 Jun 2013 17:23:00 -0700 Thomas Taranowski t...@baringforge.com wrote: Thanks for the comment Paul. What are you using for your compiler flags? I'm having a couple issues with mine. I'm currently using the following: -ffunction-sections -fdata-sections -DGCC_MSP430 -Wall -fno-exceptions -fno-rtti -fno-enforce-eh-specs -nodefaultlibs Well, I'm using: msp430-g++ -I../include/ -mmcu=msp430g2553 -O1 -g -Wreturn-type -ffunction-sections -fdata-sections -DHW_CONFIG=\hw_config_msp430.hpp\ -fno-exceptions -c blink.cpp -o bin-msp430/blink.o msp430-gcc -mmcu=msp430g2553 -Wl,--gc-sections -Wl,-Map=bin-msp430/blink.map,--cref bin-msp430/blink.o -o bin-msp430/blink (I was shocked to see that Energia doesn't pass -fno-exceptions, but I myself don't pass -fno-rtti, that needs to be fixed). This works well in with -O2 specified (release build), but fails with memset undefined when running my -O0 debug build. Presumably the optimized version is using the built-in library. Also, I can't seem to get printf back in by adding -lgcc -lc.to the linker flags, as I think these get ignored after specifying the -nodefaultlibs argument. I really want something to just disable the libstdc++ include. Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com -- Best regards, Paul mailto:pmis...@gmail.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspg++ and c++ includes
Hello, On Mon, 10 Jun 2013 23:00:43 -0400 Peter Johansson rockets4k...@gmail.com wrote: On Mon, Jun 10, 2013 at 8:00 PM, Paul Sokolovsky pmis...@gmail.com wrote: C++ as a language works really well with mspgcc. C++ stdlib is different story. The vast majority of MSP430s are rather limited in capabilities and this is borne out in even in the C library. Outside of the micro-controller realm, many people use C++ (effectively) for the library support, and that is one thing you won't get for any small micro. These are tales from previous century. There were dispelled many times (e.g. http://stackoverflow.com/questions/812717/is-there-any-reason-to-use-c-instead-of-c-for-embedded-development), including by respectable organizations (http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf). Of course, that's party due to fact that when people hear C++, they picture 30-old C++ with objects which are by now a trivial thing, or or poor implementation of exceptions, or something. When speaking about C++, one rather should imagine Lisp with its macros and how they were twisted into templates which gave birth to modern C++ and is its central part. If you want to venture into the world of C++ for micros, you are going to be writing your own libraries. Yes, that's how it has been for now, example was given. I also gave an example that it changes and will be changing further (someone will drop -avr from that stlport port, because there's of course nothing in there which got to be AVR-specific in it). At least one person on this list has put the C++ capabilities of mspgcc to excellent use. Perhaps he might be persuaded to share... I humbly can propose my piece: https://github.com/pfalcon/PeripheralTemplateLibrary is a humbly named (template) lib with the aim of providing consistent programming interface (up to the level of writing portable apps) for all possible and impossible MCUs (8051 is in queue too, blocked by lack of open-source C++ compiler for it), without sacrificing performance (should be much better than any C lib with similar aims and not much worse than Asm). -p. -- Best regards, Paul mailto:pmis...@gmail.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspg++ and c++ includes
Hello,
On Mon, 10 Jun 2013 17:45:00 -0500
Peter Bigot big...@acm.org wrote:
C++ is not supported by mspgcc. Some people are using it to some
degree with some success, and may be able to provide hints about
improved compatibility, but no effort has been made to ensure it
functions.
C++ as a language works really well with mspgcc. Well, C++ is big and
multi-paradigm, the part which is good for embedded works well (that
includes compile-time meta-programming and excludes run-time
cycle-burning, like virtual functions).
Well, it sucks that things like:
=
struct Timer
{
const static int irq_no = 10;
};
interrupt(Timer::irq_no) irq_handler()
{
}
=
don't work, but I put up with that.
C++ stdlib is different story. I recently did a survey of MCU C++ libs
and found it funny that almost everyone (including me) had circular.hpp
or similar in their codebase. So, good-for-embedded things of STL (like,
well, template classes) are definitely a miss and people reinvent the
wheel. https://github.com/vancegroup/stlport-avr may be a good start to
get those.
It is to be hoped this will be addressed by Red Hat's version.
On Mon, Jun 10, 2013 at 5:34 PM, Thomas Taranowski
t...@baringforge.comwrote:
mspg++ seems to be functioning, but all the standard c++ includes
seen to be missing. For example, cstdio, cstdlib, etc. Am I
missing some part of the install, or is this work yet to be done?
-Tom
--
Best regards,
Paul mailto:pmis...@gmail.com
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] variable reusing
Hello, On Tue, 14 May 2013 23:31:03 +0530 kuldeep dhaka kuldeepdha...@gmail.com wrote: hello guys, while coding (embedded devices) i got an idea. [] in the above code, after sending uart_send(before) , before is no more useful to me. but for while loop i have to get a new variable i for iteration. in this case the compiler allocates the memory in stack. since in embedded system, everything is scare , reusing things come handy and efficient. but if i try to reuse before in loop as replacement of i , it looks odd + bad coding practise, right? but if their is something like __reuse__(before, i) ( like __attribute__() or sizeof() ) or uart_send_param(uint8_t before|i, uint8_t after, uint8_t default_value) after that i could use before as i. You don't need to do anything for this to work as you describe for *local variables* - compiler is supposed to do this for you (at relevant optimization levels, like -O2). Google for live range analysis for more info, http://en.wikipedia.org/wiki/Register_allocation and http://en.wikipedia.org/wiki/Live_variable_analysis are a good start. More interesting question is such support for static (if not global) variables. When trying to do Elliptic Curve Cryptography on MSP430 value line devices which top up at 0.5K RAM, you really wish that compiler could pack together static buffers of functions which cannot be active at the same time ;-). If anyone know of that to be done by gcc, would be nice to get some pointers. -- Best regards, Paul mailto:pmis...@gmail.com -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] variable reusing
Hello,
On Wed, 15 May 2013 09:35:14 +1200
Daniel Beer dlb...@gmail.com wrote:
On Tue, May 14, 2013 at 09:26:46PM +0300, Paul Sokolovsky wrote:
More interesting question is such support for static (if not global)
variables. When trying to do Elliptic Curve Cryptography on MSP430
value line devices which top up at 0.5K RAM, you really wish that
compiler could pack together static buffers of functions which
cannot be active at the same time ;-). If anyone know of that to be
done by gcc, would be nice to get some pointers.
If you have static buffers which are never in use simultaneously, why
not keep them together in a union { }?
Yes, the talk was about offloading the work of proving
non-simultaneous access constraints and creation of that union to the
compiler ;-). Shouldn't be hard for the case of scalar static variables
(function-local dataflow analysis and interprocedural control flow
analysis), so I wondered if someone knows it to be implemented. To be
really useful this should be applied to structural/array vars though,
and that's much harder.
- Daniel
--
Best regards,
Paul mailto:pmis...@gmail.com
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way
Hello, On Sun, 21 Apr 2013 20:15:45 -0400 Przemek Klosowski przemek.klosow...@gmail.com wrote: As you say, the reason for the undefined behaviour in the standard is because different ISA (instruction set architectures) behave differently. The underlying assumption here is that C is a 'bare metal' language, and implements high level operations that map well to the machine language facilities. As a result, you should not expect any commonality in behaviour between different ISA if there isn't commonality between their respective natural binary operations. If the overall fastest generated code for a standard-defined case is to mask out the shift count, it would be against the spirit of C to do anything else. I'm sorry if my original mail didn't make it too clear, but my whole report was regarding evaluation rules used during compile-time constant subexpression elimination. It's obvious that runtime behavior should be the most optimal, leaving corner cases to programmer. But what would be the most obvious behavior for compile-time? Feel free to argue that it's not the mathematical definition, but some obscure platform-dependent factors. This reminds me of the section of GCC manual that said something like 'because the behaviour in this case is undefined and left to the implementer, our choice is to launch a game of life'. Yep, then people started to rely on it, then someone compiled stuff for MSP430, saw no game of life launched, and reported the compiler as broken. Solution? http://en.wikipedia.org/wiki/Principle_of_least_astonishment [] -- Best regards, Paul mailto:pmis...@gmail.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way
Hello, On Mon, 22 Apr 2013 08:12:50 -0500 Peter Bigot big...@acm.org wrote: Changes to mspgcc are/were driven by tickets filed on the SF bug tracker. If you'd like this change made after reading the material below, please file a ticket there. mspgcc evolution/maintenance is not funded at this time and the issue is below the threshold that I consider critical enough to donate time, so the ticket will remain open until somebody takes over such maintenance. Submitted: https://sourceforge.net/p/mspgcc/bugs/351/ . I actually didn't want to spend too much time on this, or call for immediate actions, just point out that there're better choices for implementation-defined behavior as implemented mspgcc. I personally don't expect any immediate changes, the whole idea was to save novices or folks who may port big software from unneeded headache. For the record, I've reconstructed my reasoning from two years ago, which makes explicit the point Przemek made. It's not worth the research to prove it, but again this was justified by similar practices in other gcc back-ends, even if not x86. First, the value of a shift expression should be the same whether it is computed at compile time or at runtime. Well, it's the same thing - standard doesn't require this ;-). I understand benefit of consistency, but given the choices (both sanctioned by standard, as it simply underfines the case completely): 1. Make runtime compile-time be consistent. 2. Make compile-time be consistent with mathematical definition, and leave runtime to be optimal for particular h/w. - It hopefully easier to make a choice. If not, then good exercise may be to stop thinking about particular embedded CPU and all quirks which can be done in its realm, but think about a compiler in general, and that metaprogramming is important thing for producing optimal code (especially for embedded targets!), and metapgramming requires robust compile-time evaluation. I.e., 1 16 should produce the same value as 1 v when v has the value 16. Second, the base MSP430 ISA does not have a multi-position shift operation like x86 does. It can shift only one bit position at a time. Exactly, so masking out bits in shift counter wasn't even hardware-bound (I don't know much about MSP430X), but more or less arbitrary choice. Variable shifts must be translated into loops with the iteration count provided at runtime. (Second-prime: use of MSP430X which has a limited version of such instructions should also not result in a change of the value of the shift expression.) Oops, here you appear to want even more than I: I want just math-guided rules for builtin GCC calculator, you want to generate same-behaving code for different ISAs, at the potential expense of runtime-efficiency. Hmm... Third, it is unreasonable when v has the value 63532 to stall the processor for 65532 iterations of a loop calculating 1 v. Instead the runtime code should limit the iteration count. Since the maximum number of iterations before the expression value becomes a constant (i.e., the number of bits in the expression value) will always be a known power of two, masking the iteration count to preserve only the low bits from 0 to that number is the simplest solution. Whoa, so you generate non-optimal code for the slight possibility that someone shifts stuff 63532 times? That clearly goes against what Przemek wrote (and with what I wholly agree, as my suggestions are solely for compile-time behavior). If a programmer wants to shoot oneself in the feet, don't preclude one from doing that, just give a good gun which will shoot in the feet, not suddenly in the opposite direction ;-). This is the behavior mspgcc currently uses. To accommodate your request a test would have to be added at runtime to see whether the iteration count is equal to or greater than the number of bits in the expression value, and if so to substitute the constant (0 or ~0) that would have resulted from the shift operation. This introduces code bloat, as in the vast majority of cases people will not be using a shift count that is large enough to trigger the conditional. In my opinion increasing generated code size just to accommodate a practice that is explicitly undefined behavior is a poor use of resources and improperly encourages a misunderstanding of how C treats this situation. Having considered the arguments, no, the behavior will not be changed. So once again, I was talking about changing *only* compile-time time behavior, runtime doesn't need to change (except that, as a separate issue, I'd vote for removing any extra masking during runtime shifts - programmer either took care of that by masking count oneself, knows that it's invariantly in range, or well, wants to shift 60K times). Please note that the new back end under development by Red Hat may have different behavior. Peter On Sun, Apr 21, 2013 at 6:10 PM, Paul Sokolovsky pmis...@gmail.com wrote
Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way
Hello, On Mon, 22 Apr 2013 17:39:27 +0200 David Brown da...@westcontrol.com wrote: Hi, When I compile the code you gave below (using gcc 4.6.3 from 20120406), I get: warning: left shift count = width of type [enabled by default] That is even without any sort of warning flags - and you should normally enable lots of warnings. So here you have undefined code, and the compiler tells you of the problem. You really cannot get better than that by trying to invent your own ideas about how you want to define this undefined behaviour. Yeah, but can get better by leveraging generally accepted ideas (math def of shift) and ideas put by more than just you into similar cases (other well known gcc ports, like x86) ;-). Thanks for all the flame, guys! ;-). -- Best regards, Paul mailto:pmis...@gmail.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
[Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way
Hello,
It's a known fact that shifting by more or equal bits as an integer
type contains is undefined behavior per C standard,
http://stackoverflow.com/questions/7214263/unexpected-behavior-of-bitwise-shifting-using-gcc
has relevant quotes and references.
It's less known the rules of dealing with undefined values for
compiler writers, in this respect I find LLVM's description insightful:
http://llvm.org/docs/LangRef.html#undefined-values . Summing up, it
says that result of most of the expressions involving undefined value
is also undefined.
Finally, it's known why C standard has it like that: because rules
various CPUs use for such shifts at *runtime* vary, so *runtime* code
should not rely on them. C also doesn't define separation between
compile-time and run-time evaluation strictly, so for it any shift by
too many bits is undefined.
It's all nice and good. But there's difference between undefined,
any value and weird. Because too many bits shifts may be
undefined in C standard, but shifts by arbitrary number of bits are
very well defined in arithmetic - and by very definition of (unsigned)
shift, any value shifted by more bits than available in its
representation is 0. That's logical, that's what users know, that's
what they expect from compiler, and well, that's how x86-gcc behaves.
Now mspgcc:
int v = 5;
int main()
{
printf(%d\n, v + (1 16));
}
main:
mov r1, r4
add #2, r4
mov v, r15
add #1, r15
pushr15
push#.LC0
call#printf
add #4, r1
So, msp430-gcc just masks out higher bits of shift count, and in this
case leaves original value intact. Which turns term ((1 BITS) - 1),
which is common to do BITS-modular arithmetic, and would be expected to
just optimize out in case of a full type, into an expression killer with
infinite loops, etc. ensuing.
--
Best regards,
Paul mailto:pmis...@gmail.com
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] mspgcc undefines too-many-bits shifts in weird way
Hello, On Sun, 21 Apr 2013 17:06:51 -0500 Peter Bigot big...@acm.org wrote: This decision was intentional, as documented in https://sourceforge.net/p/mspgcc/bugs/118/. My recollection is that the choice of how to make things consistent was informed by similar behavior in the contemporaneous gcc for x86 or at least one other target architecture. Thanks for the reference. So, I tested it with x86 gcc 4.4, 4.5, 4.6, 4.7 (packages as shipped by Ubuntu), all of them produce mathematically expected result. msp430-gcc 4.5.3, 4.7.0 both produce unexpected result. As you say, the behavior is undefined. Anybody who expects any particular behavior for this situation is confused about how C works and should take the issue up with JTC1/SC22/WG14. That's why I wrote so many words in the original mail. Yes, in small world of JTC1/SC22/WG14 C standard the behavior is undefined. But in much bigger world of: mathematics, well-known gcc targets, user expectations, principle of least surprise, etc. - it's all pretty well defined. So, when something is undefined in small area, it's still a good idea to have affinity towards how it's done/expected in wider areas. So, the request is just that - please kindly consider changing that behavior ;-). Peter -- Best regards, Paul mailto:pmis...@gmail.com -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
