Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Views w/ shrink and flex #57

Closed
rachitnigam opened this issue Feb 11, 2019 · 3 comments
Closed

Views w/ shrink and flex #57

rachitnigam opened this issue Feb 11, 2019 · 3 comments
Labels
High Priority Blocking language implementation

Comments

@rachitnigam
Copy link
Member

The current formulation of views requires that the underlying array have the same number of banks as the width of the dimension of the view.

Examples:
(1) Should fail:

decl a: int[10 bank 10];
view v_a = a[off = 0, w = 5]; 

(2) Should pass

decl a: int[10 bank 10];
view v_a =  a{shrink 5}[off = 0, w = 5]

(3) Should pass

decl a: int[10 bank 10];
view v_a = a{flex 3}[off = 0, w= 3]

Q1. Should the programmer be allowed to freely mix flex and shrink in multidimensional cases? Which examples should pass:
(4)

decl a: int[10 bank 10][10 bank 10]
view v_a = a{shrink 5}{}[off = 0, w = 5][off = 0, w = 10]

(5)

decl a: int[10 bank 10][10 bank 10]
view v_a = a{shrink 5}{shrink 5}[off = 0, w = 5][off = 0, w = 5]

(6)

decl a: int[10 bank 10][10 bank 10]
view v_a = a{shrink 5}{flex 3}[off = 0, w = 5][off = 0, w = 3]

Q2. What the stepping semantics of shrink and view? Did we decide that the step of a shrink array is always equal to the length and that the steps for flex can be arbitrary?

Q3. Syntax suggestions for shrink, flex, and views?

@rachitnigam rachitnigam added the High Priority Blocking language implementation label Feb 11, 2019
@sampsyo
Copy link
Contributor

sampsyo commented Feb 11, 2019

  1. I don't see any immediate problems with any of these three—they all seem like they should probably be fine? It could help to try drawing the "hardware interposer" for each to make sure they seem to have roughly predictable cost.

  2. I think those restrictions make sense, yes.

  3. Some rough ideas, based on previous discussions:

     let v = view a[0..+5];  // v is a view on a with offset 0 and width 5
     let a' = shrink a: int[10 bank 5];   // a' is like a, but with banking factor 5
     let a' = shrink a: int[10 bank 5][10 bank 5];   // for multi-dimensional arrays
    

    flex could work the same way. The idea behind the shrink syntax is that it might be nice, for clarity, to write out the new type of the "adapted" memory.

@rachitnigam
Copy link
Member Author

Alternative proposal: If shrink forces the step size to be the same as the width, the compilation looks like:

decl a: bit<10>[16 bank 8];
decl b: bit<10>[8];

for (let i = 0..8) {
  view v_a = shrink a[i:2]
  b[i] = v_a[0] + 2*v_a[1]
}

compiles to:

for (let i = 0..8) {
  b[i] = v_a[4*i + 0] + 2*v_a[4*i + 1];
}

I propose that we have the explicit syntax:

view v_a = shrink a[4 * i: 4];

where the programmer explicitly specifies 4 * i for the offset and 4 for the width. I think it would reduce mistakes like:

for (let i = 0..12) { // 12 will be OOB!
  view v_a = shrink a[i:2]
  b[i] = v_a[0] + 2*v_a[1]
}

Especially since we don't do any static bounds checking.

@rachitnigam
Copy link
Member Author

Tracking in #124.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
High Priority Blocking language implementation
Projects
None yet
Development

No branches or pull requests

2 participants