* unable to find precise mode to match cpu word-bitsize 24 @ 2009-06-21 19:02 Dave Korn 2009-06-21 23:07 ` Doug Evans 0 siblings, 1 reply; 6+ messages in thread From: Dave Korn @ 2009-06-21 19:02 UTC (permalink / raw) To: cgen Hello CGEN list, I'm attempting to develop a model of a CPU that has a natural 24-bit wordsize: 24-bit registers, 24-bit ALU, 24-bit data bus... 24-bit everything, and no subword or unaligned accesses - in fact, you could really call them 24-bit bytes, as it's the minimum addressable unit. A naive attempt to just write (define-cpu [ . . . ] (word-bitsize 24) [ . . . ] ) fails with the error message from the title of this post. I've crudely hacked in a couple of three-quarter int modes like this: Index: mode.scm =================================================================== RCS file: /cvs/src/src/cgen/mode.scm,v retrieving revision 1.4 diff -p -u -r1.4 mode.scm --- mode.scm 16 Jul 2003 05:35:47 -0000 1.4 +++ mode.scm 21 Jun 2009 18:45:00 -0000 @@ -499,6 +499,7 @@ Define a mode, all arguments specified. (dfm 'QI "8 bit byte" '() 'INT 8 1 "int" "'x'" #f #f #f) (dfm 'HI "16 bit int" '() 'INT 16 2 "int" "'x'" #f #f #f) + (dfm 'TQI "24 bit int" '() 'INT 24 3 "int" "'x'" #f #f #f) (dfm 'SI "32 bit int" '() 'INT 32 4 "int" "'x'" #f #f #f) (dfm 'DI "64 bit int" '(FN-SUPPORT) 'INT 64 8 "" "'D'" #f #f #f) @@ -506,6 +507,8 @@ Define a mode, all arguments specified. 8 1 "unsigned int" "'x'" (mode:lookup 'QI) #f #f) (dfm 'UHI "16 bit unsigned int" '() 'UINT 16 2 "unsigned int" "'x'" (mode:lookup 'HI) #f #f) + (dfm 'UTQI "24 bit unsigned int" '() 'UINT + 24 3 "unsigned int" "'x'" (mode:lookup 'TQI) #f #f) (dfm 'USI "32 bit unsigned int" '() 'UINT 32 4 "unsigned int" "'x'" (mode:lookup 'SI) #f #f) (dfm 'UDI "64 bit unsigned int" '(FN-SUPPORT) 'UINT just so that I can get on with writing my i-fields, but will it work? If I want my (simulated) pc to increment in steps of 1, not 3, should I define the number of bytes to 1 instead of 3? Or would I be best off redefining QI mode altogether? Sorry if this is a n00b question, but a bit of googling and grepping didn't show up anyone trying this before. cheers, DaveK ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unable to find precise mode to match cpu word-bitsize 24 2009-06-21 19:02 unable to find precise mode to match cpu word-bitsize 24 Dave Korn @ 2009-06-21 23:07 ` Doug Evans 2009-06-22 0:05 ` Dave Korn 0 siblings, 1 reply; 6+ messages in thread From: Doug Evans @ 2009-06-21 23:07 UTC (permalink / raw) To: Dave Korn; +Cc: cgen Dave Korn wrote: > Hello CGEN list, > > I'm attempting to develop a model of a CPU that has a natural 24-bit > wordsize: 24-bit registers, 24-bit ALU, 24-bit data bus... 24-bit everything, > and no subword or unaligned accesses - in fact, you could really call them > 24-bit bytes, as it's the minimum addressable unit. > > A naive attempt to just write > > (define-cpu > [ . . . ] > (word-bitsize 24) > [ . . . ] > ) > > fails with the error message from the title of this post. I've crudely hacked > in a couple of three-quarter int modes like this: > > Index: mode.scm > =================================================================== > RCS file: /cvs/src/src/cgen/mode.scm,v > retrieving revision 1.4 > diff -p -u -r1.4 mode.scm > --- mode.scm 16 Jul 2003 05:35:47 -0000 1.4 > +++ mode.scm 21 Jun 2009 18:45:00 -0000 > @@ -499,6 +499,7 @@ Define a mode, all arguments specified. > > (dfm 'QI "8 bit byte" '() 'INT 8 1 "int" "'x'" #f #f #f) > (dfm 'HI "16 bit int" '() 'INT 16 2 "int" "'x'" #f #f #f) > + (dfm 'TQI "24 bit int" '() 'INT 24 3 "int" "'x'" #f #f #f) > (dfm 'SI "32 bit int" '() 'INT 32 4 "int" "'x'" #f #f #f) > (dfm 'DI "64 bit int" '(FN-SUPPORT) 'INT 64 8 "" "'D'" #f #f #f) > > @@ -506,6 +507,8 @@ Define a mode, all arguments specified. > 8 1 "unsigned int" "'x'" (mode:lookup 'QI) #f #f) > (dfm 'UHI "16 bit unsigned int" '() 'UINT > 16 2 "unsigned int" "'x'" (mode:lookup 'HI) #f #f) > + (dfm 'UTQI "24 bit unsigned int" '() 'UINT > + 24 3 "unsigned int" "'x'" (mode:lookup 'TQI) #f #f) > (dfm 'USI "32 bit unsigned int" '() 'UINT > 32 4 "unsigned int" "'x'" (mode:lookup 'SI) #f #f) > (dfm 'UDI "64 bit unsigned int" '(FN-SUPPORT) 'UINT > > > just so that I can get on with writing my i-fields, but will it work? If I > want my (simulated) pc to increment in steps of 1, not 3, should I define the > number of bytes to 1 instead of 3? Or would I be best off redefining QI mode > altogether? Sorry if this is a n00b question, but a bit of googling and > grepping didn't show up anyone trying this before. > > This is new ground so we can decide how we want things to look, and then make it work. I think(!) that we don't want to redefine QI. For clarity's sake, the T in TQI is for "Three", right? [3 * 8 = 24] I've been thinking that while QI,HI,SI,DI are clear, any other similarly named modes might become problematic over time. An alternative is I24 of course, but if one goes that route one needs to resolve what to do about QI,etc. [They *could* become aliases of I8, etc. and perhaps eventually be removed entirely, at least from the application independent core. Anything related to gcc may certainly want to use them.] This route has the benefit of solving this problem for future weird architectures. [And just because we add I24 doesn't mean we'd have to immediately add all the others, e.g. I23, etc.] Also, since it's related, I've been thinking of removing UQI, UHI, etc. They were a useful internal implementation detail at one point, but I think they've become more of a problem than a help. [But we needn't block this discussion on what happens with that.] I'd be curious to hear what others think. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unable to find precise mode to match cpu word-bitsize 24 2009-06-21 23:07 ` Doug Evans @ 2009-06-22 0:05 ` Dave Korn 2009-06-22 17:05 ` Doug Evans 0 siblings, 1 reply; 6+ messages in thread From: Dave Korn @ 2009-06-22 0:05 UTC (permalink / raw) To: Doug Evans; +Cc: Dave Korn, cgen 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. > I think(!) that we don't want to redefine QI. Well, if you do a GCC port with #define BITS_PER_UNIT 24, don't you get a 24-bit QImode? I don't know how closely the XXmodes in cgen are meant to match the semantics of GCC's modes, or whether it's just a friendly and familiar naming scheme to adopt. > For clarity's sake, the T in TQI is for "Three", right? [3 * 8 = 24] Yep. I guess I could also call it PSImode by analogy to GCC. > I've been thinking that while QI,HI,SI,DI are clear, any other similarly > named modes might become problematic over time. > > An alternative is I24 of course, but if one goes that route one needs to > resolve what to do about QI,etc. > [They *could* become aliases of I8, etc. and perhaps eventually be > removed entirely, at least from the application independent core. > Anything related to gcc may certainly want to use them.] This route has > the benefit of solving this problem for future weird architectures. > [And just because we add I24 doesn't mean we'd have to immediately add > all the others, e.g. I23, etc.] Well, the most flexible option I think would be to implement the equivalent of BITS_PER_UNIT and have the QI/HI/SI/DI modes adjust to match, maybe. I'm really new to this and don't fully understand how modes are used in cgen yet, but if it's ever a long-term goal to be able to cgen parts of the GCC backend, it would be handy to mirror the same storage-layout abilities. > Also, since it's related, I've been thinking of removing UQI, UHI, etc. > They were a useful internal implementation detail at one point, but I > think they've become more of a problem than a help. Ah, I was wondering; GCC doesn't bother to represent signedness in the mode definitions, it's explicit in RTL sign/zero extend operations. cheers, DaveK ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unable to find precise mode to match cpu word-bitsize 24 2009-06-22 0:05 ` Dave Korn @ 2009-06-22 17:05 ` Doug Evans 2009-07-04 23:35 ` Dave Korn 0 siblings, 1 reply; 6+ messages in thread From: Doug Evans @ 2009-06-22 17:05 UTC (permalink / raw) To: Dave Korn; +Cc: cgen 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 think(!) that we don't want to redefine QI. >> > > Well, if you do a GCC port with #define BITS_PER_UNIT 24, don't you get a > 24-bit QImode? I don't know how closely the XXmodes in cgen are meant to > match the semantics of GCC's modes, or whether it's just a friendly and > familiar naming scheme to adopt. > Good point. It's not clear just how closely to follow gcc, but I have tried not to diverge *too* much. [*Certainly* there are debatable instances.] OTOH, not everything in gcc is chocolatey goodness or applicable. And gcc is just one app. A simulator, for example, needs to know both the host and the target wordiness. Having QI be one thing on the host and something else on the target may be an issue (at least to the extent that it's one more thing whose meaning is context dependent). > >> For clarity's sake, the T in TQI is for "Three", right? [3 * 8 = 24] >> > > Yep. I guess I could also call it PSImode by analogy to GCC. > > >> I've been thinking that while QI,HI,SI,DI are clear, any other similarly >> named modes might become problematic over time. >> >> An alternative is I24 of course, but if one goes that route one needs to >> resolve what to do about QI,etc. >> [They *could* become aliases of I8, etc. and perhaps eventually be >> removed entirely, at least from the application independent core. >> Anything related to gcc may certainly want to use them.] This route has >> the benefit of solving this problem for future weird architectures. >> [And just because we add I24 doesn't mean we'd have to immediately add >> all the others, e.g. I23, etc.] >> > > Well, the most flexible option I think would be to implement the equivalent > of BITS_PER_UNIT and have the QI/HI/SI/DI modes adjust to match, maybe. I'm > really new to this and don't fully understand how modes are used in cgen yet, > but if it's ever a long-term goal to be able to cgen parts of the GCC backend, > it would be handy to mirror the same storage-layout abilities. > > Modes serve two purposes: specify how big something is in bits, and specify interpretation (e.g. int vs float). Things are muddied a bit, e.g. the operation kind (e.g. div vs udiv) specifies signedness but the mode specifies int vs float. Blech. Going forward maybe the thing to do is remove meaning from the mode (e.g. just specify number of bits), have interpretation provided by the operation, and if an app wants to provide its own names for certain modes (e.g. gcc's QImode) then leave it to the app. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unable to find precise mode to match cpu word-bitsize 24 2009-06-22 17:05 ` Doug Evans @ 2009-07-04 23:35 ` Dave Korn 2009-07-14 5:59 ` Doug Evans 0 siblings, 1 reply; 6+ messages in thread From: Dave Korn @ 2009-07-04 23:35 UTC (permalink / raw) To: Doug Evans; +Cc: Dave Korn, cgen 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? cheers, DaveK ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: unable to find precise mode to match cpu word-bitsize 24 2009-07-04 23:35 ` Dave Korn @ 2009-07-14 5:59 ` Doug Evans 0 siblings, 0 replies; 6+ messages in thread From: Doug Evans @ 2009-07-14 5:59 UTC (permalink / raw) To: Dave Korn; +Cc: cgen 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). ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-07-14 5:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-06-21 19:02 unable to find precise mode to match cpu word-bitsize 24 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 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).