Re: MVT change in new opcode numbers?
Many thanks for being flexible here. Karen > On Jul 27, 2017, at 4:01 PM, Bjorn B Vardal <bjorn...@ca.ibm.com> wrote: > > Yes, we should be able to work with the lower range. > > - Original message - > From: Karen Kinnear <karen.kinn...@oracle.com> > To: Bjorn B Vardal <bjorn...@ca.ibm.com> > Cc: valhalla-spec-experts@openjdk.java.net > Subject: Re: MVT change in new opcode numbers? > Date: Thu, Jul 27, 2017 3:10 PM > > Sigh - it does matter to us where it starts - we do quickening internally > using the higher ranges and our code knows about > ranges for “real” java byte codes vs internal byte codes. > > If it is possible we would appreciate the lower numbers since the higher > numbers would slow down our range checking. > > thanks, > Karen > >> On Jul 27, 2017, at 2:09 PM, Bjorn B Vardal <bjorn...@ca.ibm.com >> <mailto:bjorn...@ca.ibm.com>> wrote: >> >> If you want to make it contiguous, does it matter to you (HotSpot) where it >> starts? If not, the most practical for us would be 217-225. If that doesn't >> work, I believe we'll be able to work with 203-211. >> >> - Original message - >> From: Karen Kinnear <karen.kinn...@oracle.com >> <mailto:karen.kinn...@oracle.com>> >> Sent by: "valhalla-spec-experts" >> <valhalla-spec-experts-boun...@openjdk.java.net >> <mailto:valhalla-spec-experts-boun...@openjdk.java.net>> >> To: valhalla-spec-experts@openjdk.java.net >> <mailto:valhalla-spec-experts@openjdk.java.net> >> Cc: >> Subject: MVT change in new opcode numbers? >> Date: Thu, Jul 27, 2017 1:38 PM >> >> Dan Smith, Bjorn, Dan H, Remi - >> >> Does it work for you if we change the JVMS to use the following value-type >> byte codes - i.e. >> make them contiguous? >> In the hotspot implementation, we ran out of internally-usable byte codes >> when we left holes here. >> >> _vload= 203, // 0xcb >> 248 _vstore = 204, // 0xcc >> 249 _vaload = 205, // 0xcd >> 250 _vastore = 206, // 0xce >> 251 _vreturn = 207, // 0xcf >> 252 _vdefault = 208, // 0xd0 >> 253 _vwithfield = 209, // 0xd1 >> 254 _vbox = 210, // 0xd2 >> 255 _vunbox = 211, // 0xd3 >> (note: we removed vgetfield) >> >> thanks, >> Karen >> > > >
Re: MVT change in new opcode numbers?
Yes, we should be able to work with the lower range. - Original message -From: Karen Kinnear <karen.kinn...@oracle.com>To: Bjorn B Vardal <bjorn...@ca.ibm.com>Cc: valhalla-spec-experts@openjdk.java.netSubject: Re: MVT change in new opcode numbers?Date: Thu, Jul 27, 2017 3:10 PM Sigh - it does matter to us where it starts - we do quickening internally using the higher ranges and our code knows about ranges for “real” java byte codes vs internal byte codes. If it is possible we would appreciate the lower numbers since the higher numbers would slow down our range checking. thanks, Karen On Jul 27, 2017, at 2:09 PM, Bjorn B Vardal <bjorn...@ca.ibm.com> wrote: If you want to make it contiguous, does it matter to you (HotSpot) where it starts? If not, the most practical for us would be 217-225. If that doesn't work, I believe we'll be able to work with 203-211. - Original message -From: Karen Kinnear <karen.kinn...@oracle.com>Sent by: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>To: valhalla-spec-experts@openjdk.java.netCc:Subject: MVT change in new opcode numbers?Date: Thu, Jul 27, 2017 1:38 PM Dan Smith, Bjorn, Dan H, Remi - Does it work for you if we change the JVMS to use the following value-type byte codes - i.e. make them contiguous? In the hotspot implementation, we ran out of internally-usable byte codes when we left holes here. _vload = 203, // 0xcb 248 _vstore = 204, // 0xcc 249 _vaload = 205, // 0xcd 250 _vastore = 206, // 0xce 251 _vreturn = 207, // 0xcf 252 _vdefault = 208, // 0xd0 253 _vwithfield = 209, // 0xd1 254 _vbox = 210, // 0xd2 255 _vunbox = 211, // 0xd3 (note: we removed vgetfield) thanks, Karen
Re: MVT change in new opcode numbers?
Sigh - it does matter to us where it starts - we do quickening internally using the higher ranges and our code knows about ranges for “real” java byte codes vs internal byte codes. If it is possible we would appreciate the lower numbers since the higher numbers would slow down our range checking. thanks, Karen > On Jul 27, 2017, at 2:09 PM, Bjorn B Vardal <bjorn...@ca.ibm.com> wrote: > > If you want to make it contiguous, does it matter to you (HotSpot) where it > starts? If not, the most practical for us would be 217-225. If that doesn't > work, I believe we'll be able to work with 203-211. > > - Original message - > From: Karen Kinnear <karen.kinn...@oracle.com> > Sent by: "valhalla-spec-experts" > <valhalla-spec-experts-boun...@openjdk.java.net> > To: valhalla-spec-experts@openjdk.java.net > Cc: > Subject: MVT change in new opcode numbers? > Date: Thu, Jul 27, 2017 1:38 PM > > Dan Smith, Bjorn, Dan H, Remi - > > Does it work for you if we change the JVMS to use the following value-type > byte codes - i.e. > make them contiguous? > In the hotspot implementation, we ran out of internally-usable byte codes > when we left holes here. > > _vload= 203, // 0xcb > 248 _vstore = 204, // 0xcc > 249 _vaload = 205, // 0xcd > 250 _vastore = 206, // 0xce > 251 _vreturn = 207, // 0xcf > 252 _vdefault = 208, // 0xd0 > 253 _vwithfield = 209, // 0xd1 > 254 _vbox = 210, // 0xd2 > 255 _vunbox = 211, // 0xd3 > (note: we removed vgetfield) > > thanks, > Karen > >
Re: MVT change in new opcode numbers?
If you want to make it contiguous, does it matter to you (HotSpot) where it starts? If not, the most practical for us would be 217-225. If that doesn't work, I believe we'll be able to work with 203-211. - Original message -From: Karen Kinnear <karen.kinn...@oracle.com>Sent by: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net>To: valhalla-spec-experts@openjdk.java.netCc:Subject: MVT change in new opcode numbers?Date: Thu, Jul 27, 2017 1:38 PM Dan Smith, Bjorn, Dan H, Remi - Does it work for you if we change the JVMS to use the following value-type byte codes - i.e. make them contiguous? In the hotspot implementation, we ran out of internally-usable byte codes when we left holes here. _vload = 203, // 0xcb 248 _vstore = 204, // 0xcc 249 _vaload = 205, // 0xcd 250 _vastore = 206, // 0xce 251 _vreturn = 207, // 0xcf 252 _vdefault = 208, // 0xd0 253 _vwithfield = 209, // 0xd1 254 _vbox = 210, // 0xd2 255 _vunbox = 211, // 0xd3 (note: we removed vgetfield) thanks, Karen
