public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
* Instruction w/ prefix
@ 2009-10-07 17:02 Dmitry Eremin-Solenikov
  2009-10-15 23:10 ` Doug Evans
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Eremin-Solenikov @ 2009-10-07 17:02 UTC (permalink / raw)
  To: cgen

Hello,

I'm using cgen to create binutils port for the CISC architecture
(M68HC(S)08 if somebody cares). I've stumbled upon one problem: the is
an instruction prefix which can change meaning
of the next instruction (basically it then uses SP register instead of IX one).

What is the most clean way to do this w/ cgen? I can of course
duplicate instruction fields, counting another byte in the beginning,
instructions, etc.. This will permit me to catch illegal combinations.
OTOH it doesn' look like completely clean idea.

What would you suggest?

-- 
With best wishes
Dmitry

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Instruction w/ prefix
  2009-10-07 17:02 Instruction w/ prefix Dmitry Eremin-Solenikov
@ 2009-10-15 23:10 ` Doug Evans
  2009-10-19 13:29   ` Dmitry Eremin-Solenikov
  0 siblings, 1 reply; 4+ messages in thread
From: Doug Evans @ 2009-10-15 23:10 UTC (permalink / raw)
  To: Dmitry Eremin-Solenikov; +Cc: cgen

Dmitry Eremin-Solenikov wrote:
> Hello,
>
> I'm using cgen to create binutils port for the CISC architecture
> (M68HC(S)08 if somebody cares). I've stumbled upon one problem: the is
> an instruction prefix which can change meaning
> of the next instruction (basically it then uses SP register instead of IX one).
>
> What is the most clean way to do this w/ cgen? I can of course
> duplicate instruction fields, counting another byte in the beginning,
> instructions, etc.. This will permit me to catch illegal combinations.
> OTOH it doesn' look like completely clean idea.
>
> What would you suggest?
>
>   

Hi.  Sorry for the slow reply.

I think the right solution (which I wouldn't wait for) is to extend cgen 
to handle instruction prefixes.

In the meantime, I would treat the prefix as its own instruction.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Instruction w/ prefix
  2009-10-15 23:10 ` Doug Evans
@ 2009-10-19 13:29   ` Dmitry Eremin-Solenikov
  2009-10-19 17:27     ` Doug Evans
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Eremin-Solenikov @ 2009-10-19 13:29 UTC (permalink / raw)
  To: Doug Evans; +Cc: cgen

Hello,

Doug Evans wrote:
> Dmitry Eremin-Solenikov wrote:
>> Hello,
>>
>> I'm using cgen to create binutils port for the CISC architecture
>> (M68HC(S)08 if somebody cares). I've stumbled upon one problem: the is
>> an instruction prefix which can change meaning
>> of the next instruction (basically it then uses SP register instead of 
>> IX one).
>>
>> What is the most clean way to do this w/ cgen? I can of course
>> duplicate instruction fields, counting another byte in the beginning,
>> instructions, etc.. This will permit me to catch illegal combinations.
>> OTOH it doesn' look like completely clean idea.
>>
>> What would you suggest?
>>
>>   
> 
> Hi.  Sorry for the slow reply.
> 
> I think the right solution (which I wouldn't wait for) is to extend cgen 
> to handle instruction prefixes.

Do you have any ideas how to implement (or at least design) this?

As for me, the prefix just changes the addressing (prefixed instruction
just uses SP as a base instead of IX register).

> In the meantime, I would treat the prefix as its own instruction.

Yep, I've tried this approach. However I've stumbled upon the fact that
cgen just sums all specified values, thus leading me into problems.

I'm currently looking into how to overcome this. Maybe you can suggest a 
  sample which I can look upon?

-- 
With best wishes
Dmitry

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Instruction w/ prefix
  2009-10-19 13:29   ` Dmitry Eremin-Solenikov
@ 2009-10-19 17:27     ` Doug Evans
  0 siblings, 0 replies; 4+ messages in thread
From: Doug Evans @ 2009-10-19 17:27 UTC (permalink / raw)
  To: Dmitry Eremin-Solenikov; +Cc: cgen

Dmitry Eremin-Solenikov wrote:
> Hello,
>
> Doug Evans wrote:
>> Dmitry Eremin-Solenikov wrote:
>>> Hello,
>>>
>>> I'm using cgen to create binutils port for the CISC architecture
>>> (M68HC(S)08 if somebody cares). I've stumbled upon one problem: the is
>>> an instruction prefix which can change meaning
>>> of the next instruction (basically it then uses SP register instead 
>>> of IX one).
>>>
>>> What is the most clean way to do this w/ cgen? I can of course
>>> duplicate instruction fields, counting another byte in the beginning,
>>> instructions, etc.. This will permit me to catch illegal combinations.
>>> OTOH it doesn' look like completely clean idea.
>>>
>>> What would you suggest?
>>>
>>>   
>>
>> Hi.  Sorry for the slow reply.
>>
>> I think the right solution (which I wouldn't wait for) is to extend 
>> cgen to handle instruction prefixes.
>
> Do you have any ideas how to implement (or at least design) this?
>
> As for me, the prefix just changes the addressing (prefixed instruction
> just uses SP as a base instead of IX register).

My current thinking is that they wouldn't be that different from 
individual instructions, except that they'd have a flag (attribute?) 
that says "I'm a prefix", and instructions that take prefixes would 
specify which prefixes are valid, and semantics would have some way of 
querying/specifying what prefixes are present/required.
[There's more details like whether multiple prefixes are valid, if 
there's a required order of prefixes (I guess), but that's the high 
order bit, I think.]

>
>> In the meantime, I would treat the prefix as its own instruction.
>
> Yep, I've tried this approach. However I've stumbled upon the fact that
> cgen just sums all specified values, thus leading me into problems.
>
> I'm currently looking into how to overcome this. Maybe you can suggest 
> a  sample which I can look upon?
>

Can you elaborate on "just sums all specified values"?  If all the 
prefixes are their own instructions, what values are summed up?

P.S. If one needed a simulator here, I'd create a register, named say 
h-use-sp-for-base or some such, that specified whether the "use-sp-base 
prefix" was present, reset it at appropriate times, have the use-sp-base 
prefix set it, and query the register in appropriate locations.  Then 
you could either choose between SP and IX in every instruction that 
needs it by querying h-use-sp-base, or you could create a virtual 
register that returns one of SP or IX depending on the value of 
h-use-sp.  I haven't tried it, but I think that would work.  [If it 
doesn't, I think it *should* work so let's fix it if it doesn't.]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-10-19 17:27 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-07 17:02 Instruction w/ prefix Dmitry Eremin-Solenikov
2009-10-15 23:10 ` Doug Evans
2009-10-19 13:29   ` Dmitry Eremin-Solenikov
2009-10-19 17:27     ` Doug Evans

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).