Monday, 2021-02-22

lxolkcl, is it the case that our processor will support neither altivec nor vsx?  I'm looking at the remaining known problem with the little I've implemented of svp64 in gcc, and it follows from having both vsx and svp64 enabled.  if that's not a relevant case, I shall not waste time on it, and arrange for them to be mutually exclusive instead00:47
*** wxie <wxie!~Thunderbi@> has joined #libre-soc01:10
*** lxo <lxo!~lxo@> has quit IRC01:23
*** lxo <lxo!~lxo@> has joined #libre-soc01:51
lxolkcl, I've implemented something to make them mutually exclusive, at least for now.  if they aren't, it will take quite some work to combine the svp64 patterns with the corresponding vsx and altivec ones02:00
*** revolve <revolve!> has quit IRC02:01
*** revolve <revolve!> has joined #libre-soc02:03
*** wxie1 <wxie1!~Thunderbi@> has joined #libre-soc03:35
*** wxie <wxie!~Thunderbi@> has quit IRC03:38
*** wxie1 is now known as wxie03:38
*** vpandya_ <vpandya_!uid104882@gateway/web/> has joined #libre-soc04:11
*** wxie <wxie!~Thunderbi@> has quit IRC04:44
*** vpandya_ <vpandya_!uid104882@gateway/web/> has quit IRC07:09
*** revolve <revolve!> has quit IRC08:32
*** revolve <revolve!> has joined #libre-soc08:34
*** raster <raster!~raster@enlightenment/developer/raster> has joined #libre-soc10:01
lkcllxo: correct.  SIMD is harmful, and significantly impairs and hinders design as well as costing us massive amounts of time and money.12:26
lkclalso it makes very little sense to have Cray-Vectorised-SIMD12:27
lkclthat said - *sigh* - there *may* be a requirement to *call* VSX EABI formatted functions.12:28
lkclthe rule of thumb is: VSX performance and support is absolute rock-bottom priority.  if it can actually be made *worse* performance than "strictly necessary" that is an added bonus (but not if if takes more time and effort to do so)12:31
lkclthe more that people can be discouraged and driven away from VSX the better12:31
lkclthe SIMD simulator - which we're forced to do as a kernel-side module - will have something like a 200 to 1,000 instruction overhead or possibly even higher due to context-switching, and that's perfect.12:32
*** Chips4Makers <Chips4Makers!> has joined #libre-soc13:38
*** revolve <revolve!> has quit IRC15:01
*** revolve <revolve!> has joined #libre-soc15:03
lkclcesar[m]1, i moved the pc-setting (storing NIA) out of the execute FSM15:59
lkclthe idea is to have fetch communicate with issue, issue communicate with execute16:03
lkcli just moved the setting of NIA into the fetch FSM16:21
*** raster <raster!~raster@enlightenment/developer/raster> has quit IRC18:53
*** revolve <revolve!> has quit IRC21:31
*** revolve <revolve!> has joined #libre-soc21:33
cesar[m]1Sure, makes sense. That way, you can keep fetching new instructions as long as VL=0 and it's a vector instruction.21:50
cesar[m]1Likewise, srcstep should be updated in the execute FSM. That way, it can keep issuing and executing while it's a vector instruction and srcstep != VL-1.21:53

Generated by 2.17.1 by Marius Gedminas - find it at!