Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

MIPS VS. MEMORY FLEXIBILITY

IP.com Disclosure Number: IPCOM000009085D
Original Publication Date: 1999-Jun-01
Included in the Prior Art Database: 2002-Aug-07
Document File: 3 page(s) / 141K

Publishing Venue

Motorola

Related People

Dror Halahmi: AUTHOR [+3]

Abstract

During code optimization, a programmer often sees a trade-off problem between MIPS and memo- ry. Changes in the code can reduce MIPS and mem- ory consumption. This trade-off between MIPS and memory raises the question of what should be preferred.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 3

0 M

MOTOROLA Technical Developments

MIPS VS. MEMORY FLEXIBILITY

by Dror Halahmi, Sharon Ronen and Boris Porotsky

PROBLEM DESCRIPTION

  During code optimization, a programmer often sees a trade-off problem between MIPS and memo- ry. Changes in the code can reduce MIPS and mem- ory consumption. This trade-off between MIPS and memory raises the question of what should be preferred.

  The customer should define the desired MIPS and memory consumption before starting the code optimization process. This is used to determine a ratio of MIPS per memory, and optimize the code according to it. It is difficult for the customer to change the requirements later on (unless the pro- grammer re-writes the code).

PROPOSED SOLUTION

  The proposed solution solves the problem in a different way which allows the user to determine the MIPS per memory ratio after the optimization is fin- ished, and after checking all the possibilities. The optimization process requires changes in the code. The code changes can be divided into two types. The first type is code change where there is no trade-off between MIPS and memory, because they are both reduced. The second type is code change where the trade-off exists - the new code reduces MIPS consumption but requires more memory and vice versa.

For example, the code:

mw xO,y%a move x:(rO)+,xO move y:(r4)+,yO

can be changed to:

wy xO,yO,a x:(rO)+,xO y:(r4)+,yO

reducing MIPS and program memory consumption at the same time. This code change belongs to the first type where there is no trade-off.

On the other hand, the code:

do #6, -end-loop mat xO,yO,a x:(rO)+,xO -end-loop


y:W)+,yO

can be changed to:

mat xO,yO,a mat xO,yO,a mat xO,yO,a mat xO,yO,a mat xO,yO,a mat xO,yO,a

x:(rO)+,xO

x:(rO)+,xO

x:(rO)+,xO

x:(rO)+,xO

x:(ro)+,xO

x:(ro)+,xO

y:W+,yO y:W+,yO y:(r4)+,yO y:W)+,yO y:(r4)+,yO y:(r4)+,yO

for which MIPS consumption is reduced by five cycles (because "do" instruction consumes 5 cycles), and memory consumption is increased by 3 words.

  The problem does not he only in program ROM, but also in program RAM. For example, one of the encoder subroutines in the GSM Enhanced Full Rate speech transcoder calculates the elements of a matrix A, in which A(ij) = Afjj). In a first way, ele- ments A(Q) are calculated and filled up the upper (or lower) triangular only. In a second way, ele- ments A(ij) are calculated and saved in the location of A(i,i) too (fill up all the matrix). When accessing the matrix in the first way, i<j is checked and a pointer is updated accordingly. In the second way, the pointer does not change. The first way needs more MIPS and the second way requires more data RAM.

  The trade-off between MIPS and memory raised the question of what should be preferred. The prior art proposed an arbitrary proportion, for example

37 June 1999

QMoIomla,hc. ,999

[This page contains 15 pictures or other non-text objects]

Page 2 of 3

0 M

MO7WROLA Technical Developments

1 MIPS and 1 K in the program ROM. The solution was not adopted...