<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>confused by the ropi specification</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/39995/confused-by-the-ropi-specification</link><description> 
 
 www.keil.com/.../armccref_chdcdggg.htm 

 
It says, &amp;quot;The use of --apcs=/ropi is not supported when compiling
C++. You can compile only the C subset of C++ with /ropi.&amp;quot; 

 
What dose it mean by &amp;quot;the C subset of C++&amp;quot; ? 
Which part of c++ is not supported</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/158133?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 07:30:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:15585bd4-de56-468b-b1ec-4518610d274b</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;the number of problems to handle tends to add up, making some
projects cost much more than the expected gain&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
How do you compare the effort (cost) of building the
aforementioned system with the gain of satisfying somebody&amp;#39;s
curiosity?&lt;br /&gt;
I think labour cost is a factor here. Once the OP starts making good
money as an engineer (and I do hope he does), he&amp;#39;ll be more careful
with his time :-)&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/158094?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 05:19:34 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ce4466b4-adc0-424e-b43c-aaa520a5e88a</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;Luckily, technical English appears to be the easier subset of the
language :-)&amp;quot;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m pretty sure there are a huge number of native english speakers
who do not agree on that :)&lt;/p&gt;

&lt;p&gt;
Anyway - consider the PC.&lt;/p&gt;

&lt;p&gt;
MS-DOS didn&amp;#39;t have multitasking.&lt;/p&gt;

&lt;p&gt;
Windows have multitasking. But the applications do not own
interrupt handlers - they are owned by the operating system as shared
resources for the applications to alocate and use. It gets
interesting when you have two completely different embedded
applications that wants to interface with the hardware and install
interrupt handlers. There is only one interrupt controller.&lt;/p&gt;

&lt;p&gt;
Multitasking two embedded applications is harder than multitasking
two desktop applications.&lt;/p&gt;

&lt;p&gt;
Another thing here is that if you relocate an application, you can
have it running at a different address. But how will you know what
RAM memory ranges it needs? Because the second application must not
use the same RAM regions. Having relocation entries for all RAM
accesses isn&amp;#39;t enough to be able to also know how much RAM that is
used. Next thing is that the ARM instruction set often don&amp;#39;t allow
arbitrary accesses unless all accesses are made relative to an index
pointer. In many situations, registers are loaded with constants of
limited width with an optional shift. And same with memory accesses -
offsets or absolute addresses are compressed to a limited width with
an optional shift. So you can&amp;#39;t get away with a relocation table that
updates 32-bit memory values with an extra offset. So you may need to
have the compiler produce accesses relative to a common pointer.&lt;/p&gt;

&lt;p&gt;
In short - the number of problems to handle tends to add up,
making some projects cost much more than the expected gain. Settling
for just two applications at a time, and linking every application
twice - one &amp;quot;low&amp;quot; and one &amp;quot;high&amp;quot; link - is a way easier way of
writing code that can load two-of-n applications and then have them
multitask concurrently.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/158050?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 04:39:02 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:65854c65-69ed-4aa0-80de-15bdccae8954</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I&amp;#39;m not good at searching for these, because English is not my
first language and I&amp;#39;m not quite used to read english web
page.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It takes time. I&amp;#39;m not a native English speaker either. But you
better get used to reading lots of (technical) English if you are
goiing to persue a career in electronics and/or programming. Luckily,
technical English appears to be the easier subset of the language
:-)&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/157982?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 03:08:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bdd083a4-8cb7-4619-9beb-2f576ad8a093</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
Per Westermark&lt;br /&gt;
----------------------------------------------&lt;br /&gt;
&lt;i&gt;how about finally post some specific reasons why you feel a need
for your loader to decide the actual load address
dynamically?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
There&amp;#39;s no actual need in fact. I&amp;#39;m still at college. Programming
entertains me somehow. I just want to implement an simple flexible
multitasking system. It does not have to be powerful, though, I want
it to behave a little bit like a PC&amp;#39;s os. So then I could be familiar
with a simple system.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;And how are you going to manage to get two concurrently loaded
applications to share processor time?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The code for passing control is very simple (I&amp;#39;m not talking about
scheduling algorithm). In the systick timer handler function, you can
push the registers into stack, (call a scheduling algorithm function
to get next task&amp;#39;s sp) and change the sp to point to another task&amp;#39;s
stack, pop the protected variables into register, and then finally
the inturrupt handler returns. (for CM3, the return address is push
into the stack by hardware when an Inturrupt occurs, and the address
is reloaded to PC register when the hanler returns). As for The
scheduling algorithm, I haven&amp;#39;t implemented it yet. The Round-Robin
scheduling may be used for first implementation.&lt;/p&gt;

&lt;p&gt;
.&lt;br /&gt;
.&lt;/p&gt;

&lt;p&gt;
Mike Kleshov&lt;br /&gt;
----------------------------------------------&lt;/p&gt;

&lt;p&gt;
Thanks for the information you provide. I&amp;#39;m not good at searching
for these, because English is not my first language and I&amp;#39;m not quite
used to read english web page.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;So far my impression is that he wants to familiarize himself
with some cool new technology in his spare time.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It&amp;#39;s not some cool new technology. Actually I think I&amp;#39;m just
trying to &amp;quot;re-inventing the wheel&amp;quot;. Things about operating system
always interest me. Knowing about it is not enough for my curiosity.
So why not do it myself when I have time. I think I may not have as
much time as now after graduation and getting a job.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/154314?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 01:49:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0a291180-0d85-449e-b804-b1384d914ca6</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;So - how about finally post some specific reasons why you feel
a need for your loader to decide the actual load address
dynamically.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;d like to know that too. So far my impression is that he wants
to familiarize himself with some cool new technology in his spare
time. Although I do think that he could pick a technology that would
be more beneficial in terms of employment prospects.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/153740?ContentTypeID=1</link><pubDate>Wed, 12 Dec 2012 01:29:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6369b8b-469b-42d7-89ba-e3fe3a6f0d4d</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
You continue to talk about &amp;quot;load apps dynamically&amp;quot;.&lt;/p&gt;

&lt;p&gt;
You can load apps dynamically without any extra work. You don&amp;#39;t
need relocation tables to load apps dynamically. The relocation is
only needed if the load address is decided dynamically.&lt;/p&gt;

&lt;p&gt;
A normal boot loader loads apps dynamically. Just that the apps
loaded are normally already linked for running at the load address
the boot loader places them at.&lt;/p&gt;

&lt;p&gt;
The question is - why do you need to load apps at a dynamically
selected load address? And how are you going to manage to get two
concurrently loaded applications to share processor time? If they
can&amp;#39;t - what specific advantage do you then see of having another app
loaded, that isn&amp;#39;t allowed to run?&lt;/p&gt;

&lt;p&gt;
Linux systems have totally different needs since you can _never_
get away with linking an application for a fixed address - it all
depends on what other things you already have loaded in memory. That
totally beside the fact that a &amp;quot;normal&amp;quot; Linux system uses a processor
with a MMU making the applications memory accesses to be mapped from
logical address space to physical address space.&lt;/p&gt;

&lt;p&gt;
So - how about finally post some specific reasons why you feel a
need for your loader to decide the actual load address
dynamically.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/153734?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 21:43:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a30b0476-1f2b-4f0f-a58d-739c97dec105</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I kept reading the ELF specification and drawing the structures
for it for about three hours&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It appears you are not the only one:&lt;/p&gt;

&lt;p&gt;

&lt;a href="http://stackoverflow.com/questions/1784495/linux-user-space-elf-loader"&gt;stackoverflow.com/.../linux-user-space-elf-loader&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
If you cannot find existing code that does most of the work, why
don&amp;#39;t you take a library for reading ELF, parse a simple executable
and implement relocations that you encounter one at a time. I think
it is reasonable to expect that Cortex-M3 executables will only use a
smaller subset of the full spec.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/153052?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 19:26:14 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:613fc219-c9a1-4bb8-8450-94c6a88bd1f2</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;then you can directly let the linker produce the image for use
at that address.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
One of my friend has done this before. It is simple and easy to
understand. I think that a framework that is able to load apps
dynamicly will be more generic and flexible.&lt;/p&gt;

&lt;p&gt;
It does need some dirty work, however. I kept reading the ELF
specification and drawing the structures for it for about three hours
... I&amp;#39;ve known how to load the image, but the relocation issues is
still not yet clear for me :-( I still don&amp;#39;t quite understand how
those tables reference to each other ...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/152294?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 11:36:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:50984821-1fcc-422c-9625-29914fe9badd</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
But are you really sure you need to generate relocateable
images?&lt;/p&gt;

&lt;p&gt;
Are you really going to load multiple images at the same time?&lt;/p&gt;

&lt;p&gt;
If you never load more than one image, then you can directly let
the linker produce the image for use at that address. So it suddenly
becomes trivial to read in the image and run it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/147856?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 05:47:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e55789db-310a-4e19-a69c-d9e391cd5d8c</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;you are exploring your options regarding dynamically loaded
apps?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Yes.&lt;/p&gt;

&lt;p&gt;
And Thanks for your help.&lt;/p&gt;

&lt;p&gt;
Now I prefer to generate relocatable images.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/146965?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 05:21:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:085f9da1-835f-46c0-aac0-d8bf9fa9ee49</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
Correct me if I&amp;#39;m wrong: you are exploring your options regarding
dynamically loaded apps? And you have not decided yet on the complete
list of features you&amp;#39;d like to see in your system?&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;But I don&amp;#39;t quite understand the advantages and disadvantages
of position-independent code and relocatable image.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I can see at least two advantages of a relocatable image:&lt;br /&gt;
- You will not be limited by a subset of C++, as with ROPI.&lt;br /&gt;
- The code should be smaller/faster than position-independent code
(PIC).&lt;br /&gt;
The disadvantage is that you have to create a loader that will
interpret the relocation table and fill in the correct addresses in
the code. This could be problematic if the code is being loaded into
flash memory.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/145457?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 04:54:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7c538cbd-3a53-4ffb-98bc-1221eb8aea0d</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
So se the --reloc may be a better choice.&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://www.keil.com/support/man/docs/armlinkref/armlinkref_chdjggbe.htm"&gt;
&lt;a href="http://www.keil.com/support/man/docs/armlinkref/armlinkref_chdjggbe.htm"&gt;www.keil.com/.../armlinkref_chdjggbe.htm&lt;/a&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
But I don&amp;#39;t quite understand the advantages and disadvantages of
position-independent code and relocatable image.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/143332?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 04:44:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:040bdc22-8f73-404e-8445-b6cc62cfa38e</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks you for you explanations.&lt;br /&gt;
I don&amp;#39;t think I will actually need it. Spending spare time studying
these issues is just a hobby for me.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/140463?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 04:08:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9079bd12-1272-4267-b229-72dbe18b0f4e</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Position-independent code, or code with relocation table, is only
needed if you want to be able to load multiple applications
concurrently. But that obviously requires that the applications
either have a callback to allow you to constantly switch between them
(and they also need to share the available RAM) or that you implement
a preemptive task-switching operating system.&lt;/p&gt;

&lt;p&gt;
The multi-tasking part is very hard.&lt;/p&gt;

&lt;p&gt;
If all you want is to load and run a single application at a time,
then you can link all your apps for a fixed memory map. So you either
load app 1 into that fixed memory region and run. Or you load app 2
into same region and run. Then there are no need for
position-independant code. And no need for any relocation table to
relocate the code while loading it into memory.&lt;/p&gt;

&lt;p&gt;
A MS-DOS application only have relocation table (exe files)
because it isn&amp;#39;t known beforehand what OS version that is used, and
the number of drivers and memory-resident applications that are
loaded beforehand. If MS-DOS had reserved a fixed amount of memory
for OS and drivers, then it would not have had a need for any
relocation table.&lt;/p&gt;

&lt;p&gt;
Always make sure that you totally bracket exactly what your needs
are, so you don&amp;#39;t spend time trying to solve a more complex problem
without actually needing it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/131165?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 03:37:10 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6864633-6e56-4ef6-abf0-f0edd3afe730</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
sorry for that. I mean &amp;quot;run app&lt;b&gt;s&lt;/b&gt; dynamiclly, like our PC&amp;#39;s
os, although it will not be as powerful.&lt;br /&gt;
&amp;quot;how the loader will operate&amp;quot; is still an issue to be solved for
me.&lt;br /&gt;
I may load it into internal RAM for simple implementation, and I
prefer using external RAM if it would be OK.&lt;br /&gt;
A systick handler can be used for passing control. I implemented the
code for passing control using a poor scheduling algorithm days ago.
I&amp;#39;m trying to work out a decent scheduling algorithm these days.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/127921?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 03:12:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5c2e3b39-1317-40e0-b5cc-0a2000052ba8</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I want a system that is able to run app dynamicly.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
But what does &amp;quot;dynamically&amp;quot; mean exactly? Please describe how the
loader will operate, what regions of memory it will use, how it will
pass control to the app, will there be two apps running concurrently
and so on.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/117115?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 03:05:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b8cffeb7-6bce-4cbf-bba1-3f7721b5a2f3</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, I want a system that is able to run app dynamicly. It&amp;#39;s not
for product. Just a hobby.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/106675?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 02:55:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:37743f50-5e3c-4f70-803f-95a20b1d6b1c</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
Are you sure you need position-independent code? Loadable app does
not necessarily imply PIC: you could have a fixed memory map for
it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/117116?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 02:51:07 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c7ccdab0-8660-4173-b0f0-a868965a67b1</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks for your reply, and recommending.&lt;br /&gt;
I have poor knowledge about these low-level stuff.&lt;br /&gt;
Thanks.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/106672?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 02:44:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:39daa208-1948-41c6-830e-b6d5d268e8a2</guid><dc:creator>Mike Kleshov</dc:creator><description>&lt;p&gt;&lt;p&gt;
I think it will be easier for you to try to compile code snippets
with different C++ features to test which ones are supported.&lt;br /&gt;
By the way, isn&amp;#39;t there a way to produce relocatable ELF images? You
could load them at run time and dynamically resolve all
references.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/80821?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 01:12:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:58537b30-e345-4789-a82e-53b86ee7a0bc</guid><dc:creator>Pony279 Pony279</dc:creator><description>&lt;p&gt;&lt;p&gt;
I know that those &amp;quot;common to both C and C++&amp;quot; will be
supported.&lt;/p&gt;

&lt;p&gt;
Some C++ features, calling a non-virtual member function for
example, is very easy to implement, so I expect that it should be
supported.&lt;/p&gt;

&lt;p&gt;
I wonder how virtual function would be supported? or I should use
the the &amp;quot;--apcs=/fpic&amp;quot; ?&lt;/p&gt;

&lt;p&gt;
I plan to build a system based on Cortex-M3 MCU which is able to
load app from sdcard. I use C++ most of the time , so the
restrictions on C++ must be clear first. It would be wierd that a
low-level system is implemented in c++ but its high-level app must be
implemented in C.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: confused by the ropi specification</title><link>https://community.arm.com/thread/67929?ContentTypeID=1</link><pubDate>Tue, 11 Dec 2012 00:52:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7af93a78-74c1-4414-9095-2a31f823a12a</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Do you understand what &amp;quot;Subset&amp;quot; means?&lt;/p&gt;

&lt;p&gt;
It is the set of things that are common to both C and C++&lt;/p&gt;

&lt;p&gt;
So:&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;Which part of c++ is not supported?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Any part which is not identical in &amp;#39;C&amp;#39;!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>