Re: [openrisc] Question regarding ISA for OR1200

["Damjan Lampret" <lampret@opencores.org>]

Hi Shane,

I think right now MIPS way is the only way how we can do it. But for next
generation we should definately do something.

regards,
Damjan

----- Original Message -----
From: "Shane Nay" <shane@minirl.com>
To: <openrisc@opencores.org>
Sent: Tuesday, September 04, 2001 4:47 AM
Subject: [openrisc] Question regarding ISA for OR1200


> I've been sort of poking a stick at this project and taking a look at
> it from a few different angles.  One major thing that I noticed right
> away I wanted to bring up because I think it's a long term mistake.
>
> Okay, the instruction pretext, what describes what sort of
> instruction we're going to be executing is only 6 bits.  Plenty of
> space left over for good encoded data, but not a lot of space for
> billions of instructions.  Which is a-okay.  But one particular
> missing instruction is going to be really painfull for PIC (Position
> Independent Code) code: "bl" or branch and link.
>
> MIPS makes the mistake of only encoding 16 bits worth of branch and
> link space, but ARM does it just right.  The importance of this is
> actually kind of critical.  If you don't have a good branch and link
> instruction, then you have to resort to register loading/manual
> offset and a "jalr" call.  That means every function call in a
> standard ABI takes at least 3 instructions to execute.  (lui, ori,
> jalr)  This can get painfull for code size, and is one of the key
> contributors to MIPS code being so bloated.
>
> The one way I've found to get around this is by using a statically
> linked library system were you could use the "jal" instruction to get
> where you need to go.  But this creates very very ugly problems in
> keeping libraries in sync, etc.  (Reference to Jay's SNOW ABI used on
> Agenda)
>
> Anyway, does anyone have any suggestion for combating this problem?
>
> Thanks,
> Shane Nay.
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml