* adjusting cgen @ 2002-06-11 19:09 Johan Rydberg 2002-06-12 8:13 ` Frank Ch. Eigler 0 siblings, 1 reply; 3+ messages in thread From: Johan Rydberg @ 2002-06-11 19:09 UTC (permalink / raw) To: cgen Hi! I'm hacking my way through the CGEN sources to adopt them to generate targets to a simulator I'm working on. What I have done is to clone the SID-part of CGEN and adjust it to generate code that suits my simulator. I better let you know that I know neither Scheme or Lisp. And I have some questions; 1) Is it possible to adjust CGEN to recognize on-page branches? This could be a huge optimization for me, since this will eliminate the full tlb+mmu lookup for (near) branches. 2) Is it possible to adjust the -gen-argbuf-elm fn in sid-decode.scm to generate bit fields instead of full integers? Currently it generates code similar to this; struct { /* */ UINT f_rd; UINT f_sr; } sfmt_mfsr; What I would like to do is to reduce the size of the sem_fields union to a total of 32-bits (for a 32-bit architecture). I guess this is best done by emitting bit fields, like; struct { /* */ UINT f_rd : 8; UINT f_sr : 8; } sfmt_mfsr; The bit field size should be the length of the ifield, rounded up to the next multiple of eight, but only for fields longer than 3 bits. (I assume that fields longer than 3 bits is normally either used as indexes in for example the register file, or immediates) Is this possible? I hope some of you understand what I'm trying to communicate (it's 4 am here). If you're intressted in the simulator, you can find information (ie the sources) at http://savannah.gnu.org/projects/guss/ . regards johan ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: adjusting cgen 2002-06-11 19:09 adjusting cgen Johan Rydberg @ 2002-06-12 8:13 ` Frank Ch. Eigler 2002-06-16 8:04 ` Johan Rydberg 0 siblings, 1 reply; 3+ messages in thread From: Frank Ch. Eigler @ 2002-06-12 8:13 UTC (permalink / raw) To: Johan Rydberg; +Cc: cgen [-- Attachment #1: Type: text/plain, Size: 1666 bytes --] Hi - > [...] > 1) Is it possible to adjust CGEN to recognize on-page branches? > This could be a huge optimization for me, since this will eliminate > the full tlb+mmu lookup for (near) branches. If nothing else, they could be detected within the branch instruction semantics. They could set some private simulator state that signals that the previously identified imem page is still valid. Or even better, this logic could be put into the general instruction execution loop directly: if the new PC is on the same page as the old PC, then use the previous value. > 2) Is it possible to adjust the -gen-argbuf-elm fn in sid-decode.scm to > generate bit fields instead of full integers? [...] > What I would like to do is to reduce the size of the sem_fields union > to a total of 32-bits (for a 32-bit architecture). [...] Are you sure that this is a worthwhile thing to do? You should mark up the generated sources by hand once, and see if it makes a positive or negative impact on performance. If it's positive for interesting hosts, we should do this cgen-wide. > If you're intressted in the simulator, you can find information (ie > the sources) at http://savannah.gnu.org/projects/guss/ . Not to be discouraging, but can you explain why you'd like to build a new simulator framework, when you're welcome to make contributions to established ones like sid and even the older gdb simulators? (It's of course a good personal learning exercise to build things from scratch, but please realize that there is a *lot* of work involved in making a nice, fully featured framework.) - FChE [-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: adjusting cgen 2002-06-12 8:13 ` Frank Ch. Eigler @ 2002-06-16 8:04 ` Johan Rydberg 0 siblings, 0 replies; 3+ messages in thread From: Johan Rydberg @ 2002-06-16 8:04 UTC (permalink / raw) To: Frank Ch . Eigler; +Cc: cgen On 2002.06.12 17:13 Frank Ch. Eigler wrote: : : [...] : : If nothing else, they could be detected within the branch instruction : semantics. They could set some private simulator state that signals : that the previously identified imem page is still valid. Or even better, : this logic could be put into the general instruction execution loop : directly: if the new PC is on the same page as the old PC, then use : the previous value. The main idea behind GUSS is "decode once -- execute many". To achive this, the insn is decoded into a intermediate format (similar to argbuf). And the simulator engine is using threaded code, implemented using GCC's computed goto's. This means that there's really no general insn execution loop. Another idea behind GUSS is that special cases, such as on-page branching should be specialized and optimized. These special cases are, to increase performance, detected at decoding time. : > [...] : : Are you sure that this is a worthwhile thing to do? You should mark : up the generated sources by hand once, and see if it makes a positive : or negative impact on performance. If it's positive for interesting : hosts, we should do this cgen-wide. The reason for me to wanting this is that my intermediate format is built of two words, one pointing to the insn semantics, and one containing the insn arguments. Trying to minimize the intermediate format gains both memory bandwidth when simulting (just loading one word, and then shift and mask), and will save memory. And if the size of intermediate format is a power of two, you can eliminate the update of the PC for every instruction, and instead use the difference between the PC and the intermediate format pointer. example; PC = pc_diff + (vpc >> S); Where S is the difference between the size of the intermediate format and the insn length. (for a architecture with 32-bit insn, and an intermediate format of 64-bits, S is 1). Many hosts also has insns to load 64-bit instructions into a register pair. : > If you're intressted in the simulator, you can find information (ie : > the sources) at http://savannah.gnu.org/projects/guss/ . : : Not to be discouraging, but can you explain why you'd like to build a : new simulator framework, when you're welcome to make contributions to : established ones like sid and even the older gdb simulators? (It's of : course a good personal learning exercise to build things from scratch, : but please realize that there is a *lot* of work involved in making a : nice, fully featured framework.) The main reason for doing this to gain more personal knowledge of simulators, and what technices that can be used to increase the performance. And to try out some of the ideas I have, I think it's easier to write something from scratch than to learn all the internals of either SID or GDB. regards johan (sorry for the delayed reply, I've been at a music festival for the last four days). ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-06-16 15:04 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-11 19:09 adjusting cgen Johan Rydberg 2002-06-12 8:13 ` Frank Ch. Eigler 2002-06-16 8:04 ` Johan Rydberg
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).