Re: problems simulating register-only architecture...

Re: problems simulating register-only architecture...

[Frank Ch. Eigler]

lehotsky wrote:

: The machine I'm developing a simulator for is a "register only"
: architecture, whose only memory is 512, 32-bit registers.
: [...]
:   There are 4 registers that are "special", in that
: they are auto-indexed (e.g.) reading register X uses the contents of
: register Y as an indirect register number.
: [...]

This stuff is tricky; some cgen features don't compose well.

I'd advise keeping it simple: use c-call to hook to a single C
getter-setter function pair, and hide the indirection within.  (BTW,
don't bother represent the actual RAM block (h-memory) within cgen.)

- FChE

Re: problems simulating register-only architecture...

[Alan Lehotsky]

At 7:03 PM -0400 5/24/01, Frank Ch. Eigler wrote:
>
>I'd advise keeping it simple: use c-call to hook to a single C
>getter-setter function pair, and hide the indirection within.  (BTW,
>don't bother represent the actual RAM block (h-memory) within cgen.)
>
>- FChE

	It made the code for loading sections from the ELF object file really trivial.  The
	mapping code just does all the heavy lifting for me :-)

-- Al
-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://home.earthlink.net/users/~qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation

Re: problems simulating register-only architecture...

[Frank Ch. Eigler]

Hi -

On Thu, May 24, 2001 at 07:19:43PM -0400, Alan Lehotsky wrote:
: >I'd advise keeping it simple: use c-call to hook to a single C
: >getter-setter function pair, and hide the indirection within.  (BTW,
: >don't bother represent the actual RAM block (h-memory) within cgen.)

: It made the code for loading sections from the ELF object file
: really trivial.  The mapping code just does all the heavy lifting for me :-)

Well, you should be using a simulator infrastructure such as sid :-) which
does this stuff for you.  Note I didn't say that you shouldn't represent
the register bank as memory; just that memory should not be described within
cgen.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7DZh8VZbdDOm/ZT0RAqC0AJ46+XRWu+Qsx6lJ84pBz6NVJtuJWwCeMPI2
URRJnepVlqHl+Ug/Ik6jPNs=
=AaIp
-----END PGP SIGNATURE-----

problems simulating register-only architecture...

[lehotsky]

The machine I'm developing a simulator for is a "register only"
architecture, whose only memory is 512, 32-bit registers.

I'm trying to model this as as a group of virtual registers
with a 2k memory.

  There are 4 registers that are "special", in that
they are auto-indexed (e.g.) reading register X uses the contents of
register Y as an indirect register number.

But when I set up my "model" as follows, it doesn't work; is it
possible that the define-pmacro EA is evaluated at the wrong time?

Or, do I need to write my "get" and "set" accessors as escapes to
C code to make this work?

It appears that with these hardware elements defined, the generated
sem.c expands to code that is doing GETMEMSI() directly, 

Here's the code from my .cpu file

(define-hardware
  (name h-register)
  (comment "all addressable registers")
  (attrs VIRTUAL)
  (type memory SI (512))
  (get (index) (mem SI (EA index)))
  (set (index newval) (set (mem SI (EA index)) newval))
)

; The actual memory.... 512 32 bit words == 2048 bytes
;
(define-hardware
  (name h-memory)
  (comment "all addressable data memory")
  (type memory QI (2048))
)

.,.
...

(define-pmacro (EA index)
  (sll (cond SI
	     ((eq index ptr0x) (and #x1ff (reg SI h-register ptr0)))
	     ((eq index ptr1x) (and #x1ff (reg SI h-register ptr1)))
	     ((eq index ptr2x) (and #x1ff (reg SI h-register ptr2)))
	     ((eq index spx)   (and #x1ff (reg SI h-register sp)))
	     (else		  index))
       2)
)

......
(dni cmpi "cmp reg/imm"
     ()
     "cmpi $rd,$imm16"
     (+ OP5_CMPI  (f-dc2 #x0) rd imm16)
     (sequence ((SI result))
	       (set result (sub SI (reg SI h-register rd) (zext USI imm16)))
	       (set zbit (zflag result))
	       (set nbit (nflag result))
	       (set cbit (sub-cflag (reg SI h-register rd)
				    (zext USI imm16) (const 0))))
     ()
)


===========================
But the resulting expansion in the sem file looks like...

  SI tmp_result;
  tmp_result = SUBSI (GETMEMSI (current_cpu, pc, i_rd), ZEXTSISI (f_imm16));

Note that the REGISTER access has been optimized to a GETMEMSI, but
when I step my way thru the expansion of the GETMEMSI, the code to
evaluate the effective address is gone.

Any thoughts on this?

Is there a better way to achieve this?

-- Al

Re: problems simulating register-only architecture...

[Ben Elliston]

>>>>> "lehotsky" == lehotsky  <lehotsky@earthlink.net> writes:

  lehotsky> But when I set up my "model" as follows, it doesn't work; is it
  lehotsky> possible that the define-pmacro EA is evaluated at the
  lehotsky> wrong time?

You can debug such problems by raising the level of verbosity in the
sim generator.  Set CGENFLAGS="-v -v -v -v" (I think).

  lehotsky> Or, do I need to write my "get" and "set" accessors as
  lehotsky> escapes to C code to make this work?

That shouldn't be necessary.  If it is, it's a bug.

  lehotsky> ; The actual memory.... 512 32 bit words == 2048 bytes
  lehotsky> ;
  lehotsky> (define-hardware
  lehotsky>   (name h-memory)
  lehotsky>   (comment "all addressable data memory")
  lehotsky>   (type memory QI (2048))
  lehotsky> )

  lehotsky> (define-pmacro (EA index)

Is your pmacro really defined *after* the hardware elements?  Have you
tried placing it before all of its applications?

Ben

Re: problems simulating register-only architecture...

[Alan Lehotsky]

At 8:35 AM +1000 5/25/01, Ben Elliston wrote:

> >>>>> "lehotsky" == lehotsky  <lehotsky@earthlink.net> writes:
>
>  lehotsky> But when I set up my "model" as follows, it doesn't work; is it
>  lehotsky> possible that the define-pmacro EA is evaluated at the
>  lehotsky> wrong time?
>
>You can debug such problems by raising the level of verbosity in the
>sim generator.  Set CGENFLAGS="-v -v -v -v" (I think).

	I assume this is a make flag, not an environment variable.  Thanks for the suggestion...

>
>  lehotsky> Or, do I need to write my "get" and "set" accessors as
>  lehotsky> escapes to C code to make this work?
>
>That shouldn't be necessary.  If it is, it's a bug.
>
>  lehotsky> ; The actual memory.... 512 32 bit words == 2048 bytes
>  lehotsky> ;
>  lehotsky> (define-hardware
>  lehotsky>   (name h-memory)
>  lehotsky>   (comment "all addressable data memory")
>  lehotsky>   (type memory QI (2048))
>  lehotsky> )
>
>  lehotsky> (define-pmacro (EA index)
>
>Is your pmacro really defined *after* the hardware elements?  Have you
>tried placing it before all of its applications?

	Yes.  I was wondering if that would work, but nothing complained......

	I'll try putting things in predeclared order....

-- Al


-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://home.earthlink.net/users/~qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation