public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: Doug Evans <dje@sebabeach.org>
To: Dave Korn <dave.korn.cygwin@googlemail.com>
Cc: cgen@sources.redhat.com
Subject: Re: unable to find precise mode to match cpu word-bitsize 24
Date: Tue, 14 Jul 2009 05:59:00 -0000	[thread overview]
Message-ID: <4A5C1EA4.8070005@sebabeach.org> (raw)
In-Reply-To: <4A4FEA13.1090104@gmail.com>

Dave Korn wrote:
> Doug Evans wrote:
>   
>> Dave Korn wrote:
>>     
>>> Doug Evans wrote:
>>>
>>>  
>>>       
>>>> This is new ground so we can decide how we want things to look, and then
>>>> make it work.
>>>>     
>>>>         
>>>   Well, what I'd particularly like in this case would be for my pc to
>>> increment by one for each 24-bit insn, rather than have the model
>>> pretend to
>>> be an 8-bit CISC machine processing all 3-byte instructions, if you
>>> see what I
>>> mean.
>>>   
>>>       
>> Righto.  That should be doable regardless.
>>     
>
>   I hope so.  Should I just take the blunt sledgehammer approach, and define
> setters and getters for hardware units h-addr and h-iaddr that multiply/divide
> by 3 on the fly, and let the underlying framework pretend it's a CISC machine
> that uses 3-byte operands and data?  Or is there a cleaner way to go?
>
>   

Sorry for the slow reply.

Regarding "and let the underlying framework pretend ...", I think it 
depends on the framework.  If you want to run a simulator on linux, say, 
what would you *want* it to look like?

I think it should be possible to define things as you want in the 
description file, and then have the app source generators deal with the 
mapping from the architecture description to the app's implementation of 
that description.  We'll probably need to extend the opcodes and 
simulator generators, but if it's the right thing to do, let's do it.

IOW I'm not sure I'd add hardware setters/getters to do the mapping.  
Instead I'd like to see if the appropriate information could be passed 
to the simulator generator and it would generate its own getters/setters 
(or just make calls to something that is then provided by the underlying 
framework).

      reply	other threads:[~2009-07-14  5:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-21 19:02 Dave Korn
2009-06-21 23:07 ` Doug Evans
2009-06-22  0:05   ` Dave Korn
2009-06-22 17:05     ` Doug Evans
2009-07-04 23:35       ` Dave Korn
2009-07-14  5:59         ` Doug Evans [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A5C1EA4.8070005@sebabeach.org \
    --to=dje@sebabeach.org \
    --cc=cgen@sources.redhat.com \
    --cc=dave.korn.cygwin@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).