4 Mar 2006 15:13
4 Mar 2006 18:22
Forw: Hi you there and how to run Cgen sample
Frank Ch. Eigler <fche <at> redhat.com>
2006-03-04 17:22:30 GMT
2006-03-04 17:22:30 GMT
From: chucking <at> sjtu.org Subject: Hi you there and how to run Cgen sample Hi, I am a first year CS post graduate in China , and new to CGEN. I wanna try Cgen's included example like ia32, and expect to gain experience of using it for gnu binary utility port. I tried as follows: configure, make , but got nothing as an executable to run in the end. And I turn to manual on your site, only to find the "how to run " chapter almost empty on that. So I wonder if you can help me out, and give me some infomation about running Cgen's included sample? I am working on a minimum-equipped Cygwin, with all the gnu build tool there. Hope I am not bothering you too muchExpecting your helping reply at your earliest convenience. Yours faithfully, Chuck Jin
8 Mar 2006 10:17
MIL-STD-1750A description
<Lorenzo.Motter <at> ses-astra.com>
2006-03-08 09:17:11 GMT
2006-03-08 09:17:11 GMT
Is anywhere available the CPU file description for the old veneralble MIL-STD-1750A? Thanks. -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail.
11 Mar 2006 15:13
14 Mar 2006 00:02
Re: Forw: Hi you there and how to run Cgen sample
Frank Ch. Eigler <fche <at> redhat.com>
2006-03-13 23:02:30 GMT
2006-03-13 23:02:30 GMT
> [...] I wanna try Cgen's included example like ia32, and expect to > gain experience of using it for gnu binary utility port. The ia32 port was never completed - it's only experimental. You may find this old thread helpful to get you started: http://sourceware.org/ml/cgen/2003-q4/msg00014.html - FChE
14 Mar 2006 14:34
Re: [RFA:] Fix breakage of manually building SID CPU
Hans-Peter Nilsson <hans-peter.nilsson <at> axis.com>
2006-03-14 13:34:19 GMT
2006-03-14 13:34:19 GMT
> Date: Mon, 30 Jan 2006 12:21:20 -0500
> From: Dave Brolley <brolley <at> redhat.com>
> The patch looks ok to me. Please go ahead and commit it.
Finally done.
I must mention at least for the record that I see further errors
stopping generation of a SID cgen-cpu description with sources
as of today, for example the guile command sequence:
(load "dev.scm")
(load-sid)
(cload #:arch "../../cpu/cris" #:options "with-scache" #:machs "crisv32")
(cgen-semantics.cxx)
Gets:
... (seemingly successfully output C++ semantic translations.)
return status;
#undef FLD
}
Processing semantics for bcc-b: "b${cc} ${o-pcrel}" ...
Backtrace:
In ./rtl-c.scm:
1400: 0* [string-append "(delay ...) rtx applied to wrong type of operand '" ...]
1398: 1 [context-error #f ...
1393: 2* (if (let # #) (context-error # #))
1387: 3 (let* (# # #) (if # #) (if # #) ...)
(Continue reading)
14 Mar 2006 17:46
Re: [RFA:] Fix breakage of manually building SID CPU
Dave Brolley <brolley <at> redhat.com>
2006-03-14 16:46:45 GMT
2006-03-14 16:46:45 GMT
Hans-Peter Nilsson wrote:
>(i.e. the earliest occurrence of "delay" for the enabled mach).
>I guessed this could be related to some change in delay
>semantics, but the usage in cris.cpu seems no different to other
>*.cpu. Except that some *.cpu use (delay (const 1) ...) instead
>of (delay 1 ...) but unfortunately that doesn't help; changing
>that doesn't affect the behavior.
>
>
>
(delay 1 ...) vs (delay (const 1) ...) won't make a difference. They are
identical.
However, It seems that CGEN generating SID expects a different syntax
for delay than CGEN generating SIM.
CGEN generating sid expects
(set (delay 1 pc) retaddr)
while CGEN generating SIM expects
(delay 1 (set pc retaddr))
I do recall the new syntax being introduced some time ago, however, I
don't recall that the old syntax was depricated. Does anyone know if
both are still supposed to work?
Dave
(Continue reading)
14 Mar 2006 18:02
Re: [RFA:] Fix breakage of manually building SID CPU
Hans-Peter Nilsson <hans-peter.nilsson <at> axis.com>
2006-03-14 17:02:46 GMT
2006-03-14 17:02:46 GMT
> Date: Tue, 14 Mar 2006 11:46:45 -0500 > From: Dave Brolley <brolley <at> redhat.com> > However, It seems that CGEN generating SID expects a different syntax > for delay than CGEN generating SIM. > > CGEN generating sid expects > > (set (delay 1 pc) retaddr) > > while CGEN generating SIM expects > > (delay 1 (set pc retaddr)) > > I do recall the new syntax being introduced some time ago, however, I > don't recall that the old syntax was depricated. Does anyone know if > both are still supposed to work? FWIW, the "new syntax" didn't catch my eye as I saw only src/cpu/mt.cpu using it; none in src/cgen/cpu. Maybe some wart was introduced in whatever compatibility there is. brgds, H-P
14 Mar 2006 18:16
Re: [RFA:] Fix breakage of manually building SID CPU
Frank Ch. Eigler <fche <at> redhat.com>
2006-03-14 17:16:55 GMT
2006-03-14 17:16:55 GMT
Hi - > >(i.e. the earliest occurrence of "delay" for the enabled mach). > >I guessed this could be related to some change in delay > >semantics, but the usage in cris.cpu seems no different to other > >*.cpu. [...] I believe (delay) was never implemented properly for the SIM backend, only for SID. I expect it to be treated rather like a no-op for SIM, or equivalently, that any SIM-targeting .cpu users of (delay) should work just as well without. - FChE
14 Mar 2006 22:24
Re: [RFA:] Fix breakage of manually building SID CPU
Hans-Peter Nilsson <hans-peter.nilsson <at> axis.com>
2006-03-14 21:24:37 GMT
2006-03-14 21:24:37 GMT
> Date: Tue, 14 Mar 2006 12:16:55 -0500 > From: "Frank Ch. Eigler" <fche <at> redhat.com> > > >(i.e. the earliest occurrence of "delay" for the enabled mach). > > >I guessed this could be related to some change in delay > > >semantics, but the usage in cris.cpu seems no different to other > > >*.cpu. [...] > > I believe (delay) was never implemented properly for the SIM backend, > only for SID. I expect it to be treated rather like a no-op for SIM, > or equivalently, that any SIM-targeting .cpu users of (delay) should > work just as well without. Um, what (delay) are you referring to above? A (delay 1 (set pc something)) certainly is different to (set pc something). I now think it's the cris.cpu pc setter function that may have something that causes the SID cgen-cpu generators to barf. brgds, H-P
RSS Feed