General discussion about the OpenRISC architecture ()

Jeremy Bennett | 26 Jun 2012 09:33

Re: Getting involved with OR2k

On Tue, 2012-06-26 at 00:04 +0100, Rob Riglar wrote:
> Hi Julius & Jeremy,
> 
> I attempted to join the mailing lists with a spamable new email
> address robr.opencores <at> gmail.com. 
> I think I was partially successful but the openrisc.net website timed
> out when confirming.

Hi Rob,

I've transferred this discussion to the mailing lists. I don't know what
went wrong with signing up to openrisc.net, but Jonas Bonn (who owns
that list) should pick up this message and add you manually.

> > I'd like to get to a point where we have a fair bit of the
> implementation work done before we lock down the ISA, so we can fully
> evaluate the impact of the choices. For example, have a basic tool
> chain and simulator which we can tweak with different instructions and
> see the performance and code size impacts on a set of software, say
> the GCC/newlib libraries, u-boot, and an RTOS or two. Anyway, that's
> the sort of thing I'm working toward at the moment, but first is to
> have a bit of a think about the different options available to us for
> the basic instruction set.
> 
> 
> I really like this idea Julius. If there was a rough and ready
> toolchain & ISS, we'd be able to prototype & evaluate different ISA
> options and see how they play out with some different use cases, and
> how well suited they would be to being implemented in RTL.
> Creating a GCC port is the hard part in this equation (for 16-bit

(Continue reading)

headers

Stefan Kristiansson | 10 Jul 2012 08:18

Re: Getting involved with OR2k

On Tue, Jun 26, 2012 at 08:33:11AM +0100, Jeremy Bennett wrote:
> On Tue, 2012-06-26 at 00:04 +0100, Rob Riglar wrote:
> > > I'd like to get to a point where we have a fair bit of the
> > implementation work done before we lock down the ISA, so we can fully
> > evaluate the impact of the choices. For example, have a basic tool
> > chain and simulator which we can tweak with different instructions and
> > see the performance and code size impacts on a set of software, say
> > the GCC/newlib libraries, u-boot, and an RTOS or two. Anyway, that's
> > the sort of thing I'm working toward at the moment, but first is to
> > have a bit of a think about the different options available to us for
> > the basic instruction set.
> > 
> > 
> > I really like this idea Julius. If there was a rough and ready
> > toolchain & ISS, we'd be able to prototype & evaluate different ISA
> > options and see how they play out with some different use cases, and
> > how well suited they would be to being implemented in RTL.
> > Creating a GCC port is the hard part in this equation (for 16-bit
> > instruction support which  probably can't build upon the OR1K port too
> > easily); though to this end, I guess as a first pass, a simple single
> > file noddy assembler could be knocked up in an afternoon.
> 
> A simple assembler can be knocked up, but I suggest a CGEN assembler
> would be the better route. Still quick (although not an afternoon) and
> should give you the basis of both an assembler and simulator. You'll
> need a linker/loader as well. I think Julius Baxter has been working on
> updating the CGEN spec for OR1K and that should be a good starting
> point.
>

(Continue reading)

headers

Jeremy Bennett | 10 Jul 2012 13:07

Re: Getting involved with OR2k

On Tue, 2012-07-10 at 09:18 +0300, Stefan Kristiansson wrote:

<snip>

> You're most probably right that creating the GCC port is
> the hard part, but there is a "shortcut" available.
> I'd be more inclined to use LLVM/Clang as a stepping stone,
> the effort required to get such a port up and running is
> a lot less steep (I'm clearly biased here though ;))
> 
> Without any prior compiler internals experience I think
> it took about a month, working a couple of hours each evening,
> to get the OR1K LLVM/Clang port compile u-boot and run it
> (admittedly, I had some initial help by the effort started by
> Jonas Bonn and the example OpenRISC LLVM backend by
> Anton Korobeynikov, but it's still a good reference how quick
> you can get something useful out of it).
> Around the 2 month mark I got uClibc and busybux compiling and running.

Hi Stefan,

That's a good point. Using LLVM as a starting point is a very good idea.

Best wishes,

Jeremy

--

-- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050

(Continue reading)