> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
>> The easiest way is to do this in the linker instead of the compiler.
>> See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
>> has the distinct advantage that
Marek Michalkiewicz <[EMAIL PROTECTED]> writes:
> On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
>
> > The easiest way is to do this in the linker instead of the compiler.
> > See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
> > has the distinct advantage th
On Sun, Mar 20, 2005 at 04:29:01PM -0800, Richard Henderson wrote:
> The easiest way is to do this in the linker instead of the compiler.
> See the xstormy16 port and how it handles R_XSTORMY16_FPTR16. This
> has the distinct advantage that you do not commit to the creation of
> an indirect jump
On Mon, Mar 21, 2005 at 01:12:40AM +0100, Marek Michalkiewicz wrote:
> On the other hand, branches within the same function should avoid the
> extra jump and go to "1:" directly. If the same label is used in both
> ways (direct jump/branch, and address taken), two separate labels (at
> the same ad
On Sun, Mar 20, 2005 at 02:58:29AM +0100, Giovanni Bajo wrote:
> It is possible in GNU C at least:
>
> int foo(int dest)
> {
>__label__ l1, l2, l3;
>void *lb[] = { &&l1, &&l2, &&l3 };
>int x = 0;
>
>goto *lb[dest];
>
> l1:
>x += 1;
> l2:
>x += 1;
> l3:
>x += 1;
>
> From: Paul Brook <[EMAIL PROTECTED]>
> Don't we know which labels are targets of indirect jumps?
> So the proposed restriction now becomes: functions *and targets of indirect
> jumps* must be aligned to an N word boundary. I'd guess that the latter are
> sufficiently rare that this is still an ac
> From: Giovanni Bajo <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> wrote:
>> - Sorry, I'm confused; can you give me an example of legal C
>> expression specifying an indirect jump to an arbitrary location
>> within a function?
> It is possible in GNU C at least:
- thanks, obviously w
On Sunday 20 March 2005 01:58, Giovanni Bajo wrote:
> Paul Schlie <[EMAIL PROTECTED]> wrote:
> > - Sorry, I'm confused; can you give me an example of legal C
> > expression specifying an indirect jump to an arbitrary location
> > within a function?
>
> It is possible in GNU C at least:
>
> int fo
Paul Schlie <[EMAIL PROTECTED]> wrote:
> - Sorry, I'm confused; can you give me an example of legal C
> expression specifying an indirect jump to an arbitrary location
> within a function?
It is possible in GNU C at least:
int foo(int dest)
{
__label__ l1, l2, l3;
void *lb[] = { &&l1, &
On Sat, Mar 19, 2005 at 06:37:54PM -0500, Paul Schlie wrote:
> - or possibly GCC may try to be clever by jumping to no-return attribute
> function calls?
Such "trying to be clever" would most likely be optional.
Again, why is indirect_jump _mandatory_ on all machines?
Please, don't try to be t
> From: Paul Schlie <[EMAIL PROTECTED]>
>> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> Good question - I can't. On the other hand, the manual says:
>>
>> `indirect_jump'
>> An instruction to jump to an address which is operand zero. *This pattern
>> name is mandatory on all machines.*
>>
>
> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
> Good question - I can't. On the other hand, the manual says:
>
> `indirect_jump'
> An instruction to jump to an address which is operand zero. *This pattern
> name is mandatory on all machines.*
>
> Why would it be mandatory if it was not truly
On Sat, Mar 19, 2005 at 04:38:28PM -0500, Paul Schlie wrote:
> - understood, however unlikely; observing it will likely take Atmel at
> least 2-3 years to stabilize production of the 256K devices, and larger
> device volume potential vs. competitive offerings couldn't likely justify
> their
> From: Marek Michalkiewicz <[EMAIL PROTECTED]>
>> - Fully agree, just can't keep from wondering if this may be most
>> efficiency accomplish by simply requiring the alignment of all
>> function entry points to be two instruction word aligned. Thereby
>
> This only doubles the available addres
On Sat, Mar 19, 2005 at 01:51:05PM -0500, Paul Schlie wrote:
> - Fully agree, just can't keep from wondering if this may be most
> efficiency accomplish by simply requiring the alignment of all
> function entry points to be two instruction word aligned. Thereby
This only doubles the available
> From: Paul Schlie <[EMAIL PROTECTED]>
>> Marek Michalkiewicz wrote:
>> I'm looking into adding support for ATmega256x and larger devices to
>> the AVR port. This means that program memory addresses no longer fit
>> in 16 bits - and I'm looking how to avoid making pointers larger.
>
> - Fully ag
> Marek Michalkiewicz wrote:
> I'm looking into adding support for ATmega256x and larger devices to
> the AVR port. This means that program memory addresses no longer fit
> in 16 bits - and I'm looking how to avoid making pointers larger.
- Fully agree, just can't keep from wondering if this may
Hello,
I'm looking into adding support for ATmega256x and larger devices to
the AVR port. This means that program memory addresses no longer fit
in 16 bits - and I'm looking how to avoid making pointers larger.
Jumps and function calls are no problem as long as they use labels
(constant addresse
18 matches
Mail list logo
