API tools faq
paste
Guest User

2022-04-14-thread-dump-RISC-V_asm_instruction_name_madness_entire_thread.txt

a guest
Mar 14th, 2022
344
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 211.38 KB | None | 0 0
raw download clone embed print report
  1. =====
  2. The below was generated from the thread in
  3. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205288
  4. to make it easier to read it using the command line provided/suggested
  5. (Thanks!) by psychoslave @ https://news.ycombinator.com/item?id=30673056
  6. which was
  7.  
  8. elinks 'https://www.realworldtech.com/forum/?threadid=205288' -dump | grep curpostid | sed -e 's/.*https/https/' | while read -r url ; do elinks -dump $url | awk '/By:/, /Previous/' | sed \$d ; done
  9.  
  10. =====
  11.  
  12.  
  13. By: anonymou5 ([email protected]), March 9, 2022 3:58 am
  14. Room: [25]Moderated Discussions
  15. > What have the guys deciding the naming of these instructions have been
  16. smoking?
  17.  
  18. Direct your feedback and contributions to https://lists.riscv.org/g/main
  19. to make it productive?
  20.  
  21. By: Heikki Kultala ([email protected]), March 9, 2022
  22. 1:35 am
  23. Room: [25]Moderated Discussions
  24. There seem to be lots of really stupid instruction naming conventions on
  25. RISC-V:
  26.  
  27. When they were proposing a select instruction to the BMI extension, they
  28. were going to call it "cmov"
  29.  
  30. In the V-extension, they have an instruction named "vrgather".
  31.  
  32. But that instruction is not a gather load instruction. This instructoin is
  33. just a shuffle instruction.
  34.  
  35. What have the guys deciding the naming of these instructions have been
  36. smoking?
  37.  
  38. [26]Next Post in Thread >
  39.  
  40. Topic Posted By Date
  41. [27]RISC-V asm instruction name madness Heikki Kultala 2022/03/09
  42. 01:35 AM
  43. [28]RISC-V asm instruction name madness anonymou5 2022/03/09
  44. 03:58 AM
  45. [29]RISC-V asm instruction name madness -.- 2022/03/09
  46. 06:39 AM
  47. [30]RISC-V asm instruction name madness dmcq 2022/03/09
  48. 07:04 AM
  49. [31]RISC-V asm instruction name madness -.- 2022/03/09
  50. 06:52 PM
  51. [32]RISC-V asm instruction name madness Anon 2022/03/09
  52. 07:33 PM
  53. [33]RISC-V asm instruction name Jukka Larja 2022/03/10
  54. madness 08:55 AM
  55. [34]RISC-V asm instruction name dmcq 2022/03/10
  56. madness 10:32 AM
  57. [35]RISC-V asm instruction name -.- 2022/03/10
  58. madness 08:52 PM
  59. [36]RISC-V asm instruction name rwessel 2022/03/11
  60. madness 10:38 AM
  61. [37]More descriptive asm -.- 2022/03/11
  62. instruction names 09:22 PM
  63. [38]More descriptive asm dmcq 2022/03/12
  64. instruction names 01:58 AM
  65. [39]More descriptive asm dmcq 2022/03/12
  66. instruction names 01:42 PM
  67. [40]More descriptive asm -.- 2022/03/12
  68. instruction names 09:28 PM
  69. [41]More descriptive dmcq 2022/03/13
  70. asm instruction names 12:46 PM
  71. [42]More descriptive dmcq 2022/03/13
  72. asm instruction names 12:47 PM
  73. [43]RISC-V asm instruction name Anon 2022/03/10
  74. madness 09:35 PM
  75. [44]RISC-V asm instruction name Jukka Larja 2022/03/11
  76. madness 11:55 PM
  77. [45]RISC-V asm instruction name anonymou5 2022/03/12
  78. madness 02:43 AM
  79. [46]RISC-V asm instruction Jukka Larja 2022/03/13
  80. name madness 01:25 AM
  81. [47]RISC-V asm instruction name -.- 2022/03/10
  82. madness 08:47 PM
  83. [48]RISC-V asm instruction name Anon 2022/03/10
  84. madness 09:40 PM
  85. [49]RISC-V asm instruction name gallier2 2022/03/11
  86. madness 12:34 AM
  87. [50]RISC-V asm instruction name Tim 2022/03/11
  88. madness 11:56 AM
  89. [51]RISC-V asm instruction name Anon 2022/03/11
  90. madness 12:25 PM
  91. [52]RISC-V asm instruction Joern Engel 2022/03/11
  92. name madness 01:04 PM
  93. [53]Me, too (but ...) Mark Roulo 2022/03/11
  94. 12:26 PM
  95. [54]Me, too (but ...) David Hess 2022/03/12
  96. 11:39 AM
  97. [55]Me, too (but ...) Adrian 2022/03/12
  98. 12:01 PM
  99. [56]If APL and assembly Mark Roulo 2022/03/12
  100. language had a baby ... 07:12 PM
  101. [57]If APL and assembly Adrian 2022/03/13
  102. language had a baby ... 01:38 AM
  103. [58]If APL and Mark Roulo 2022/03/13
  104. assembly language had a baby ... 08:53 AM
  105. [59]If APL and Adrian 2022/03/13
  106. assembly language had a baby ... 10:57 AM
  107. [60]If APL and rwessel 2022/03/13
  108. assembly language had a baby ... 11:23 AM
  109. [61]If APL and Andrey 2022/03/14
  110. assembly language had a baby ... 01:42 AM
  111. [62]If APL and Anon 2022/03/14
  112. assembly language had a baby ... 01:57 AM
  113. [63]If APL Michael S 2022/03/14
  114. and assembly language had a baby ... 04:07 AM
  115. [64]Me, too (but ...) Michael S 2022/03/13
  116. 08:14 AM
  117. [65]Me, too (but ...) Michael S 2022/03/13
  118. 08:27 AM
  119. [66]Me, too (but ...) Adrian 2022/03/13
  120. 10:29 AM
  121. [67]Me, too (but ...) David Hess 2022/03/13
  122. 02:54 PM
  123. [68]Me, too (but ...) Michael S 2022/03/13
  124. 03:09 PM
  125. [69]Me, too (but ...) Andrey 2022/03/14
  126. 01:27 AM
  127. [70]Me, too (but ...) Michael S 2022/03/14
  128. 03:08 AM
  129. [71]Me, too (but Andrey 2022/03/14
  130. ...) 05:36 AM
  131. [72]Me, too (but rwessel 2022/03/14
  132. ...) 06:32 AM
  133. [73]Me, too (but Jukka Larja 2022/03/14
  134. ...) 07:10 AM
  135. [74]RISC-V asm instruction name Adrian 2022/03/11
  136. madness 01:06 PM
  137. [75]RISC-V asm instruction name Andrey 2022/03/11
  138. madness 04:01 PM
  139. [76]RISC-V asm instruction Adrian 2022/03/12
  140. name madness 02:24 AM
  141. [77]RISC-V asm instruction name anon2 2022/03/11
  142. madness 05:37 PM
  143. [78]RISC-V asm instruction name rwessel 2022/03/11
  144. madness 07:44 PM
  145. [79]RISC-V asm instruction name madness Heikki Kultala 2022/03/09
  146. 11:31 PM
  147. [80]RISC-V asm instruction name madness Adrian 2022/03/10
  148. 07:33 AM
  149. [81]RISC-V asm instruction name madness anonymou5 2022/03/10
  150. 12:59 PM
  151. [82]RISC-V asm instruction name rwessel 2022/03/11
  152. madness 10:42 AM
  153. [83]RISC-V asm instruction name Anon 2022/03/11
  154. madness 11:44 AM
  155. [84]RISC-V asm instruction name Adrian 2022/03/11
  156. madness 01:45 PM
  157. [85]RISC-V asm instruction name Anon 2022/03/11
  158. madness 02:33 PM
  159. [86]RISC-V asm instruction Andrey 2022/03/11
  160. name madness 04:09 PM
  161. [87]RISC-V asm instruction Adrian 2022/03/12
  162. name madness 02:41 AM
  163. [88]RISC-V asm Andrey 2022/03/12
  164. instruction name madness 04:57 AM
  165. [89]RISC-V asm Anon 2022/03/12
  166. instruction name madness 05:01 AM
  167. [90]RISC-V asm rwessel 2022/03/12
  168. instruction name madness 07:12 AM
  169. [91]RISC-V asm Anon 2022/03/12
  170. instruction name madness 01:50 PM
  171. [92]RISC-V asm Adrian 2022/03/12
  172. instruction name madness 05:50 AM
  173. [93]RISC-V asm instruction name madness Linus Torvalds 2022/03/10
  174. 01:25 PM
  175. [94]RISC-V asm instruction name Ian Ameline 2022/03/10
  176. madness 03:34 PM
  177. [95]RISC-V asm instruction name gallier2 2022/03/11
  178. madness 12:42 AM
  179. [96]RISC-V asm instruction name konrad.schwarz 2022/03/11
  180. madness 05:26 AM
  181. [97]RISC-V asm instruction name konrad.schwarz 2022/03/11
  182. madness 05:31 AM
  183. [98]RISC-V asm instruction name Adrian 2022/03/11
  184. madness 06:25 AM
  185. [99]RISC-V asm instruction name cqwrteur 2022/03/11
  186. madness 12:57 PM
  187. [100]RISC-V asm instruction name Linus Torvalds 2022/03/11
  188. madness 01:28 PM
  189. This Post has been deleted
  190. [101]numeric direction hobold 2022/03/11
  191. 05:29 PM
  192. [102]numeric direction RIIR 2022/03/11
  193. 08:19 PM
  194. [103]numeric direction anonymou5 2022/03/12
  195. 02:48 AM
  196. [104]RISC-V asm instruction name Konrad Schwarz 2022/03/12
  197. madness 02:31 AM
  198. [105]RISC-V asm instruction rwessel 2022/03/12
  199. name madness 07:04 AM
  200. [106]RISC-V asm instruction name dmcq 2022/03/12
  201. madness 12:18 PM
  202. [107]RISC-V asm instruction name ** 2022/03/12
  203. madness 02:20 PM
  204. [108]The most clueless post of Heikki Kultala 2022/03/13
  205. the year 2022 12:28 AM
  206. [109]RISC-V asm instruction name Joern Engel 2022/03/13
  207. madness 12:08 AM
  208. [110]big endian crap Heikki Kultala 2022/03/13
  209. 12:31 AM
  210. [111]big endian crap Anne O. Nymous 2022/03/13
  211. 03:40 AM
  212. [112]big endian crap dmcq 2022/03/13
  213. 02:30 PM
  214. [113]RISC-V asm instruction gallier2 2022/03/14
  215. name madness 08:09 AM
  216. [114]RISC-V asm instruction name madness -.- 2022/03/10
  217. 09:00 PM
  218. [115]RISC-V asm instruction name Anon 2022/03/10
  219. madness 09:42 PM
  220. [116]RISC-V asm instruction name Heikki Kultala 2022/03/10
  221. madness 10:59 PM
  222. [117]RISC-V asm instruction name -.- 2022/03/11
  223. madness 01:21 AM
  224. [118]RISC-V asm instruction name rwessel 2022/03/11
  225. madness 10:56 AM
  226. [119]RISC-V asm instruction name Anon 2022/03/11
  227. madness 12:07 PM
  228. [120]RISC-V asm instruction name -.- 2022/03/11
  229. madness 09:29 PM
  230. [121]RISC-V asm instruction name madness Andrey 2022/03/10
  231. 09:55 AM
  232. [122]Why not both? Matt Sayler 2022/03/10
  233. 02:56 PM
  234. [123]Why not both? Andrey 2022/03/10
  235. 06:01 PM
  236. [124]Why not both? Matt Sayler 2022/03/11
  237. 10:10 AM
  238. [125]RISC-V asm instruction name madness -.- 2022/03/10
  239. 09:03 PM
  240. [126]RISC-V asm instruction name Andrey 2022/03/11
  241. madness 04:01 AM
  242. [127]Vector ISA and LVI sr 2022/03/09
  243. 12:26 PM
  244.  
  245. Reply to this Topic
  246. Name: [128]_____________________
  247. Email: [129]_____________________
  248. Topic: [130]_____________________
  249. [131][ ] No Text
  250. [132]
  251. _________________________________________
  252. _________________________________________
  253. _________________________________________
  254. _________________________________________
  255. _________________________________________
  256. _________________________________________
  257. _________________________________________
  258. _________________________________________
  259. Body: _________________________________________
  260. _________________________________________
  261. _________________________________________
  262. _________________________________________
  263. _________________________________________
  264. _________________________________________
  265. _________________________________________
  266. _________________________________________
  267. _________________________________________
  268. _________________________________________
  269. _________________________________________
  270. _________________________________________
  271. How do you spell avocado? [133]_____________________
  272. [134][ Post ] [135][ Preview ]
  273.  
  274. Editor's Picks
  275.  
  276. [136]PhysX87: Software Deficiency
  277.  
  278. By [137]David Kanter
  279.  
  280. [138]Intel's Sandy Bridge Graphics Architecture
  281.  
  282. By [139]David Kanter
  283.  
  284. [140]The Spider and the Mountain
  285.  
  286. By [141]Paul DeMone
  287.  
  288. RWT on Twitter
  289.  
  290. o Intel just released a fantastic history of the transistor, tracing the
  291. evolution of this marvelous technology. The...
  292. [142]https://t.co/emlyyFwOef [143]about 2 weeks ago
  293. o Happy New Year! May 2022 be even better than 2021. [144]about 2 months
  294. ago
  295. o [145]@TwitterSupport how can I disable notifications from
  296. recommendations? I have disabled all notifications and still g...
  297. [146]https://t.co/B0zaVgOU2u [147]about 4 months ago [148]in reply to
  298. TwitterSupport
  299.  
  300. [149]@RWT
  301.  
  302. o [150]About Us
  303. o [151]Contact Us
  304. o [152]Reprints
  305.  
  306. o [153]Advertise at RWT
  307. o [154]Write for Us
  308. o [155]Privacy Policy
  309.  
  310. o [156]Forum Guidelines
  311. o [157]Membership
  312. o [158]TOS
  313.  
  314. Copyright (c) 1996-2022 [159]Real World Tech . All Rights Reserved .
  315.  
  316. Insert/edit link
  317.  
  318. [160]Close
  319.  
  320. Enter the destination URL
  321.  
  322. URL [161]_____________________
  323. Link Text [162]_____________________
  324. [163][ ] Open link in a new tab
  325.  
  326. Or link to existing content
  327.  
  328. Search [164]_____________________
  329.  
  330. No search term specified. Showing recent items. Search or use up and down
  331. arrow keys to select an item.
  332.  
  333. [165]Cancel
  334. [166][ Add Link ]
  335.  
  336. References
  337.  
  338. Visible links
  339. 1. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205288
  340. 2. https://www.realworldtech.com/feed/
  341. 3. https://www.realworldtech.com/comments/feed/
  342. 4. https://www.realworldtech.com/forum/feed/
  343. 5. https://www.realworldtech.com/wp-json/
  344. 6. https://www.realworldtech.com/wp-json/wp/v2/pages/2048
  345. 7. https://www.realworldtech.com/?p=2048
  346. 8. https://www.realworldtech.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fwww.realworldtech.com%2Fforum%2F
  347. 9. https://www.realworldtech.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fwww.realworldtech.com%2Fforum%2F&format=xml
  348. 10. https://www.realworldtech.com/
  349. 11. https://www.realworldtech.com/wp-login.php?redirect_to=http%3A%2F%2Fwww.realworldtech.com%2Fforum%2F%3Fthreadid%3D205288%26curpostid%3D205288
  350. 12. https://www.realworldtech.com/category/cloud/
  351. 13. https://www.realworldtech.com/category/mobile/
  352. 14. https://www.realworldtech.com/category/graphics/
  353. 15. https://www.realworldtech.com/category/chips/
  354. 16. https://www.realworldtech.com/category/software/
  355. 17. https://www.realworldtech.com/cpu/
  356. 18. https://www.realworldtech.com/gpu/
  357. 19. https://www.realworldtech.com/semis/
  358. 20. https://www.realworldtech.com/strategy/
  359. 21. https://www.realworldtech.com/forum/
  360. 22. http://www.facebook.com/pages/Real-World-Tech/153534084681202
  361. 23. http://twitter.com/rwt
  362. 24. https://www.realworldtech.com/feed/rss/
  363. 25. https://www.realworldtech.com/forum/?roomid=1
  364. 26. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205290
  365. 27. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205288
  366. 28. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205290
  367. 29. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205292
  368. 30. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205293
  369. 31. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205306
  370. 32. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205308
  371. 33. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205311
  372. 34. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205313
  373. 35. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205324
  374. 36. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205341
  375. 37. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205362
  376. 38. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205365
  377. 39. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205380
  378. 40. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205384
  379. 41. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205397
  380. 42. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205398
  381. 43. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205327
  382. 44. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205364
  383. 45. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205369
  384. 46. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205388
  385. 47. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205323
  386. 48. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205328
  387. 49. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205332
  388. 50. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205345
  389. 51. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205347
  390. 52. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205350
  391. 53. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205348
  392. 54. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205377
  393. 55. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205378
  394. 56. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205383
  395. 57. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205389
  396. 58. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205393
  397. 59. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205395
  398. 60. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205396
  399. 61. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205404
  400. 62. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205405
  401. 63. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205408
  402. 64. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205391
  403. 65. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205392
  404. 66. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205394
  405. 67. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205400
  406. 68. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205401
  407. 69. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205403
  408. 70. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205406
  409. 71. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205409
  410. 72. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205410
  411. 73. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205411
  412. 74. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205351
  413. 75. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205356
  414. 76. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205366
  415. 77. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205359
  416. 78. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205360
  417. 79. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205309
  418. 80. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205310
  419. 81. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205314
  420. 82. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205342
  421. 83. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205344
  422. 84. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205354
  423. 85. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205355
  424. 86. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205357
  425. 87. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205368
  426. 88. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205372
  427. 89. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205373
  428. 90. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205376
  429. 91. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205381
  430. 92. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205374
  431. 93. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205315
  432. 94. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205319
  433. 95. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205333
  434. 96. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205336
  435. 97. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205337
  436. 98. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205338
  437. 99. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205349
  438. 100. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205352
  439. 101. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205358
  440. 102. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205361
  441. 103. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205370
  442. 104. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205367
  443. 105. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205375
  444. 106. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205379
  445. 107. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205382
  446. 108. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205386
  447. 109. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205385
  448. 110. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205387
  449. 111. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205390
  450. 112. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205399
  451. 113. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205412
  452. 114. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205325
  453. 115. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205329
  454. 116. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205330
  455. 117. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205334
  456. 118. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205343
  457. 119. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205346
  458. 120. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205363
  459. 121. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205312
  460. 122. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205318
  461. 123. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205321
  462. 124. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205339
  463. 125. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205326
  464. 126. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205335
  465. 127. https://www.realworldtech.com/forum/?threadid=205288&curpostid=205301
  466. 136. https://www.realworldtech.com/physx87/
  467. 137. https://www.realworldtech.com/author/dkanter/
  468. 138. https://www.realworldtech.com/sandy-bridge-gpu/
  469. 139. https://www.realworldtech.com/author/dkanter/
  470. 140. https://www.realworldtech.com/ev8-mckinley/
  471. 141. https://www.realworldtech.com/author/pdemone/
  472. 142. https://t.co/emlyyFwOef
  473. 143. http://twitter.com/rwt/statuses/1496298024695476225
  474. 144. http://twitter.com/rwt/statuses/1477220413696462850
  475. 145. http://twitter.com/TwitterSupport
  476. 146. https://t.co/B0zaVgOU2u
  477. 147. http://twitter.com/rwt/statuses/1458138609295380482
  478. 148. http://twitter.com/TwitterSupport/statuses/
  479. 149. Follow @RWT
  480. http://twitter.com/RWT
  481. 150. https://www.realworldtech.com/about/
  482. 151. https://www.realworldtech.com/contact/
  483. 152. https://www.realworldtech.com/reprints/
  484. 153. https://www.realworldtech.com/advertise/
  485. 154. https://www.realworldtech.com/write-for-rwt/
  486. 155. https://www.realworldtech.com/privacy-policy/
  487. 156. https://www.realworldtech.com/forum-guidelines/
  488. 157. https://www.realworldtech.com/membership/
  489. 158. https://www.realworldtech.com/user-agreement/
  490. By: anonymou5 ([email protected]), March 9, 2022 3:58 am
  491. Room: [25]Moderated Discussions
  492. > What have the guys deciding the naming of these instructions have been
  493. smoking?
  494.  
  495. Direct your feedback and contributions to https://lists.riscv.org/g/main
  496. to make it productive?
  497.  
  498. By: -.- ([email protected]), March 9, 2022 6:39 am
  499. Room: [25]Moderated Discussions
  500. Plenty of weird names in many assembly dialects, to be honest.
  501. PALIGNR in x86 or EXT in AArch64 aren't obvious unless you already know
  502. what the instruction does.
  503.  
  504. Perhaps it's time to move away from compact assembly instruction names?
  505. I'd say the number of people writing assembly is relatively small compared
  506. to the number of people reading it, and being less compact could help
  507. beginners understand the code more easily.
  508. We're no longer stuck with technology where long names are problematic. We
  509. aren't using 80 character wide screens any more.
  510. Why not make opcode names longer and more descriptive? You could always
  511. keep a more compact version to cater to the few assembly writers without
  512. autocomplete.
  513.  
  514. I just don't see why assembly syntax today still has to follow the design
  515. principles of ~50 years ago.
  516.  
  517. By: dmcq ([email protected]), March 9, 2022 7:04 am
  518. Room: [25]Moderated Discussions
  519. -.- ([email protected]) on March 9, 2022 5:39 am wrote:
  520. > Plenty of weird names in many assembly dialects, to be honest.
  521. > PALIGNR in x86 or EXT in AArch64 aren't obvious unless you already know
  522. what the instruction does.
  523. >
  524. > Perhaps it's time to move away from compact assembly instruction names?
  525. I'd say the number
  526. > of people writing assembly is relatively small compared to the number of
  527. people reading
  528. > it, and being less compact could help beginners understand the code more
  529. easily.
  530. > We're no longer stuck with technology where long names are problematic.
  531. > We aren't using 80 character wide screens any more.
  532. > Why not make opcode names longer and more descriptive? You could always
  533. keep a
  534. > more compact version to cater to the few assembly writers without
  535. autocomplete.
  536. >
  537. > I just don't see why assembly syntax today still has to follow the
  538. design principles of ~50 years ago.
  539.  
  540. Well I can see the point of an assembly language support which described
  541. the instructions when you clicked on them and helped with fields and did
  542. some other checking. However I don't think making the names longer would
  543. help, they'd just make them longer to read. Their function is either
  544. obvious or needs a lookup and a paragrapph to explain.
  545.  
  546. By: -.- ([email protected]), March 9, 2022 6:52 pm
  547. Room: [25]Moderated Discussions
  548. dmcq ([email protected]) on March 9, 2022 6:04 am wrote:
  549. > Their function is either obvious or needs a lookup and a paragrapph to
  550. explain.
  551.  
  552. Yes, some will require explanation, but I disagree that simple instruction
  553. names are always obvious.
  554.  
  555. For example, let's take the AArch64 instruction UXTB. Let's say you have
  556. some assembly experience, but haven't seen that instruction before. Is
  557. what it does obvious? Would you even be able to roughly guess as to what
  558. it might do?
  559.  
  560. On the other hand, if it were called "EXTEND_U8" or perhaps
  561. "ZERO_EXTEND_BYTE" or whatever. Maybe it might still not be clear what it
  562. exactly does, but I'd imagine it'd give much more of a clue regarding its
  563. functionality, without the need to consult the manual.
  564.  
  565. I also don't see if being so much of a hassle to read either.
  566.  
  567. It can also help cases where you have looked up the instruction in the
  568. past, but don't see it often enough to remember what it does all the time.
  569. Perhaps you've seen "BSL" before, but "BIT_SELECT" is likely going to
  570. stick in your memory better.
  571.  
  572. With ISAs having thousands of instructions nowadays, there's bound to be
  573. instructions you haven't seen or don't remember clearly.
  574.  
  575. By: Anon ([email protected]), March 9, 2022 7:33 pm
  576. Room: [25]Moderated Discussions
  577. -.- ([email protected]) on March 9, 2022 5:52 pm wrote:
  578. > With ISAs having thousands of instructions nowadays, there's bound
  579. > to be instructions you haven't seen or don't remember clearly.
  580.  
  581. Yeah, but most instructions are just variations and ISAs usually have a
  582. standard way to describe the variations, even when the ISA is a mess like
  583. x86, ADDPS, the "P" means packed, for more or less a thousand
  584. instructions, the last "S" means single, I see no point in writing the
  585. full meaning of those suffixes, the start of the instruction, which
  586. contains the actual instrcution name, usually get a good share of letters
  587. to describe it, like INSERTPS.
  588.  
  589. By: Jukka Larja ([email protected]), March 10, 2022 8:55
  590. am
  591. Room: [25]Moderated Discussions
  592. Anon ([email protected]) on March 9, 2022 6:33 pm wrote:
  593. > -.- ([email protected]) on March 9, 2022 5:52 pm wrote:
  594. > > With ISAs having thousands of instructions nowadays, there's bound
  595. > > to be instructions you haven't seen or don't remember clearly.
  596. >
  597. > Yeah, but most instructions are just variations and ISAs usually have a
  598. standard way to describe
  599. > the variations, even when the ISA is a mess like x86, ADDPS, the "P"
  600. means packed, for more
  601. > or less a thousand instructions, the last "S" means single, I see no
  602. point in writing the
  603. > full meaning of those suffixes, the start of the instruction, which
  604. contains the actual instrcution
  605. > name, usually get a good share of letters to describe it, like INSERTPS.
  606.  
  607. ADDPS is a perfect example of simple instruction name that I can't easily
  608. read, while addPackedSingle (or ADDPACKEDSINGLE or ADD_PACKED_SINGLE or
  609. whatever you fancy) would be easy. After years of reading assembly, I
  610. don't still don't really like it, because I constantly have to concentrate
  611. on stupid trivialities like this. Having more letters in instruction names
  612. would be a huge benefit for readability.
  613.  
  614. (I'm not trying to say everyone has this problem, or that majority has it,
  615. or even that many people have it, but I do. I don't expect ever to learn
  616. to read assembly fluently. I've had enough practice to know my limits.)
  617.  
  618. -JLarja
  619.  
  620. By: dmcq ([email protected]), March 10, 2022 10:32 am
  621. Room: [25]Moderated Discussions
  622. Jukka Larja ([email protected]) on March 10, 2022 7:55
  623. am wrote:
  624. > Anon ([email protected]) on March 9, 2022 6:33 pm wrote:
  625. > > -.- ([email protected]) on March 9, 2022 5:52 pm wrote:
  626. > > > With ISAs having thousands of instructions nowadays, there's bound
  627. > > > to be instructions you haven't seen or don't remember clearly.
  628. > >
  629. > > Yeah, but most instructions are just variations and ISAs usually have
  630. a standard way to describe
  631. > > the variations, even when the ISA is a mess like x86, ADDPS, the "P"
  632. means packed, for more
  633. > > or less a thousand instructions, the last "S" means single, I see no
  634. point in writing the
  635. > > full meaning of those suffixes, the start of the instruction, which
  636. contains the actual instrcution
  637. > > name, usually get a good share of letters to describe it, like
  638. INSERTPS.
  639. >
  640. > ADDPS is a perfect example of simple instruction name that I can't
  641. easily read, while addPackedSingle
  642. > (or ADDPACKEDSINGLE or ADD_PACKED_SINGLE or whatever you fancy) would be
  643. easy. After years of reading
  644. > assembly, I don't still don't really like it, because I constantly have
  645. to concentrate on stupid trivialities
  646. > like this. Having more letters in instruction names would be a huge
  647. benefit for readability.
  648. >
  649. > (I'm not trying to say everyone has this problem, or that majority has
  650. it,
  651. > or even that many people have it, but I do. I don't expect ever to learn
  652. > to read assembly fluently. I've had enough practice to know my limits.)
  653. >
  654. > -JLarja
  655.  
  656. It would be far better to have a good editor I think that describes what's
  657. under the cursor rather than having big long dscriptions everywhere
  658. written into the text. I've used probably in the order of twenty different
  659. assembly languages and the main problem I've found is special restrictions
  660. in arguments and different register orders and knowing what constants are
  661. allowed.
  662.  
  663. By: -.- ([email protected]), March 10, 2022 8:52 pm
  664. Room: [25]Moderated Discussions
  665. dmcq ([email protected]) on March 10, 2022 9:32 am wrote:
  666. > It would be far better to have a good editor I think that describes
  667. what's under the cursor rather
  668. > than having big long dscriptions everywhere written into the text.
  669.  
  670. That's certainly helpful, but the problem is that it's not really
  671. universal. Assembly instructions can appear in various places, from forum
  672. posts and email discussions to webpage articles and console outputs.
  673. Expecting assembly hints to be implemented everywhere seems unrealistic.
  674.  
  675. Yes, more descriptive opcodes won't magically address all complexities,
  676. but I think it's at least a step in the right direction.
  677.  
  678. By: rwessel ([email protected]), March 11, 2022 10:38 am
  679. Room: [25]Moderated Discussions
  680. -.- ([email protected]) on March 10, 2022 7:52 pm wrote:
  681. > dmcq ([email protected]) on March 10, 2022 9:32 am wrote:
  682. > > It would be far better to have a good editor I think that describes
  683. what's under the cursor rather
  684. > > than having big long dscriptions everywhere written into the text.
  685. >
  686. > That's certainly helpful, but the problem is that it's not really
  687. universal. Assembly instructions
  688. > can appear in various places, from forum posts and email discussions to
  689. webpage articles and console
  690. > outputs. Expecting assembly hints to be implemented everywhere seems
  691. unrealistic.
  692. >
  693. > Yes, more descriptive opcodes won't magically address all complexities,
  694. > but I think it's at least a step in the right direction.
  695.  
  696. It's a tradeoff. I write rather more assembler than the vast majority of
  697. programmers*, but I'm going to be annoyed if you turn assembler into Cobol
  698. - especially since assembler tends to be pretty bulky to begin with. The
  699. terse mnemonics are usually the least of the issues with writing assembler
  700. (although they're certainly of source of negative clarity for the
  701. inexperienced).
  702.  
  703. Many uses wouldn't care about wordier mnemonics. Things that generate
  704. assembler, like compiler back ends, for example.
  705.  
  706. So the question are the few of us still writing assembler enough of an
  707. audience to care about? On the flip side, are the dilettantes** enough
  708. reason to change? Although the way these things usually end up, we're more
  709. likely to end up with both sets of mnemonics (or whatever we call the
  710. wordier versions) in programs...
  711.  
  712. *Since the vast majority of programmers don't write any, that's actually
  713. not much of a claim...
  714.  
  715. **And I don't mean that *too* derogatorily ;-)
  716.  
  717. By: -.- ([email protected]), March 11, 2022 9:22 pm
  718. Room: [25]Moderated Discussions
  719. rwessel ([email protected]) on March 11, 2022 9:38 am wrote:
  720. > It's a tradeoff. I write rather more assembler than the vast majority of
  721. programmers*, but I'm
  722. > going to be annoyed if you turn assembler into Cobol - especially since
  723. assembler tends to be pretty
  724. > bulky to begin with. The terse mnemonics are usually the least of the
  725. issues with writing assembler
  726.  
  727. I like to believe that programmers aren't writing any serious code in
  728. Windows Notepad, or that data entry is the bottleneck of programming.
  729.  
  730. Many code editors these days support (possibly adaptive) auto-complete, so
  731. I'd expect a good assembly coding tool to have something similar (along
  732. with operand hints, inline syntax checking etc). I'd imagine that longer
  733. instructions shouldn't matter too much if they can just be auto-completed
  734. for you, though admittedly, there may be some overall downside to those
  735. who code a lot of assembly.
  736.  
  737. By: dmcq ([email protected]), March 12, 2022 1:58 am
  738. Room: [25]Moderated Discussions
  739. -.- ([email protected]) on March 11, 2022 8:22 pm wrote:
  740. > rwessel ([email protected]) on March 11, 2022 9:38 am wrote:
  741. > > It's a tradeoff. I write rather more assembler than the vast majority
  742. of programmers*, but I'm
  743. > > going to be annoyed if you turn assembler into Cobol - especially
  744. since assembler tends to be pretty
  745. > > bulky to begin with. The terse mnemonics are usually the least of the
  746. issues with writing assembler
  747. >
  748. > I like to believe that programmers aren't writing any serious code in
  749. > Windows Notepad, or that data entry is the bottleneck of programming.
  750. >
  751. > Many code editors these days support (possibly adaptive) auto-complete,
  752. so I'd expect a good assembly
  753. > coding tool to have something similar (along with operand hints, inline
  754. syntax checking etc). I'd
  755. > imagine that longer instructions shouldn't matter too much if they can
  756. just be auto-completed for
  757. > you, though admittedly, there may be some overall downside to those who
  758. code a lot of assembly.
  759.  
  760. A big problem with longer names would be that the operands would be either
  761. poitioned higgeldy piggeldy to the right or if space is always allowed for
  762. he biggest instruction most would have the operands far away.
  763.  
  764. By: dmcq ([email protected]), March 12, 2022 1:42 pm
  765. Room: [25]Moderated Discussions
  766. dmcq ([email protected]) on March 12, 2022 12:58 am wrote:
  767. > -.- ([email protected]) on March 11, 2022 8:22 pm wrote:
  768. > > rwessel ([email protected]) on March 11, 2022 9:38 am
  769. wrote:
  770. > > > It's a tradeoff. I write rather more assembler than the vast
  771. majority of programmers*, but I'm
  772. > > > going to be annoyed if you turn assembler into Cobol - especially
  773. since assembler tends to be pretty
  774. > > > bulky to begin with. The terse mnemonics are usually the least of
  775. the issues with writing assembler
  776. > >
  777. > > I like to believe that programmers aren't writing any serious code in
  778. > > Windows Notepad, or that data entry is the bottleneck of programming.
  779. > >
  780. > > Many code editors these days support (possibly adaptive)
  781. auto-complete, so I'd expect a good assembly
  782. > > coding tool to have something similar (along with operand hints,
  783. inline syntax checking etc). I'd
  784. > > imagine that longer instructions shouldn't matter too much if they can
  785. just be auto-completed for
  786. > > you, though admittedly, there may be some overall downside to those
  787. who code a lot of assembly.
  788. >
  789. > A big problem with longer names would be that the operands would be
  790. either poitioned higgeldy piggeldy to
  791. > the right or if space is always allowed for he biggest instruction most
  792. would have the operands far away.
  793.  
  794. This is related to tht assembler programming tends to be sort of two
  795. dimensional. One wants to looks at a numbe rof previous and following
  796. instructions and operands rather than having a unique state one should be
  797. at like in a C pprogram when one writes some eexpression.
  798.  
  799. By: -.- ([email protected]), March 12, 2022 9:28 pm
  800. Room: [25]Moderated Discussions
  801. dmcq ([email protected]) on March 12, 2022 12:58 am wrote:
  802. > A big problem with longer names would be that the operands would be
  803. either poitioned higgeldy piggeldy to
  804. > the right or if space is always allowed for he biggest instruction most
  805. would have the operands far away.
  806.  
  807. For your first assertion, many ISAs already have variable length
  808. instruction names, so you either accept "higgeldy piggeldy" or your line
  809. up the operands with spaces.
  810.  
  811. As for your second, "big problem" and "far away" are subjective.
  812. Regardless, I think there's a number of solutions that could be adopted,
  813. e.g.:
  814.  
  815. - add enough space for most instructions to be aligned, and let that rare
  816. extra-long instruction be unaligned
  817. - the above, but put operands on an indented new line instead of being
  818. unaligned
  819. - right-align the instruction name, instead of left alignment (your editor
  820. could help position things here, instead of trying to manually figure out
  821. the correct spacing each time)
  822.  
  823. Allowing for longer names doesn't mean names should try and fit an entire
  824. paragraph in them - it's just about being a little less cryptic about what
  825. the instruction does.
  826.  
  827. By: dmcq ([email protected]), March 13, 2022 12:46 pm
  828. Room: [25]Moderated Discussions
  829. -.- ([email protected]) on March 12, 2022 9:28 pm wrote:
  830. > dmcq ([email protected]) on March 12, 2022 12:58 am wrote:
  831. > > A big problem with longer names would be that the operands would be
  832. either poitioned higgeldy piggeldy to
  833. > > the right or if space is always allowed for he biggest instruction
  834. most would have the operands far away.
  835. >
  836. > For your first assertion, many ISAs already have variable length
  837. instruction names,
  838. > so you either accept "higgeldy piggeldy" or your line up the operands
  839. with spaces.
  840. >
  841. > As for your second, "big problem" and "far away" are subjective.
  842. Regardless,
  843. > I think there's a number of solutions that could be adopted, e.g.:
  844. >
  845. > - add enough space for most instructions to be aligned,
  846. > and let that rare extra-long instruction be unaligned
  847. > - the above, but put operands on an indented new line instead of being
  848. unaligned
  849. > - right-align the instruction name, instead of left alignment (your
  850. editor could help position
  851. > things here, instead of trying to manually figure out the correct
  852. spacing each time)
  853. >
  854. > Allowing for longer names doesn't mean names should try and fit an
  855. entire paragraph in
  856. > them - it's just about being a little less cryptic about what the
  857. instruction does.
  858.  
  859. Her is a little ARM instruction sequence for example
  860. movs mm, mm
  861. umullne tmp, mm, n, mm
  862. subne n, n, mm
  863. addne n, mm, n, lsr #1
  864. mov n, n, lsr sh
  865.  
  866. with words in and aligning except for the longest
  867. move.s mm, mm
  868. unsigned_multiply_long.ne tmp, mm, n, mm
  869. subtract.ne n, n, mm
  870. add.ne n, mm, n, lsr #1
  871. move n, n, lsr sh
  872. this breaks the 2d nature where oe wishes to look at uses of the registrs
  873. in nearby instructions and might want to rename them or move instructions
  874. around. This also puts in a larger space between the common instructions
  875. and thir operands.
  876.  
  877. putting onto a new line
  878. move.s mm, mm
  879. unsigned_multiply_long.ne
  880. tmp, mm, n, mm
  881. subtract.ne n, n, mm
  882. add.ne n, mm, n, lsr #1
  883. move n, n, lsr sh
  884. this breaks up the registers with the ends of long instructions and moves
  885. the operands further apart
  886.  
  887. right aligning the instruction
  888. move.s mm, mm
  889. unsigned_multiply_long.ne tmp, mm, n, mm
  890. subtract.ne n, n, mm
  891. add.ne n, mm, n, lsr #1
  892. move n, n, lsr sh
  893. at least the operands are kept well organized but the operations re mad
  894. more difficult to scan down.
  895.  
  896. Perhaps I could get used to one of these but who figures out exactly how
  897. much toinclude in the names? Would it be okay to say sub instead of
  898. subtract? For instand umull doesn't actually multiply two longs - it
  899. multiplies two 32 bit registers n and mm above treated as unsigned into
  900. two registers, the low part which is temp above and the high part in mm.
  901. SO perhaps multply_unsigned_extending_to_long might be a better name even
  902. if longer. Though anyone who'd been working on this would be fed up of
  903. that long name after a while as assembler can take a while to get just
  904. right.
  905.  
  906. By: dmcq ([email protected]), March 13, 2022 12:47 pm
  907. Room: [25]Moderated Discussions
  908. dmcq ([email protected]) on March 13, 2022 12:46 pm wrote:
  909. > -.- ([email protected]) on March 12, 2022 9:28 pm wrote:
  910. > > dmcq ([email protected]) on March 12, 2022 12:58 am wrote:
  911. > > > A big problem with longer names would be that the operands would be
  912. either poitioned higgeldy piggeldy to
  913. > > > the right or if space is always allowed for he biggest instruction
  914. most would have the operands far away.
  915. > >
  916. > > For your first assertion, many ISAs already have variable length
  917. instruction names,
  918. > > so you either accept "higgeldy piggeldy" or your line up the operands
  919. with spaces.
  920. > >
  921. > > As for your second, "big problem" and "far away" are subjective.
  922. Regardless,
  923. > > I think there's a number of solutions that could be adopted, e.g.:
  924. > >
  925. > > - add enough space for most instructions to be aligned,
  926. > > and let that rare extra-long instruction be unaligned
  927. > > - the above, but put operands on an indented new line instead of being
  928. unaligned
  929. > > - right-align the instruction name, instead of left alignment (your
  930. editor could help position
  931. > > things here, instead of trying to manually figure out the correct
  932. spacing each time)
  933. > >
  934. > > Allowing for longer names doesn't mean names should try and fit an
  935. entire paragraph in
  936. > > them - it's just about being a little less cryptic about what the
  937. instruction does.
  938. >
  939. > Her is a little ARM instruction sequence for example
  940. > movs mm, mm
  941. > umullne tmp, mm, n, mm
  942. > subne n, n, mm
  943. > addne n, mm, n, lsr #1
  944. > mov n, n, lsr sh
  945. >
  946. > with words in and aligning except for the longest
  947. > move.s mm, mm
  948. > unsigned_multiply_long.ne tmp, mm, n, mm
  949. > subtract.ne n, n, mm
  950. > add.ne n, mm, n, lsr #1
  951. > move n, n, lsr sh
  952. > this breaks the 2d nature where oe wishes to look at uses of the
  953. registrs in nearby
  954. > instructions and might want to rename them or move instructions around.
  955. This also
  956. > puts in a larger space between the common instructions and thir
  957. operands.
  958. >
  959. > putting onto a new line
  960. > move.s mm, mm
  961. > unsigned_multiply_long.ne
  962. > tmp, mm, n, mm
  963. > subtract.ne n, n, mm
  964. > add.ne n, mm, n, lsr #1
  965. > move n, n, lsr sh
  966. > this breaks up the registers with the ends of long instructions and
  967. moves the operands further apart
  968. >
  969. > right aligning the instruction
  970. > move.s mm, mm
  971. > unsigned_multiply_long.ne tmp, mm, n, mm
  972. > subtract.ne n, n, mm
  973. > add.ne n, mm, n, lsr #1
  974. > move n, n, lsr sh
  975. > at least the operands are kept well organized but the operations re mad
  976. more difficult to scan down.
  977. >
  978. > Perhaps I could get used to one of these but who figures out exactly how
  979. much toinclude in the names?
  980. > Would it be okay to say sub instead of subtract? For instand umull
  981. doesn't actually multiply two
  982. > longs - it multiplies two 32 bit registers n and mm above treated as
  983. unsigned into two registers,
  984. > the low part which is temp above and the high part in mm. SO perhaps
  985. multply_unsigned_extending_to_long
  986. > might be a better name even if longer. Though anyone who'd been working
  987. on this would be fed up
  988. > of that long name after a while as assembler can take a while to get
  989. just right.
  990.  
  991. By the way microcode can have a number of instructions per line
  992.  
  993. By: Anon ([email protected]), March 10, 2022 9:35 pm
  994. Room: [25]Moderated Discussions
  995. Jukka Larja ([email protected]) on March 10, 2022 7:55
  996. am wrote:
  997. > ADDPS is a perfect example of simple instruction name that I can't
  998. easily read, while addPackedSingle
  999. > (or ADDPACKEDSINGLE or ADD_PACKED_SINGLE or whatever you fancy) would be
  1000. easy. After years of reading
  1001. > assembly, I don't still don't really like it, because I constantly have
  1002. to concentrate on stupid trivialities
  1003. > like this. Having more letters in instruction names would be a huge
  1004. benefit for readability.
  1005. >
  1006. > (I'm not trying to say everyone has this problem, or that majority has
  1007. it,
  1008. > or even that many people have it, but I do. I don't expect ever to learn
  1009. > to read assembly fluently. I've had enough practice to know my limits.)
  1010. >
  1011. > -JLarja
  1012.  
  1013. I don't know how often you read assembly or how long is the code you read,
  1014. but come on, imagine a piece of code with 100 instructions, all of them
  1015. followed by a prefix, having all of them were followed by _PACKED_SINGLE
  1016. is far more annoying than a simple PS, even if it is a prefix you don't
  1017. know you only have to look up once for that 100 instructions sequence.
  1018.  
  1019. By: Jukka Larja ([email protected]), March 11, 2022
  1020. 11:55 pm
  1021. Room: [25]Moderated Discussions
  1022. Anon ([email protected]) on March 10, 2022 8:35 pm wrote:
  1023. > Jukka Larja ([email protected]) on March 10, 2022 7:55
  1024. am wrote:
  1025. > > ADDPS is a perfect example of simple instruction name that I can't
  1026. easily read, while addPackedSingle
  1027. > > (or ADDPACKEDSINGLE or ADD_PACKED_SINGLE or whatever you fancy) would
  1028. be easy. After years of reading
  1029. > > assembly, I don't still don't really like it, because I
  1030. > > constantly have to concentrate on stupid trivialities
  1031. > > like this. Having more letters in instruction names would be a huge
  1032. benefit for readability.
  1033. > >
  1034. > > (I'm not trying to say everyone has this problem, or that majority has
  1035. it,
  1036. > > or even that many people have it, but I do. I don't expect ever to
  1037. learn
  1038. > > to read assembly fluently. I've had enough practice to know my
  1039. limits.)
  1040. > >
  1041. > > -JLarja
  1042. >
  1043. > I don't know how often you read assembly or how long is the code you
  1044. read, but come on, imagine
  1045. > a piece of code with 100 instructions, all of them followed by a prefix,
  1046. having all of them
  1047. > were followed by _PACKED_SINGLE is far more annoying than a simple PS,
  1048. even if it is a prefix
  1049. > you don't know you only have to look up once for that 100 instructions
  1050. sequence.
  1051.  
  1052. It's not about knowing what PS means (that's a separate problem, one which
  1053. good editor or relatively simple PDF file can solve). It's about me not
  1054. seeing if it's PS or SS written on screen. Overly short words are simply
  1055. hard to read. Same goes for short variable and function names. No one
  1056. suggest that variable or function names should be limited to 3-6
  1057. characters, because that would be insane. Why is it sane to limit
  1058. assembler mnemonics?
  1059.  
  1060. -JLarja
  1061.  
  1062. By: anonymou5 ([email protected]), March 12, 2022 2:43 am
  1063. Room: [25]Moderated Discussions
  1064. Jukka Larja ([email protected]) on March 11, 2022 10:55
  1065. pm wrote:
  1066. > It's not about knowing what PS means (that's a separate problem, one
  1067. which good editor or
  1068. > relatively simple PDF file can solve). It's about me not seeing if it's
  1069. PS or SS written
  1070. > on screen. Overly short words are simply hard to read. Same goes for
  1071. short variable and
  1072. > function names. No one suggest that variable or function names should be
  1073. limited to 3-6
  1074. > characters, because that would be insane. Why is it sane to limit
  1075. assembler mnemonics?
  1076.  
  1077. uhm... still not seeing you over in the RISC-V universe
  1078.  
  1079. but hey... keep whining down the /dev/null device here
  1080.  
  1081. By: Jukka Larja ([email protected]), March 13, 2022 1:25
  1082. am
  1083. Room: [25]Moderated Discussions
  1084. anonymou5 ([email protected]) on March 12, 2022 1:43 am wrote:
  1085. > Jukka Larja ([email protected]) on March 11, 2022
  1086. 10:55 pm wrote:
  1087. > > It's not about knowing what PS means (that's a separate problem, one
  1088. which good editor or
  1089. > > relatively simple PDF file can solve). It's about me not seeing if
  1090. it's PS or SS written
  1091. > > on screen. Overly short words are simply hard to read. Same goes for
  1092. short variable and
  1093. > > function names. No one suggest that variable or function names should
  1094. be limited to 3-6
  1095. > > characters, because that would be insane. Why is it sane to limit
  1096. assembler mnemonics?
  1097. >
  1098. > uhm... still not seeing you over in the RISC-V universe
  1099. >
  1100. > but hey... keep whining down the /dev/null device here
  1101.  
  1102. What? I have no association with RISC V. If I was to make a drive-by
  1103. complaint there about anything, I would likely just annoy people there
  1104. trying to get something useful done. At worst someone would do exactly the
  1105. opposite than what that idiot n00b blathered about.
  1106.  
  1107. I was commenting in general about assembler tradition that I find
  1108. unsuitable for modern world (as far as I'm aware, the problem is
  1109. universal, but I only see x64 and ARM64 these days and have passing
  1110. familiarity with MIPS and PowerPC).
  1111.  
  1112. -JLarja
  1113.  
  1114. By: -.- ([email protected]), March 10, 2022 8:47 pm
  1115. Room: [25]Moderated Discussions
  1116. Anon ([email protected]) on March 9, 2022 6:33 pm wrote:
  1117. > Yeah, but most instructions are just variations and ISAs usually have a
  1118. standard way to describe
  1119. > the variations, even when the ISA is a mess like x86, ADDPS, the "P"
  1120. means packed, for more
  1121. > or less a thousand instructions, the last "S" means single, I see no
  1122. point in writing the
  1123. > full meaning of those suffixes, the start of the instruction, which
  1124. contains the actual instrcution
  1125. > name, usually get a good share of letters to describe it, like INSERTPS.
  1126.  
  1127. I think 'add' is quite well established, so more descriptive opcodes
  1128. wouldn't really help much here - it's more beneficial for less obvious
  1129. instructions.
  1130. Even so, I doubt 'ADD_PS' would've been that much of an ask, to separate
  1131. the operation from the type, or better still, 'ADD_PF32' or 'ADD_P_F32'
  1132. (since they use 'packed' instead of 'vector' mnemonic). Being more
  1133. consistent (what you refer to as the 'standard way') could also help (e.g.
  1134. don't switch between ordering/formatting like ADDPS for float32, but PADDD
  1135. for int32).
  1136.  
  1137. Expanding the name doesn't mean contractions aren't allowed, it's just
  1138. that a lot of instructions are almost deliberately named to appear
  1139. cryptic.
  1140.  
  1141. As for your other example, INSERTPS isn't too bad, whilst the integer
  1142. equivalent, PINSRD, is what I'd say falls into the 'less obvious'
  1143. category.
  1144.  
  1145. By: Anon ([email protected]), March 10, 2022 9:40 pm
  1146. Room: [25]Moderated Discussions
  1147. -.- ([email protected]) on March 10, 2022 7:47 pm wrote:
  1148. > I think 'add' is quite well established, so more descriptive opcodes
  1149. wouldn't
  1150. > really help much here - it's more beneficial for less obvious
  1151. instructions.
  1152. > Even so, I doubt 'ADD_PS' would've been that much of an ask, to separate
  1153. the operation from the
  1154. > type, or better still, 'ADD_PF32' or 'ADD_P_F32' (since they use
  1155. 'packed' instead of 'vector'
  1156. > mnemonic). Being more consistent (what you refer to as the 'standard
  1157. way') could also help (e.g.
  1158. > don't switch between ordering/formatting like ADDPS for float32, but
  1159. PADDD for int32).
  1160.  
  1161. I agree, others use a dot as separator.
  1162.  
  1163. > As for your other example, INSERTPS isn't too bad, whilst the integer
  1164. equivalent,
  1165. > PINSRD, is what I'd say falls into the 'less obvious' category.
  1166.  
  1167. I agree, MMX was the first SIMD extension, I think Intel only realized the
  1168. dumb naming convention after it.
  1169.  
  1170. By: gallier2 ([email protected]), March 11, 2022 12:34 am
  1171. Room: [25]Moderated Discussions
  1172. -.- ([email protected]) on March 10, 2022 7:47 pm wrote:
  1173. > Anon ([email protected]) on March 9, 2022 6:33 pm wrote:
  1174. > > Yeah, but most instructions are just variations and ISAs usually have
  1175. a standard way to describe
  1176. > > the variations, even when the ISA is a mess like x86, ADDPS, the "P"
  1177. means packed, for more
  1178. > > or less a thousand instructions, the last "S" means single, I see no
  1179. point in writing the
  1180. > > full meaning of those suffixes, the start of the instruction, which
  1181. contains the actual instrcution
  1182. > > name, usually get a good share of letters to describe it, like
  1183. INSERTPS.
  1184. >
  1185. > I think 'add' is quite well established, so more descriptive opcodes
  1186. wouldn't
  1187.  
  1188. A on the TMS-9900 :-)
  1189.  
  1190. > really help much here - it's more beneficial for less obvious
  1191. instructions.
  1192. > Even so, I doubt 'ADD_PS' would've been that much of an ask, to separate
  1193. the operation from the
  1194. > type, or better still, 'ADD_PF32' or 'ADD_P_F32' (since they use
  1195. 'packed' instead of 'vector'
  1196. > mnemonic). Being more consistent (what you refer to as the 'standard
  1197. way') could also help (e.g.
  1198. > don't switch between ordering/formatting like ADDPS for float32, but
  1199. PADDD for int32).
  1200. >
  1201. > Expanding the name doesn't mean contractions aren't allowed, it's just
  1202. that
  1203. > a lot of instructions are almost deliberately named to appear cryptic.
  1204. >
  1205. > As for your other example, INSERTPS isn't too bad, whilst the integer
  1206. equivalent,
  1207. > PINSRD, is what I'd say falls into the 'less obvious' category.
  1208.  
  1209. By: Tim ([email protected]), March 11, 2022 11:56 am
  1210. Room: [25]Moderated Discussions
  1211. I always wanted my assembly (and I have written a fair amount, although
  1212. not much lately) to be
  1213. closer to a high level language. Instead of
  1214.  
  1215. ADD R1,R2
  1216.  
  1217. Which could be "add r1 to r2", or "add R2 to R1" depending on the
  1218. assembler, just write:
  1219.  
  1220. R1 += R2
  1221.  
  1222. For a load:
  1223.  
  1224. R1 = [R1+offset]
  1225.  
  1226. and so on.
  1227.  
  1228. For the more complex things (add packed single), a simple algebraic
  1229. statement is not going
  1230. to work, so make it a function call like syntax:
  1231.  
  1232. R1 = add_packed_single(R1, R2)
  1233.  
  1234. Of course there are limitations on what is semantically allowed, but if
  1235. somebody wants to write:
  1236.  
  1237. R3 = add_packed_single(R1, R2)
  1238.  
  1239. The assembler *could* be smart enough to move R1 to R3 first, then do the
  1240. add.
  1241.  
  1242. The result is something that is still as efficient and low level as
  1243. assembler (still pretty
  1244. much one instruction per statement), but readable by programmers that are
  1245. familiar with C like
  1246. languages.
  1247.  
  1248. By: Anon ([email protected]), March 11, 2022 12:25 pm
  1249. Room: [25]Moderated Discussions
  1250. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  1251. > I always wanted my assembly (and I have written a fair amount, although
  1252. not much lately) to be
  1253. > closer to a high level language. Instead of
  1254. >
  1255. > ADD R1,R2
  1256. >
  1257. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  1258. assembler, just write:
  1259. >
  1260. > R1 += R2
  1261. >
  1262. > For a load:
  1263. >
  1264. > R1 = [R1+offset]
  1265. >
  1266. > and so on.
  1267. >
  1268. > For the more complex things (add packed single), a simple algebraic
  1269. statement is not going
  1270. > to work, so make it a function call like syntax:
  1271. >
  1272. > R1 = add_packed_single(R1, R2)
  1273. >
  1274. > Of course there are limitations on what is semantically allowed, but if
  1275. somebody wants to write:
  1276. >
  1277. > R3 = add_packed_single(R1, R2)
  1278. >
  1279. > The assembler *could* be smart enough to move R1 to R3 first, then do
  1280. the add.
  1281. >
  1282. > The result is something that is still as efficient and low level as
  1283. assembler (still pretty
  1284. > much one instruction per statement), but readable by programmers that
  1285. are familiar with C like
  1286. > languages.
  1287.  
  1288. You are not the first to thing about it.
  1289.  
  1290. IBM have HLAsm, there was a hobby HLA for x86 but, as far as I know, isn't
  1291. supported anymore, Microsoft have Macro Assembler which is quite powerful,
  1292. I have seem people write macros that expand things like R1 = R2 * R3 + R4
  1293. * R5 - R6 into assembly instructions, and macros that help OOP, but no
  1294. macro library is much used.
  1295.  
  1296. The problem is that nobody uses assembly to do things that compilers do so
  1297. well, so expanding a math expression may looks cool but is not that
  1298. usefull, assembly usually is used when there is a need for many
  1299. instructions that the compiler can't emit, and often when intrinsics
  1300. aren't an option, in those cases macro libraries add complexity without
  1301. giving much help in the solution.
  1302.  
  1303. By: Joern Engel ([email protected]), March 11, 2022 1:04
  1304. pm
  1305. Room: [25]Moderated Discussions
  1306. Anon ([email protected]) on March 11, 2022 11:25 am wrote:
  1307. >
  1308. > The problem is that nobody uses assembly to do things that compilers do
  1309. so well, so expanding a
  1310. > math expression may looks cool but is not that usefull, assembly usually
  1311. is used when there is
  1312. > a need for many instructions that the compiler can't emit, and often
  1313. when intrinsics aren't an
  1314. > option, in those cases macro libraries add complexity without giving
  1315. much help in the solution.
  1316.  
  1317. And in my experience, when you need close to all available registers and
  1318. compilers generate a pig's breakfast. On x86 that happens fairly often if
  1319. you need 8 accumulators for some compute kernel, plus some pointers, loop
  1320. counters, etc. Usually that still fits in the available 16 registers. But
  1321. compilers tend to need more registers than humans would and start spilling
  1322. onto the stack. And then they make bad decisions and spill hot variables
  1323. while keeping cold variables in registers. In a recent example,
  1324. compiler-generated code was 60% larger and 60% slower than necessary.
  1325.  
  1326. It is fairly rare that a) this happens and b) it matters enough to replace
  1327. the compiler-generated code with hand-written assembly. But it does come
  1328. up from time to time.
  1329.  
  1330. By: Mark Roulo ([email protected]), March 11, 2022 12:26 pm
  1331. Room: [25]Moderated Discussions
  1332. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  1333. > I always wanted my assembly (and I have written a fair amount, although
  1334. not much lately) to be
  1335. > closer to a high level language. Instead of
  1336. >
  1337. > ADD R1,R2
  1338. >
  1339. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  1340. assembler, just write:
  1341. >
  1342. > R1 += R2
  1343. >
  1344. > For a load:
  1345. >
  1346. > R1 = [R1+offset]
  1347. >
  1348. > and so on.
  1349. >
  1350. > For the more complex things (add packed single), a simple algebraic
  1351. statement is not going
  1352. > to work, so make it a function call like syntax:
  1353. >
  1354. > R1 = add_packed_single(R1, R2)
  1355. >
  1356. > Of course there are limitations on what is semantically allowed, but if
  1357. somebody wants to write:
  1358. >
  1359. > R3 = add_packed_single(R1, R2)
  1360. >
  1361. > The assembler *could* be smart enough to move R1 to R3 first, then do
  1362. the add.
  1363. >
  1364. > The result is something that is still as efficient and low level as
  1365. assembler (still pretty
  1366. > much one instruction per statement), but readable by programmers that
  1367. are familiar with C like
  1368. > languages.
  1369.  
  1370. Me, too!
  1371.  
  1372. But I read assembly (and rarely at that) but I don't *write* it.
  1373.  
  1374. Maybe there are good reasons that we don't get this (other than
  1375. "historically, we haven't done this")? The obvious problem might be that
  1376. many instructions don't have good mappings to higher level constructs. As
  1377. an example, the x86 test instruction seems to:
  1378. *) do a bitwise and (not a problem), and
  1379. *) set the ZF flag resister to the result (0 or 1)
  1380. *) set the SF flag resister to the value of the sign bit (0 or 1)
  1381. *) set the PF flag register to the parity of the result
  1382. *) clear the CF flag register
  1383.  
  1384. So we can't do: r1 = r2 and r3
  1385.  
  1386. I expect that ARM instructions aren't as annoying as this, but maybe there
  1387. are enough of these sorts of cases that the simplification you (and I)
  1388. want doesn't really help very much?
  1389.  
  1390. By: David Hess ([email protected]), March 12, 2022 11:39 am
  1391. Room: [25]Moderated Discussions
  1392. Mark Roulo ([email protected]) on March 11, 2022 11:26 am
  1393. wrote:
  1394. > Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  1395. > > I always wanted my assembly (and I have written a fair amount,
  1396. although not much lately) to be
  1397. > > closer to a high level language. Instead of
  1398. > >
  1399. > > ADD R1,R2
  1400. > >
  1401. > > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  1402. assembler, just write:
  1403. > >
  1404. > > R1 += R2
  1405. > >
  1406. > > For a load:
  1407. > >
  1408. > > R1 = [R1+offset]
  1409. > >
  1410. > > and so on.
  1411. > >
  1412. > > For the more complex things (add packed single), a simple algebraic
  1413. statement is not going
  1414. > > to work, so make it a function call like syntax:
  1415. > >
  1416. > > R1 = add_packed_single(R1, R2)
  1417. > >
  1418. > > Of course there are limitations on what is semantically allowed, but
  1419. if somebody wants to write:
  1420. > >
  1421. > > R3 = add_packed_single(R1, R2)
  1422. > >
  1423. > > The assembler *could* be smart enough to move R1 to R3 first, then do
  1424. the add.
  1425. > >
  1426. > > The result is something that is still as efficient and low level as
  1427. assembler (still pretty
  1428. > > much one instruction per statement), but readable by programmers that
  1429. are familiar with C like
  1430. > > languages.
  1431. >
  1432. > Me, too!
  1433. >
  1434. > But I read assembly (and rarely at that) but I don't *write* it.
  1435. >
  1436. > Maybe there are good reasons that we don't get this (other than
  1437. "historically, we haven't
  1438. > done this")? The obvious problem might be that many instructions don't
  1439. have good mappings
  1440. > to higher level constructs. As an example, the x86 test instruction
  1441. seems to:
  1442. > *) do a bitwise and (not a problem), and
  1443. > *) set the ZF flag resister to the result (0 or 1)
  1444. > *) set the SF flag resister to the value of the sign bit (0 or 1)
  1445. > *) set the PF flag register to the parity of the result
  1446. > *) clear the CF flag register
  1447. >
  1448. > So we can't do: r1 = r2 and r3
  1449. >
  1450. > I expect that ARM instructions aren't as annoying as this, but maybe
  1451. there are enough of these
  1452. > sorts of cases that the simplification you (and I) want doesn't really
  1453. help very much?
  1454.  
  1455. Even ADD usually has a variation which includes carry, and assuming the
  1456. ADD width from the operands is not always unambiguous. Even x86 assembly
  1457. required an extra notation to handle that, while 8080 did not. I do not
  1458. remember now how Z80 handled it; Z80 used different mnemonics than 8080
  1459. and must have determined context like x86.
  1460.  
  1461. Macro assemblers solved these problems long ago but perhaps not in the way
  1462. modern programmers are used to. From my perspective of an assembly
  1463. programmer, I could list similar problems with C notation, and in the past
  1464. some non-standard specialized C compilers addressed issues like this.
  1465.  
  1466. By: Adrian ([email protected]), March 12, 2022 12:01 pm
  1467. Room: [25]Moderated Discussions
  1468. David Hess ([email protected]) on March 12, 2022 10:39 am
  1469. wrote:
  1470. >
  1471. > Even ADD usually has a variation which includes carry, and assuming the
  1472. ADD width from
  1473. > the operands is not always unambiguous. Even x86 assembly required an
  1474. extra notation
  1475. > to handle that, while 8080 did not. I do not remember now how Z80
  1476. handled it; Z80
  1477. > used different mnemonics than 8080 and must have determined context like
  1478. x86.
  1479. >
  1480. > Macro assemblers solved these problems long ago but perhaps not in the
  1481. way modern programmers are
  1482. > used to. From my perspective of an assembly programmer, I could list
  1483. similar problems with C notation,
  1484. > and in the past some non-standard specialized C compilers addressed
  1485. issues like this.
  1486. >
  1487.  
  1488. In an assembly language that does not use the traditional assembly
  1489. instruction format, but it uses expressions, like e.g. in C, you need more
  1490. operators, to cover all the operations that are possible between operands
  1491. of a given type.
  1492.  
  1493. Those operators may use keywords, like the mnemonics of a traditional
  1494. language, e.g. ADD and ADC, or, in a programming language that accepts
  1495. Unicode source files, like any modern programming language should, in my
  1496. opinion, then there are plenty of symbols available for operators, e.g.
  1497. one could use "+" for ADD and "+" in a circle for ADC.
  1498.  
  1499. Actually such a notation is not new, it was used in the documentation of
  1500. various CPUs, in the past.
  1501.  
  1502. By: Mark Roulo ([email protected]), March 12, 2022 7:12 pm
  1503. Room: [25]Moderated Discussions
  1504. Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1505. > Those operators may use keywords, like the mnemonics of a traditional
  1506. language, e.g.
  1507. > ADD and ADC, or, in a programming language that accepts Unicode source
  1508. files, like any
  1509. > modern programming language should, in my opinion, then
  1510.  
  1511. there are plenty of symbols available
  1512. > for operators, e.g. one could use "+" for ADD and "+" in a circle for
  1513. ADC.
  1514. >
  1515. > Actually such a notation is not new, it was used in the documentation
  1516. of various CPUs, in the past.
  1517. >
  1518.  
  1519. If APL and assembly language had a baby ...
  1520.  
  1521. By: Adrian ([email protected]), March 13, 2022 1:38 am
  1522. Room: [25]Moderated Discussions
  1523. Mark Roulo ([email protected]) on March 12, 2022 6:12 pm wrote:
  1524. > Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1525. > > Those operators may use keywords, like the mnemonics of a traditional
  1526. language, e.g.
  1527. > > ADD and ADC, or, in a programming language that accepts Unicode source
  1528. files, like any
  1529. > > modern programming language should, in my opinion, then
  1530.  
  1531. there are plenty of symbols available
  1532. > > for operators, e.g. one could use "+" for ADD and "+" in a circle
  1533. for ADC.
  1534. > >
  1535. > > Actually such a notation is not new, it was used in the
  1536. documentation of various CPUs, in the past.
  1537. > >
  1538. >
  1539. > If APL and assembly language had a baby ...
  1540. >
  1541. >
  1542.  
  1543. I assume that you allude to "A formal description of SYSTEM/360",
  1544. created at IBM in 1964 by Falkoff, Iverson & Sussenguth, which can be
  1545. considered as such a baby (even if it predates both the first computer
  1546. implementation of APL, APL360, and the coining of the acronym APL for
  1547. the Iverson notation).
  1548.  
  1549. By: Mark Roulo ([email protected]), March 13, 2022 8:53 am
  1550. Room: [25]Moderated Discussions
  1551. Adrian ([email protected]) on March 13, 2022 1:38 am wrote:
  1552. > Mark Roulo ([email protected]) on March 12, 2022 6:12 pm
  1553. wrote:
  1554. > > Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1555. > > > Those operators may use keywords, like the mnemonics of a
  1556. traditional language, e.g.
  1557. > > > ADD and ADC, or, in a programming language that accepts Unicode
  1558. source files, like any
  1559. > > > modern programming language should, in my opinion, then
  1560.  
  1561. there are plenty of symbols available
  1562. > > > for operators, e.g. one could use "+" for ADD and "+" in a circle
  1563. for ADC.
  1564. > > >
  1565. > > > Actually such a notation is not new, it was used in the
  1566. documentation of various CPUs, in the past.
  1567. > > >
  1568. > >
  1569. > > If APL and assembly language had a baby ...
  1570. > >
  1571. > >
  1572. >
  1573. >
  1574. > I assume that you allude to "A formal description of SYSTEM/360",
  1575. created at IBM in 1964 by Falkoff,
  1576. > Iverson & Sussenguth, which can be considered as such a baby (even if
  1577. it predates both the first computer
  1578. > implementation of APL, APL360, and the coining of the acronym APL for
  1579. the Iverson notation).
  1580. >
  1581.  
  1582. I was referring to how I would view things if (an) assembly language
  1583. began to use Unicode extensively (for example a '+' inside a circle
  1584. to indicate add-with-carry).
  1585.  
  1586. By: Adrian ([email protected]), March 13, 2022 10:57 am
  1587. Room: [25]Moderated Discussions
  1588. Mark Roulo ([email protected]) on March 13, 2022 8:53 am wrote:
  1589. > Adrian ([email protected]) on March 13, 2022 1:38 am wrote:
  1590. > > Mark Roulo ([email protected]) on March 12, 2022 6:12 pm
  1591. wrote:
  1592. > > > Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1593. > > > > Those operators may use keywords, like the mnemonics of a
  1594. traditional language, e.g.
  1595. > > > > ADD and ADC, or, in a programming language that accepts Unicode
  1596. source files, like any
  1597. > > > > modern programming language should, in my opinion, then
  1598.  
  1599. there are plenty of symbols available
  1600. > > > > for operators, e.g. one could use "+" for ADD and "+" in a
  1601. circle for ADC.
  1602. > > > >
  1603. > > > > Actually such a notation is not new, it was used in the
  1604. documentation of various CPUs, in the past.
  1605. > > > >
  1606. > > >
  1607. > > > If APL and assembly language had a baby ...
  1608. > > >
  1609. > > >
  1610. > >
  1611. > >
  1612. > > I assume that you allude to "A formal description of SYSTEM/360",
  1613. created at IBM in 1964 by Falkoff,
  1614. > > Iverson & Sussenguth, which can be considered as such a baby (even
  1615. if it predates both the first computer
  1616. > > implementation of APL, APL360, and the coining of the acronym APL
  1617. for the Iverson notation).
  1618. > >
  1619. >
  1620. > I was referring to how I would view things if (an) assembly language
  1621. > began to use Unicode extensively (for example a '+' inside a circle
  1622. > to indicate add-with-carry).
  1623. >
  1624. >
  1625.  
  1626. Even if Unicode did not exist in 1964, this exactly what that formal
  1627. description of IBM System/360 was.
  1628.  
  1629. It was a method to write any IBM System/360 program, which used an
  1630. APL-based language, which was written with a large number of different
  1631. symbolic operators that had an unambiguous meaning.
  1632.  
  1633. In order to be able to describe in detail the semantics of the
  1634. System/360 ISA and the behavior of its peripherals, the APL operators
  1635. were used for a lower level than the assembly language. They
  1636. corresponded with the microinstructions of an ideal machine, which would
  1637. interpret the System/360 instructions.
  1638.  
  1639. Nevertheless, it would have been trivial to extend that APL notation to
  1640. write directly any assembly language program, instead of the equivalent
  1641. microprogram.
  1642.  
  1643. However, IBM has always been extremely reluctant to provide on its
  1644. products character sets with enough characters. Therefore an assembly
  1645. language notation with a large number of symbols was OK in a research
  1646. project, but it would have never been approved for a commercial product.
  1647.  
  1648. By: rwessel ([email protected]), March 13, 2022 11:23 am
  1649. Room: [25]Moderated Discussions
  1650. Adrian ([email protected]) on March 13, 2022 10:57 am wrote:
  1651. > Mark Roulo ([email protected]) on March 13, 2022 8:53 am
  1652. wrote:
  1653. > > Adrian ([email protected]) on March 13, 2022 1:38 am wrote:
  1654. > > > Mark Roulo ([email protected]) on March 12, 2022 6:12 pm
  1655. wrote:
  1656. > > > > Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1657. > > > > > Those operators may use keywords, like the mnemonics of a
  1658. traditional language, e.g.
  1659. > > > > > ADD and ADC, or, in a programming language that accepts Unicode
  1660. source files, like any
  1661. > > > > > modern programming language should, in my opinion, then
  1662.  
  1663. there are plenty of symbols available
  1664. > > > > > for operators, e.g. one could use "+" for ADD and "+" in a
  1665. circle for ADC.
  1666. > > > > >
  1667. > > > > > Actually such a notation is not new, it was used in the
  1668. documentation of various CPUs, in the past.
  1669. > > > > >
  1670. > > > >
  1671. > > > > If APL and assembly language had a baby ...
  1672. > > > >
  1673. > > > >
  1674. > > >
  1675. > > >
  1676. > > > I assume that you allude to "A formal description of SYSTEM/360",
  1677. created at IBM in 1964 by Falkoff,
  1678. > > > Iverson & Sussenguth, which can be considered as such a baby (even
  1679. if it predates both the first computer
  1680. > > > implementation of APL, APL360, and the coining of the acronym APL
  1681. for the Iverson notation).
  1682. > > >
  1683. > >
  1684. > > I was referring to how I would view things if (an) assembly language
  1685. > > began to use Unicode extensively (for example a '+' inside a circle
  1686. > > to indicate add-with-carry).
  1687. > >
  1688. > >
  1689. >
  1690. >
  1691. > Even if Unicode did not exist in 1964, this exactly what that formal
  1692. description of IBM System/360 was.
  1693. >
  1694. > It was a method to write any IBM System/360 program, which used an
  1695. APL-based language, which was
  1696. > written with a large number of different symbolic operators that had
  1697. an unambiguous meaning.
  1698. >
  1699. > In order to be able to describe in detail the semantics of the
  1700. System/360 ISA and the behavior of its
  1701. > peripherals, the APL operators were used for a lower level than the
  1702. assembly language. They corresponded
  1703. > with the microinstructions of an ideal machine, which would interpret
  1704. the System/360 instructions.
  1705. >
  1706. > Nevertheless, it would have been trivial to extend that APL notation
  1707. to write directly
  1708. > any assembly language program, instead of the equivalent microprogram.
  1709. >
  1710. > However, IBM has always been extremely reluctant to provide on its
  1711. products character sets with
  1712. > enough characters. Therefore an assembly language notation with a
  1713. large number of symbols was
  1714. > OK in a research project, but it would have never been approved for a
  1715. commercial product.
  1716.  
  1717. I'm not sure that's quite fair. At the time, expanded character sets
  1718. tended to be costly - slower print trains, more costly character
  1719. generators on early terminals, etc. And much programming took place on
  1720. devices designed for "normal" data (eg. keypunches), and were limited to
  1721. character sets provided by that hardware. Programming really being a
  1722. secondary task - these expensive devices being intended for data
  1723. progress. That was hardly unique to IBM, and many systems pre-360 used
  1724. 6-bit characters most of the time. While IBM (unfortunately) ended up
  1725. with EBCDIC for S/360, it's not like ASCII really moved the needle all
  1726. that far, providing only 95 printable characters.
  1727.  
  1728. IBM would have happily sold you a TN train* for your 1403 printer, and
  1729. then you'd get not only lower case letters but a bunch of new
  1730. punctuation marks, but than your 1403 will run at less than half speed.
  1731.  
  1732. *120 different printable characters (plus space).
  1733.  
  1734. By: Andrey ([email protected]), March 14, 2022 1:42 am
  1735. Room: [25]Moderated Discussions
  1736. Adrian ([email protected]) on March 13, 2022 10:57 am wrote:
  1737. > Mark Roulo ([email protected]) on March 13, 2022 8:53 am
  1738. wrote:
  1739. > > Adrian ([email protected]) on March 13, 2022 1:38 am wrote:
  1740. > > > Mark Roulo ([email protected]) on March 12, 2022 6:12 pm
  1741. wrote:
  1742. > > > > Adrian ([email protected]) on March 12, 2022 11:01 am wrote:
  1743. > > > > > Those operators may use keywords, like the mnemonics of a
  1744. traditional language, e.g.
  1745. > > > > > ADD and ADC, or, in a programming language that accepts Unicode
  1746. source files, like any
  1747. > > > > > modern programming language should, in my opinion, then
  1748.  
  1749. there are plenty of symbols available
  1750. > > > > > for operators, e.g. one could use "+" for ADD and "+" in a
  1751. circle for ADC.
  1752. > > > > >
  1753. > > > > > Actually such a notation is not new, it was used in the
  1754. documentation of various CPUs, in the past.
  1755. > > > > >
  1756. > > > >
  1757. > > > > If APL and assembly language had a baby ...
  1758. > > > >
  1759. > > > >
  1760. > > >
  1761. > > >
  1762. > > > I assume that you allude to "A formal description of SYSTEM/360",
  1763. created at IBM in 1964 by Falkoff,
  1764. > > > Iverson & Sussenguth, which can be considered as such a baby (even
  1765. if it predates both the first computer
  1766. > > > implementation of APL, APL360, and the coining of the acronym APL
  1767. for the Iverson notation).
  1768. > > >
  1769. > >
  1770. > > I was referring to how I would view things if (an) assembly language
  1771. > > began to use Unicode extensively (for example a '+' inside a circle
  1772. > > to indicate add-with-carry).
  1773. > >
  1774. > >
  1775. >
  1776. >
  1777. > Even if Unicode did not exist in 1964, this exactly what that formal
  1778. description of IBM System/360 was.
  1779. >
  1780. > It was a method to write any IBM System/360 program, which used an
  1781. APL-based language, which was
  1782. > written with a large number of different symbolic operators that had
  1783. an unambiguous meaning.
  1784. >
  1785. > In order to be able to describe in detail the semantics of the
  1786. System/360 ISA and the behavior of its
  1787. > peripherals, the APL operators were used for a lower level than the
  1788. assembly language. They corresponded
  1789. > with the microinstructions of an ideal machine, which would interpret
  1790. the System/360 instructions.
  1791. >
  1792. > Nevertheless, it would have been trivial to extend that APL notation
  1793. to write directly
  1794. > any assembly language program, instead of the equivalent microprogram.
  1795. >
  1796. > However, IBM has always been extremely reluctant to provide on its
  1797. products character sets with
  1798. > enough characters. Therefore an assembly language notation with a
  1799. large number of symbols was
  1800. > OK in a research project, but it would have never been approved for a
  1801. commercial product.
  1802.  
  1803. Even today, inputting Unicode characters outside ASCII and possibly one
  1804. national character set is a pain (and national characters typically
  1805. require switching keyboard layout, so they are also a pain, just a bit
  1806. less of a pain compared to opening some app to insert a special
  1807. character or using a compose sequence, or switching keyboard to a third
  1808. layer layout). Even ignoring the minimum bar for the system that is
  1809. capable to support programming with Unicode operations (the system would
  1810. have to support Unicode, there must be software or hardware support for
  1811. inputting non-ASCII characters), the amount of effort to input these
  1812. characters (on a conventional system with a PC keyboard) would be
  1813. unacceptable.
  1814.  
  1815. Then there is an issue of character discernability. This is not an issue
  1816. with something like a plus in a circle, but there are plenty of
  1817. different Unicode characters that look the same or alike. This is a huge
  1818. source of ambiguity and code obfuscation, both benign and malicious.
  1819.  
  1820. I strongly believe that programming languages should limit their code
  1821. character sets to ASCII (that is, Unicode may be supported in comments
  1822. and string literals, but not for operators, names, delimiters or
  1823. non-string literals).
  1824.  
  1825. By: Anon ([email protected]), March 14, 2022 1:57 am
  1826. Room: [25]Moderated Discussions
  1827. Andrey ([email protected]) on March 14, 2022 1:42 am
  1828. wrote:
  1829. > Even today, inputting Unicode characters outside ASCII and possibly one
  1830. national character set is a pain
  1831. > (and national characters typically require switching keyboard layout, so
  1832. they are also a pain, just a
  1833. > bit less of a pain compared to opening some app to insert a special
  1834. character or using a compose sequence,
  1835. > or switching keyboard to a third layer layout). Even ignoring the
  1836. minimum bar for the system that is
  1837. > capable to support programming with Unicode operations (the system would
  1838. have to support Unicode, there
  1839. > must be software or hardware support for inputting non-ASCII
  1840. characters), the amount of effort to input
  1841. > these characters (on a conventional system with a PC keyboard) would be
  1842. unacceptable.
  1843. >
  1844. > Then there is an issue of character discernability. This is not an issue
  1845. with something like
  1846. > a plus in a circle, but there are plenty of different Unicode characters
  1847. that look the same or
  1848. > alike. This is a huge source of ambiguity and code obfuscation, both
  1849. benign and malicious.
  1850. >
  1851. > I strongly believe that programming languages should limit their code
  1852. character
  1853. > sets to ASCII (that is, Unicode may be supported in comments and string
  1854. literals,
  1855. > but not for operators, names, delimiters or non-string literals).
  1856. >
  1857.  
  1858. I guess CJK writters already had and solved some of those problems, I am
  1859. not sure APL (and anyone else thinking about including more unicode
  1860. characters) programmers are a big enough group for someone to solve their
  1861. problem too.
  1862.  
  1863. By: Michael S ([email protected]), March 14, 2022 4:07
  1864. am
  1865. Room: [25]Moderated Discussions
  1866. Anon ([email protected]) on March 14, 2022 1:57 am wrote:
  1867. > Andrey ([email protected]) on March 14, 2022 1:42 am
  1868. wrote:
  1869. > > Even today, inputting Unicode characters outside ASCII and possibly
  1870. one national character set is a pain
  1871. > > (and national characters typically require switching keyboard layout,
  1872. so they are also a pain, just a
  1873. > > bit less of a pain compared to opening some app to insert a special
  1874. character or using a compose sequence,
  1875. > > or switching keyboard to a third layer layout). Even ignoring the
  1876. minimum bar for the system that is
  1877. > > capable to support programming with Unicode operations (the system
  1878. would have to support Unicode, there
  1879. > > must be software or hardware support for inputting non-ASCII
  1880. characters), the amount of effort to input
  1881. > > these characters (on a conventional system with a PC keyboard) would
  1882. be unacceptable.
  1883. > >
  1884. > > Then there is an issue of character discernability. This is not an
  1885. issue with something like
  1886. > > a plus in a circle, but there are plenty of different Unicode
  1887. characters that look the same or
  1888. > > alike. This is a huge source of ambiguity and code obfuscation, both
  1889. benign and malicious.
  1890. > >
  1891. > > I strongly believe that programming languages should limit their code
  1892. character
  1893. > > sets to ASCII (that is, Unicode may be supported in comments and
  1894. string literals,
  1895. > > but not for operators, names, delimiters or non-string literals).
  1896. > >
  1897. >
  1898. > I guess CJK writters already had and solved some of those problems, I am
  1899. not
  1900. > sure APL (and anyone else thinking about including more unicode
  1901. characters)
  1902. > programmers are a big enough group for someone to solve their problem
  1903. too.
  1904.  
  1905. C - yes.
  1906. But J (Hiragana) and K (Hangul) fall under "one national character set".
  1907. May be, they are no the most prestigious forms of writing J and K, but I
  1908. would think that they are most widely used on computers.
  1909.  
  1910. BTW, at home I have a keyboard marked with three character sets. It's pain
  1911. to use for one of them (hard to concentrate), but o.k. for the other two.
  1912. The fact that I am closer to blind typing on the those other two sets
  1913. certainly helps.
  1914.  
  1915. By: Michael S ([email protected]), March 13, 2022 8:14
  1916. am
  1917. Room: [25]Moderated Discussions
  1918. Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  1919. > David Hess ([email protected]) on March 12, 2022 10:39 am
  1920. wrote:
  1921. > >
  1922. > > Even ADD usually has a variation which includes carry, and assuming
  1923. the ADD width from
  1924. > > the operands is not always unambiguous. Even x86 assembly required an
  1925. extra notation
  1926. > > to handle that, while 8080 did not. I do not remember now how Z80
  1927. handled it; Z80
  1928. > > used different mnemonics than 8080 and must have determined context
  1929. like x86.
  1930. > >
  1931. > > Macro assemblers solved these problems long ago but perhaps not in the
  1932. way modern programmers are
  1933. > > used to. From my perspective of an assembly programmer, I could list
  1934. similar problems with C notation,
  1935. > > and in the past some non-standard specialized C compilers addressed
  1936. issues like this.
  1937. > >
  1938. >
  1939. >
  1940. > In an assembly language that does not use the traditional assembly
  1941. instruction
  1942. > format, but it uses expressions, like e.g. in C, you need more
  1943. operators, to cover
  1944. > all the operations that are possible between operands of a given type.
  1945. >
  1946. > Those operators may use keywords, like the mnemonics of a traditional
  1947. language, e.g.
  1948. > ADD and ADC, or, in a programming language that accepts Unicode source
  1949. files, like any
  1950. > modern programming language should, in my opinion, then there are plenty
  1951. of symbols available
  1952. > for operators, e.g. one could use "+" for ADD and "+" in a circle for
  1953. ADC.
  1954. >
  1955. > Actually such a notation is not new, it was used in the documentation of
  1956. various CPUs, in the past.
  1957. >
  1958.  
  1959. What's wrong with "R1=R2+R3+CarryFlag" ?
  1960.  
  1961. By: Michael S ([email protected]), March 13, 2022 8:27
  1962. am
  1963. Room: [25]Moderated Discussions
  1964. Michael S ([email protected]) on March 13, 2022 8:14 am
  1965. wrote:
  1966. > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  1967. > > David Hess ([email protected]) on March 12, 2022 10:39
  1968. am wrote:
  1969. > > >
  1970. > > > Even ADD usually has a variation which includes carry, and assuming
  1971. the ADD width from
  1972. > > > the operands is not always unambiguous. Even x86 assembly required
  1973. an extra notation
  1974. > > > to handle that, while 8080 did not. I do not remember now how Z80
  1975. handled it; Z80
  1976. > > > used different mnemonics than 8080 and must have determined context
  1977. like x86.
  1978. > > >
  1979. > > > Macro assemblers solved these problems long ago but perhaps not in
  1980. the way modern programmers are
  1981. > > > used to. From my perspective of an assembly programmer, I could list
  1982. similar problems with C notation,
  1983. > > > and in the past some non-standard specialized C compilers addressed
  1984. issues like this.
  1985. > > >
  1986. > >
  1987. > >
  1988. > > In an assembly language that does not use the traditional assembly
  1989. instruction
  1990. > > format, but it uses expressions, like e.g. in C, you need more
  1991. operators, to cover
  1992. > > all the operations that are possible between operands of a given type.
  1993. > >
  1994. > > Those operators may use keywords, like the mnemonics of a traditional
  1995. language, e.g.
  1996. > > ADD and ADC, or, in a programming language that accepts Unicode source
  1997. files, like any
  1998. > > modern programming language should, in my opinion, then there are
  1999. plenty of symbols available
  2000. > > for operators, e.g. one could use "+" for ADD and "+" in a circle for
  2001. ADC.
  2002. > >
  2003. > > Actually such a notation is not new, it was used in the documentation
  2004. of various CPUs, in the past.
  2005. > >
  2006. >
  2007. > What's wrong with "R1=R2+R3+CarryFlag" ?
  2008. >
  2009.  
  2010. BTW, that almost exactly the syntax of ADI SHARC and TigerSHARC asm.
  2011. Except that they use CI instead of CarryFlag.
  2012.  
  2013. By: Adrian ([email protected]), March 13, 2022 10:29 am
  2014. Room: [25]Moderated Discussions
  2015. Michael S ([email protected]) on March 13, 2022 8:14 am
  2016. wrote:
  2017. > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  2018. > > David Hess ([email protected]) on March 12, 2022 10:39
  2019. am wrote:
  2020. > > >
  2021. > > > Even ADD usually has a variation which includes carry, and assuming
  2022. the ADD width from
  2023. > > > the operands is not always unambiguous. Even x86 assembly required
  2024. an extra notation
  2025. > > > to handle that, while 8080 did not. I do not remember now how Z80
  2026. handled it; Z80
  2027. > > > used different mnemonics than 8080 and must have determined context
  2028. like x86.
  2029. > > >
  2030. > > > Macro assemblers solved these problems long ago but perhaps not in
  2031. the way modern programmers are
  2032. > > > used to. From my perspective of an assembly programmer, I could list
  2033. similar problems with C notation,
  2034. > > > and in the past some non-standard specialized C compilers addressed
  2035. issues like this.
  2036. > > >
  2037. > >
  2038. > >
  2039. > > In an assembly language that does not use the traditional assembly
  2040. instruction
  2041. > > format, but it uses expressions, like e.g. in C, you need more
  2042. operators, to cover
  2043. > > all the operations that are possible between operands of a given type.
  2044. > >
  2045. > > Those operators may use keywords, like the mnemonics of a traditional
  2046. language, e.g.
  2047. > > ADD and ADC, or, in a programming language that accepts Unicode source
  2048. files, like any
  2049. > > modern programming language should, in my opinion, then there are
  2050. plenty of symbols available
  2051. > > for operators, e.g. one could use "+" for ADD and "+" in a circle for
  2052. ADC.
  2053. > >
  2054. > > Actually such a notation is not new, it was used in the documentation
  2055. of various CPUs, in the past.
  2056. > >
  2057. >
  2058. > What's wrong with "R1=R2+R3+CarryFlag" ?
  2059. >
  2060.  
  2061. There is nothing wrong with it.
  2062. It is one alternative.
  2063.  
  2064. In any case, someone who designs a new assembly language must make a
  2065. choice, but then that choice should be used always, in a consistent way,
  2066. i.e. either the number of operators/mnemonics for the relevant operations
  2067. should be doubled, or an explicit carry operand should be written, to be
  2068. able to distinguish operations like ADD vs. ADC or ROL vs. RCL.
  2069.  
  2070. By: David Hess ([email protected]), March 13, 2022 2:54 pm
  2071. Room: [25]Moderated Discussions
  2072. Michael S ([email protected]) on March 13, 2022 8:14 am
  2073. wrote:
  2074. >
  2075. > What's wrong with "R1=R2+R3+CarryFlag" ?
  2076.  
  2077. I have occasionally seen that, but I do not remember if any of the
  2078. specialized C compilers used it.
  2079.  
  2080. By: Michael S ([email protected]), March 13, 2022 3:09
  2081. pm
  2082. Room: [25]Moderated Discussions
  2083. David Hess ([email protected]) on March 13, 2022 2:54 pm
  2084. wrote:
  2085. > Michael S ([email protected]) on March 13, 2022 8:14
  2086. am wrote:
  2087. > >
  2088. > > What's wrong with "R1=R2+R3+CarryFlag" ?
  2089. >
  2090. > I have occasionally seen that, but I do not remember if any of the
  2091. specialized C compilers used it.
  2092. >
  2093.  
  2094. That's asm, not a specialized C.
  2095. See the followup.
  2096. Or read page 478.
  2097. [26]https://www.analog.com/media/en/dsp-documentation/processor-manuals/34605284816196ts201_pgr.pdf
  2098.  
  2099. By: Andrey ([email protected]), March 14, 2022 1:27 am
  2100. Room: [25]Moderated Discussions
  2101. Michael S ([email protected]) on March 13, 2022 8:14 am
  2102. wrote:
  2103. > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  2104. > > David Hess ([email protected]) on March 12, 2022 10:39
  2105. am wrote:
  2106. > > >
  2107. > > > Even ADD usually has a variation which includes carry, and assuming
  2108. the ADD width from
  2109. > > > the operands is not always unambiguous. Even x86 assembly required
  2110. an extra notation
  2111. > > > to handle that, while 8080 did not. I do not remember now how Z80
  2112. handled it; Z80
  2113. > > > used different mnemonics than 8080 and must have determined context
  2114. like x86.
  2115. > > >
  2116. > > > Macro assemblers solved these problems long ago but perhaps not in
  2117. the way modern programmers are
  2118. > > > used to. From my perspective of an assembly programmer, I could list
  2119. similar problems with C notation,
  2120. > > > and in the past some non-standard specialized C compilers addressed
  2121. issues like this.
  2122. > > >
  2123. > >
  2124. > >
  2125. > > In an assembly language that does not use the traditional assembly
  2126. instruction
  2127. > > format, but it uses expressions, like e.g. in C, you need more
  2128. operators, to cover
  2129. > > all the operations that are possible between operands of a given type.
  2130. > >
  2131. > > Those operators may use keywords, like the mnemonics of a traditional
  2132. language, e.g.
  2133. > > ADD and ADC, or, in a programming language that accepts Unicode source
  2134. files, like any
  2135. > > modern programming language should, in my opinion, then there are
  2136. plenty of symbols available
  2137. > > for operators, e.g. one could use "+" for ADD and "+" in a circle for
  2138. ADC.
  2139. > >
  2140. > > Actually such a notation is not new, it was used in the documentation
  2141. of various CPUs, in the past.
  2142. > >
  2143. >
  2144. > What's wrong with "R1=R2+R3+CarryFlag" ?
  2145.  
  2146. The problem with it is I can see three operations in this notation, while
  2147. there's supposed to be a single instruction for it. There is an ambiguity
  2148. as to how this notation is translated into instructions, unless you
  2149. hardcode in specification the correspondence between exact expressions and
  2150. machine instructions. And at that point, how is it better than the
  2151. instruction mnemonics we use today?
  2152.  
  2153. Also, unless you put restrictions on the expressions and their
  2154. interpretation, there is an ambiguity on the result of this expression.
  2155. Integer addition is transitive, so should the compiler interpret it as
  2156. "R1=(R2+R3)+CarryFlag" or "R1=R2+(R3+CarryFlag)"? If you put the
  2157. requirement to interpret the expression left-to-right then what about
  2158. "R1=CarryFlag+R2+R3"? Next you put the requirement that CarryFlag must go
  2159. last, but then how is it better than "adc R2, R3, R1"? Also, if your
  2160. target ISA does not support non-destructive instructions, you will have an
  2161. ambiguity with "R1=R2+R3" as the compiler will have to either insert a
  2162. move instruction or reject this expression, while this is naturally solved
  2163. by instruction mnemonics, which would only support two operands.
  2164.  
  2165. Instruction mnemonics are better because they are not ambiguous like that.
  2166. From the programmer's perspective, they provide the minimum granularity of
  2167. operations performed by the machine. This is not only important from the
  2168. program interpretation standpoint, but also the definition of the program
  2169. state at the point of interruption, and visibility of operation effects to
  2170. other CPUs and devices.
  2171.  
  2172. By: Michael S ([email protected]), March 14, 2022 3:08
  2173. am
  2174. Room: [25]Moderated Discussions
  2175. Andrey ([email protected]) on March 14, 2022 1:27 am
  2176. wrote:
  2177. > Michael S ([email protected]) on March 13, 2022 8:14
  2178. am wrote:
  2179. > > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  2180. > > > David Hess ([email protected]) on March 12, 2022
  2181. 10:39 am wrote:
  2182. > > > >
  2183. > > > > Even ADD usually has a variation which includes carry, and
  2184. assuming the ADD width from
  2185. > > > > the operands is not always unambiguous. Even x86 assembly required
  2186. an extra notation
  2187. > > > > to handle that, while 8080 did not. I do not remember now how Z80
  2188. handled it; Z80
  2189. > > > > used different mnemonics than 8080 and must have determined
  2190. context like x86.
  2191. > > > >
  2192. > > > > Macro assemblers solved these problems long ago but perhaps not in
  2193. the way modern programmers are
  2194. > > > > used to. From my perspective of an assembly programmer, I could
  2195. list similar problems with C notation,
  2196. > > > > and in the past some non-standard specialized C compilers
  2197. addressed issues like this.
  2198. > > > >
  2199. > > >
  2200. > > >
  2201. > > > In an assembly language that does not use the traditional assembly
  2202. instruction
  2203. > > > format, but it uses expressions, like e.g. in C, you need more
  2204. operators, to cover
  2205. > > > all the operations that are possible between operands of a given
  2206. type.
  2207. > > >
  2208. > > > Those operators may use keywords, like the mnemonics of a
  2209. traditional language, e.g.
  2210. > > > ADD and ADC, or, in a programming language that accepts Unicode
  2211. source files, like any
  2212. > > > modern programming language should, in my opinion, then there are
  2213. plenty of symbols available
  2214. > > > for operators, e.g. one could use "+" for ADD and "+" in a circle
  2215. for ADC.
  2216. > > >
  2217. > > > Actually such a notation is not new, it was used in the
  2218. documentation of various CPUs, in the past.
  2219. > > >
  2220. > >
  2221. > > What's wrong with "R1=R2+R3+CarryFlag" ?
  2222. >
  2223. > The problem with it is I can see three operations in this notation,
  2224. while there's supposed to be a
  2225. > single instruction for it. There is an ambiguity as to how this notation
  2226. is translated into instructions,
  2227. > unless you hardcode in specification the correspondence between exact
  2228. expressions and machine instructions.
  2229. > And at that point, how is it better than the instruction mnemonics we
  2230. use today?
  2231.  
  2232. It's better because the meaning is easier to remember. Especially for
  2233. casual reader.
  2234. It's probably not better for asm programmer that write asm on particular
  2235. ISA 200 hours per month.
  2236. And it's marginally worse for antiquated compiler like gcc that goes
  2237. through asm stage during compilation.
  2238.  
  2239. >
  2240. > Also, unless you put restrictions on the expressions and their
  2241. interpretation, there is an ambiguity
  2242. > on the result of this expression. Integer addition is transitive, so
  2243. should the compiler interpret
  2244. > it as "R1=(R2+R3)+CarryFlag" or "R1=R2+(R3+CarryFlag)"? If you put the
  2245. requirement to interpret
  2246. > the expression left-to-right then what about "R1=CarryFlag+R2+R3"? Next
  2247. you put the requirement
  2248. > that CarryFlag must go last, but then how is it better than "adc R2, R3,
  2249. R1"? Also, if your target
  2250. > ISA does not support non-destructive instructions, you will have an
  2251. ambiguity with "R1=R2+R3" as
  2252. > the compiler will have to either insert a move instruction or reject
  2253. this expression, while this
  2254. > is naturally solved by instruction mnemonics, which would only support
  2255. two operands.
  2256. >
  2257. > Instruction mnemonics are better because they are not ambiguous like
  2258. that. From the programmer's perspective,
  2259. > they provide the minimum granularity of operations performed by the
  2260. machine. This is not only important
  2261. > from the program interpretation standpoint, but also the definition of
  2262. the program state at the point
  2263. > of interruption, and visibility of operation effects to other CPUs and
  2264. devices.
  2265. >
  2266.  
  2267. You're thinking in terms of compiler while I am talking about assembler.
  2268. Most of the things you mentioned above are just syntax errors that would
  2269. produce [hopefully intelligible] error messages.
  2270.  
  2271. And it's not a pure theory, "algebraic" assemblers exist in real world.
  2272. For some architectures, e.g. for majority of Analog Devices families of
  2273. DSPs, they are the only existing assemblers.
  2274. As I said above, for heavy human users they are neither better nor worse
  2275. than decent traditional asm, which is not surprising due to Perlis's
  2276. observation #99, but for casual users, esp reader, they are non-trivially
  2277. better.
  2278.  
  2279. By: Andrey ([email protected]), March 14, 2022 5:36 am
  2280. Room: [25]Moderated Discussions
  2281. Michael S ([email protected]) on March 14, 2022 3:08 am
  2282. wrote:
  2283. > Andrey ([email protected]) on March 14, 2022 1:27 am
  2284. wrote:
  2285. > > Michael S ([email protected]) on March 13, 2022
  2286. 8:14 am wrote:
  2287. > > > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  2288. > > > > David Hess ([email protected]) on March 12, 2022
  2289. 10:39 am wrote:
  2290. > > > > >
  2291. > > > > > Even ADD usually has a variation which includes carry, and
  2292. assuming the ADD width from
  2293. > > > > > the operands is not always unambiguous. Even x86 assembly
  2294. required an extra notation
  2295. > > > > > to handle that, while 8080 did not. I do not remember now how
  2296. Z80 handled it; Z80
  2297. > > > > > used different mnemonics than 8080 and must have determined
  2298. context like x86.
  2299. > > > > >
  2300. > > > > > Macro assemblers solved these problems long ago but perhaps not
  2301. in the way modern programmers are
  2302. > > > > > used to. From my perspective of an assembly programmer, I could
  2303. list similar problems with C notation,
  2304. > > > > > and in the past some non-standard specialized C compilers
  2305. addressed issues like this.
  2306. > > > > >
  2307. > > > >
  2308. > > > >
  2309. > > > > In an assembly language that does not use the traditional assembly
  2310. instruction
  2311. > > > > format, but it uses expressions, like e.g. in C, you need more
  2312. operators, to cover
  2313. > > > > all the operations that are possible between operands of a given
  2314. type.
  2315. > > > >
  2316. > > > > Those operators may use keywords, like the mnemonics of a
  2317. traditional language, e.g.
  2318. > > > > ADD and ADC, or, in a programming language that accepts Unicode
  2319. source files, like any
  2320. > > > > modern programming language should, in my opinion, then there are
  2321. plenty of symbols available
  2322. > > > > for operators, e.g. one could use "+" for ADD and "+" in a circle
  2323. for ADC.
  2324. > > > >
  2325. > > > > Actually such a notation is not new, it was used in the
  2326. documentation of various CPUs, in the past.
  2327. > > > >
  2328. > > >
  2329. > > > What's wrong with "R1=R2+R3+CarryFlag" ?
  2330. > >
  2331. > > The problem with it is I can see three operations in this notation,
  2332. while there's supposed to be a
  2333. > > single instruction for it. There is an ambiguity as to how this
  2334. notation is translated into instructions,
  2335. > > unless you hardcode in specification the correspondence between exact
  2336. expressions and machine instructions.
  2337. > > And at that point, how is it better than the instruction mnemonics we
  2338. use today?
  2339. >
  2340. > It's better because the meaning is easier to remember. Especially for
  2341. casual reader.
  2342. > It's probably not better for asm programmer that write asm on particular
  2343. ISA 200 hours per month.
  2344. > And it's marginally worse for antiquated compiler like gcc that goes
  2345. through asm stage during compilation.
  2346. >
  2347. > >
  2348. > > Also, unless you put restrictions on the expressions and their
  2349. interpretation, there is an ambiguity
  2350. > > on the result of this expression. Integer addition is transitive, so
  2351. should the compiler interpret
  2352. > > it as "R1=(R2+R3)+CarryFlag" or "R1=R2+(R3+CarryFlag)"? If you put the
  2353. requirement to interpret
  2354. > > the expression left-to-right then what about "R1=CarryFlag+R2+R3"?
  2355. Next you put the requirement
  2356. > > that CarryFlag must go last, but then how is it better than "adc R2,
  2357. R3, R1"? Also, if your target
  2358. > > ISA does not support non-destructive instructions, you will have an
  2359. ambiguity with "R1=R2+R3" as
  2360. > > the compiler will have to either insert a move instruction or reject
  2361. this expression, while this
  2362. > > is naturally solved by instruction mnemonics, which would only support
  2363. two operands.
  2364. > >
  2365. > > Instruction mnemonics are better because they are not ambiguous
  2366. > > like that. From the programmer's perspective,
  2367. > > they provide the minimum granularity of operations performed by the
  2368. machine. This is not only important
  2369. > > from the program interpretation standpoint, but also the definition of
  2370. the program state at the point
  2371. > > of interruption, and visibility of operation effects to other CPUs and
  2372. devices.
  2373. > >
  2374. >
  2375. > You're thinking in terms of compiler while I am talking about assembler.
  2376. Most of the things you mentioned
  2377. > above are just syntax errors that would produce [hopefully intelligible]
  2378. error messages.
  2379. >
  2380. > And it's not a pure theory, "algebraic" assemblers exist in real world.
  2381. For some architectures,
  2382. > e.g. for majority of Analog Devices families of DSPs, they are the only
  2383. existing assemblers.
  2384. > As I said above, for heavy human users they are neither better nor worse
  2385. than
  2386. > decent traditional asm, which is not surprising due to Perlis's
  2387. observation
  2388. > #99, but for casual users, esp reader, they are non-trivially better.
  2389.  
  2390. I don't consider casual users the target audience for assembler languages,
  2391. neither for writing nor for reading. There are plenty of higher level
  2392. programming languages that provide more traditional syntax for arithmetic
  2393. operations and much more. Assembler is not for that, its main target is to
  2394. be the low level machine-oriented language, where there's basically no
  2395. lower level language (well, aside from binary code, but programming in
  2396. binary code is almost not applicable to humans). In a language like that,
  2397. you must be very explicit and very precise as to what the machine must do,
  2398. and any ambiguity and interpretation freedom is for the worse.
  2399.  
  2400. I don't dispute that there are implementations of more human-friendly
  2401. assemblers. I'm saying I don't think this is a good idea.
  2402.  
  2403. By: rwessel ([email protected]), March 14, 2022 6:32 am
  2404. Room: [25]Moderated Discussions
  2405. Andrey ([email protected]) on March 14, 2022 5:36 am
  2406. wrote:
  2407. > Michael S ([email protected]) on March 14, 2022 3:08
  2408. am wrote:
  2409. > > Andrey ([email protected]) on March 14, 2022 1:27
  2410. am wrote:
  2411. > > > Michael S ([email protected]) on March 13, 2022
  2412. 8:14 am wrote:
  2413. > > > > Adrian ([email protected]) on March 12, 2022 12:01 pm wrote:
  2414. > > > > > David Hess ([email protected]) on March 12, 2022
  2415. 10:39 am wrote:
  2416. > > > > > >
  2417. > > > > > > Even ADD usually has a variation which includes carry, and
  2418. assuming the ADD width from
  2419. > > > > > > the operands is not always unambiguous. Even x86 assembly
  2420. required an extra notation
  2421. > > > > > > to handle that, while 8080 did not. I do not remember now how
  2422. Z80 handled it; Z80
  2423. > > > > > > used different mnemonics than 8080 and must have determined
  2424. context like x86.
  2425. > > > > > >
  2426. > > > > > > Macro assemblers solved these problems long ago but perhaps
  2427. not in the way modern programmers are
  2428. > > > > > > used to. From my perspective of an assembly programmer, I
  2429. could list similar problems with C notation,
  2430. > > > > > > and in the past some non-standard specialized C compilers
  2431. addressed issues like this.
  2432. > > > > > >
  2433. > > > > >
  2434. > > > > >
  2435. > > > > > In an assembly language that does not use the traditional
  2436. assembly instruction
  2437. > > > > > format, but it uses expressions, like e.g. in C, you need more
  2438. operators, to cover
  2439. > > > > > all the operations that are possible between operands of a given
  2440. type.
  2441. > > > > >
  2442. > > > > > Those operators may use keywords, like the mnemonics of a
  2443. traditional language, e.g.
  2444. > > > > > ADD and ADC, or, in a programming language that accepts Unicode
  2445. source files, like any
  2446. > > > > > modern programming language should, in my opinion, then there
  2447. are plenty of symbols available
  2448. > > > > > for operators, e.g. one could use "+" for ADD and "+" in a
  2449. circle for ADC.
  2450. > > > > >
  2451. > > > > > Actually such a notation is not new, it was used in the
  2452. documentation of various CPUs, in the past.
  2453. > > > > >
  2454. > > > >
  2455. > > > > What's wrong with "R1=R2+R3+CarryFlag" ?
  2456. > > >
  2457. > > > The problem with it is I can see three operations in this notation,
  2458. while there's supposed to be a
  2459. > > > single instruction for it. There is an ambiguity as to how this
  2460. notation is translated into instructions,
  2461. > > > unless you hardcode in specification the correspondence between
  2462. exact expressions and machine instructions.
  2463. > > > And at that point, how is it better than the instruction mnemonics
  2464. we use today?
  2465. > >
  2466. > > It's better because the meaning is easier to remember. Especially for
  2467. casual reader.
  2468. > > It's probably not better for asm programmer that write asm on
  2469. particular ISA 200 hours per month.
  2470. > > And it's marginally worse for antiquated compiler like gcc that goes
  2471. through asm stage during compilation.
  2472. > >
  2473. > > >
  2474. > > > Also, unless you put restrictions on the expressions and their
  2475. interpretation, there is an ambiguity
  2476. > > > on the result of this expression. Integer addition is transitive, so
  2477. should the compiler interpret
  2478. > > > it as "R1=(R2+R3)+CarryFlag" or "R1=R2+(R3+CarryFlag)"? If you put
  2479. the requirement to interpret
  2480. > > > the expression left-to-right then what about "R1=CarryFlag+R2+R3"?
  2481. Next you put the requirement
  2482. > > > that CarryFlag must go last, but then how is it better than "adc R2,
  2483. R3, R1"? Also, if your target
  2484. > > > ISA does not support non-destructive instructions, you will have an
  2485. ambiguity with "R1=R2+R3" as
  2486. > > > the compiler will have to either insert a move instruction or reject
  2487. this expression, while this
  2488. > > > is naturally solved by instruction mnemonics, which would only
  2489. support two operands.
  2490. > > >
  2491. > > > Instruction mnemonics are better because they are not ambiguous
  2492. > > > like that. From the programmer's perspective,
  2493. > > > they provide the minimum granularity of operations performed by the
  2494. machine. This is not only important
  2495. > > > from the program interpretation standpoint, but also the definition
  2496. of the program state at the point
  2497. > > > of interruption, and visibility of operation effects to other CPUs
  2498. and devices.
  2499. > > >
  2500. > >
  2501. > > You're thinking in terms of compiler while I am talking about
  2502. assembler. Most of the things you mentioned
  2503. > > above are just syntax errors that would produce [hopefully
  2504. intelligible] error messages.
  2505. > >
  2506. > > And it's not a pure theory, "algebraic" assemblers exist in real
  2507. world. For some architectures,
  2508. > > e.g. for majority of Analog Devices families of DSPs, they are the
  2509. only existing assemblers.
  2510. > > As I said above, for heavy human users they are neither better nor
  2511. worse than
  2512. > > decent traditional asm, which is not surprising due to Perlis's
  2513. observation
  2514. > > #99, but for casual users, esp reader, they are non-trivially better.
  2515. >
  2516. > I don't consider casual users the target audience for assembler
  2517. languages, neither for writing nor for reading.
  2518. > There are plenty of higher level programming languages that provide more
  2519. traditional syntax for arithmetic operations
  2520. > and much more. Assembler is not for that, its main target is to be the
  2521. low level machine-oriented language,
  2522. > where there's basically no lower level language (well, aside from binary
  2523. code, but programming in binary code
  2524. > is almost not applicable to humans). In a language like that, you must
  2525. be very explicit and very precise as
  2526. > to what the machine must do, and any ambiguity and interpretation
  2527. freedom is for the worse.
  2528. >
  2529. > I don't dispute that there are implementations of more human-friendly
  2530. > assemblers. I'm saying I don't think this is a good idea.
  2531.  
  2532. In the past good assembler facilities for more "casual" programming were
  2533. more important as assembler programming was much more common, and unlike
  2534. today, it often included entire applications, where you ended up with tons
  2535. of more boilerplate-ish code.
  2536.  
  2537. Still a decent macro facilities and other aids are still occasionally
  2538. useful, unfortunately they tend to be more afterthoughts these days (and
  2539. often a more than a bit half-baked). I've more than once resorted to a HLL
  2540. program to generate some code (say with significant unrolling, or such)
  2541. rather than using facilities built into the assembler.
  2542.  
  2543. By: Jukka Larja ([email protected]), March 14, 2022 7:10
  2544. am
  2545. Room: [25]Moderated Discussions
  2546. Andrey ([email protected]) on March 14, 2022 5:36 am
  2547. wrote:
  2548.  
  2549. > I don't consider casual users the target audience for assembler
  2550. languages, neither for writing nor for reading.
  2551.  
  2552. That may well be, but I don't know anyone who writes assembler (I could
  2553. add "pretty much ever", but frankly, even that would be bit of an
  2554. exaggeration). However, everyone who writes C(++) for game industry should
  2555. be able to read assembly. And I imagine situation is pretty similar for
  2556. most C(++) programmers (otherwise they are likely to use something
  2557. friendlier).
  2558.  
  2559. So personally I'm thinking that readability of assembler is an order of
  2560. magnitude more important than writability, and that large part of those
  2561. readers are "casual", at least when compared to someone who spents
  2562. significant time writing assembler for work.
  2563.  
  2564. But this is all based on my use case of assembler. If current (in my
  2565. opinion horrible and extremely unreadable) syntax is superior for writing,
  2566. then I'd suggest friendlier syntax (and especially naming) as an option in
  2567. debugger (and in Godbolt :D ). In a perfect world, that is. I don't think
  2568. there's enough demand for anything like that.
  2569.  
  2570. -JLarja
  2571.  
  2572. By: Adrian ([email protected]), March 11, 2022 1:06 pm
  2573. Room: [25]Moderated Discussions
  2574. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  2575. > I always wanted my assembly (and I have written a fair amount, although
  2576. not much lately) to be
  2577. > closer to a high level language. Instead of
  2578. >
  2579. > ADD R1,R2
  2580. >
  2581. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  2582. assembler, just write:
  2583. >
  2584. > R1 += R2
  2585. >
  2586. > For a load:
  2587. >
  2588. > R1 = [R1+offset]
  2589. >
  2590. > and so on.
  2591. >
  2592. > For the more complex things (add packed single), a simple algebraic
  2593. statement is not going
  2594. > to work, so make it a function call like syntax:
  2595. >
  2596. > R1 = add_packed_single(R1, R2)
  2597. >
  2598. > Of course there are limitations on what is semantically allowed, but if
  2599. somebody wants to write:
  2600. >
  2601. > R3 = add_packed_single(R1, R2)
  2602. >
  2603. > The assembler *could* be smart enough to move R1 to R3 first, then do
  2604. the add.
  2605. >
  2606. > The result is something that is still as efficient and low level as
  2607. assembler (still pretty
  2608. > much one instruction per statement), but readable by programmers that
  2609. are familiar with C like
  2610. > languages.
  2611.  
  2612. You are not the only one.
  2613.  
  2614. I also prefer to write assembly in a way similar to your examples and to
  2615. use a preprocessor to generate a standard assembly file.
  2616.  
  2617. A more elaborate tool of this type was the qhasm assembler of D. J.
  2618. Bernstein.
  2619. A preliminary version of it was published in 2007.
  2620.  
  2621. An example of the syntax used by qhasm:
  2622.  
  2623. [26]https://cr.yp.to/qhasm/amd64/20070122-poly1305.q
  2624.  
  2625. By: Andrey ([email protected]), March 11, 2022 4:01 pm
  2626. Room: [25]Moderated Discussions
  2627. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  2628. > I always wanted my assembly (and I have written a fair amount, although
  2629. not much lately) to be
  2630. > closer to a high level language. Instead of
  2631. >
  2632. > ADD R1,R2
  2633. >
  2634. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  2635. assembler, just write:
  2636. >
  2637. > R1 += R2
  2638. >
  2639. > For a load:
  2640. >
  2641. > R1 = [R1+offset]
  2642. >
  2643. > and so on.
  2644. >
  2645. > For the more complex things (add packed single), a simple algebraic
  2646. statement is not going
  2647. > to work, so make it a function call like syntax:
  2648. >
  2649. > R1 = add_packed_single(R1, R2)
  2650. >
  2651. > Of course there are limitations on what is semantically allowed, but if
  2652. somebody wants to write:
  2653. >
  2654. > R3 = add_packed_single(R1, R2)
  2655. >
  2656. > The assembler *could* be smart enough to move R1 to R3 first, then do
  2657. the add.
  2658. >
  2659. > The result is something that is still as efficient and low level as
  2660. assembler (still pretty
  2661. > much one instruction per statement), but readable by programmers that
  2662. are familiar with C like
  2663. > languages.
  2664.  
  2665. Why don't you just write in C?
  2666.  
  2667. Assembler is useful in cases when you want exact instructions and their
  2668. order. For example, there may be many ways to do arithmetic operations (in
  2669. x86, add/sub/mul, lea, shifts), and different instructions are useful in
  2670. different circumstances (like lea not affecting flags, meaning they are
  2671. preserved from prior instructions; the other way around is also useful if
  2672. you want to test the result of the arithmetic instruction). Another
  2673. example is atomics and memory ordering guarantees which are maintained by
  2674. specific instructions and their order. Yet another example is emitting
  2675. very specific instruction sequences (some of which may look stupid,
  2676. inefficient or useless) that have special semantics on hardware. Think
  2677. workarounds for hardware bugs and vulnerabilities. So you do want to be
  2678. very explicit about generated instructions in assembler.
  2679.  
  2680. By: Adrian ([email protected]), March 12, 2022 2:24 am
  2681. Room: [25]Moderated Discussions
  2682. Andrey ([email protected]) on March 11, 2022 3:01 pm
  2683. wrote:
  2684. > Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  2685. > > I always wanted my assembly (and I have written a fair amount,
  2686. although not much lately) to be
  2687. > > closer to a high level language. Instead of
  2688. > >
  2689. > > ADD R1,R2
  2690. > >
  2691. > > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  2692. assembler, just write:
  2693. > >
  2694. > > R1 += R2
  2695. > >
  2696. > > For a load:
  2697. > >
  2698. > > R1 = [R1+offset]
  2699. > >
  2700. > > and so on.
  2701. > >
  2702. > > For the more complex things (add packed single), a simple algebraic
  2703. statement is not going
  2704. > > to work, so make it a function call like syntax:
  2705. > >
  2706. > > R1 = add_packed_single(R1, R2)
  2707. > >
  2708. > > Of course there are limitations on what is semantically allowed, but
  2709. if somebody wants to write:
  2710. > >
  2711. > > R3 = add_packed_single(R1, R2)
  2712. > >
  2713. > > The assembler *could* be smart enough to move R1 to R3 first, then do
  2714. the add.
  2715. > >
  2716. > > The result is something that is still as efficient and low level as
  2717. assembler (still pretty
  2718. > > much one instruction per statement), but readable by programmers that
  2719. are familiar with C like
  2720. > > languages.
  2721. >
  2722. > Why don't you just write in C?
  2723. >
  2724. > Assembler is useful in cases when you want exact instructions and their
  2725. order. For example, there may be
  2726. > many ways to do arithmetic operations (in x86, add/sub/mul, lea,
  2727. shifts), and different instructions are useful
  2728. > in different circumstances (like lea not affecting flags, meaning they
  2729. are preserved from prior instructions;
  2730. > the other way around is also useful if you want to test the result of
  2731. the arithmetic instruction). Another
  2732. > example is atomics and memory ordering guarantees which are maintained
  2733. by specific instructions and their
  2734. > order. Yet another example is emitting very specific instruction
  2735. sequences (some of which may look stupid,
  2736. > inefficient or useless) that have special semantics on hardware. Think
  2737. workarounds for hardware bugs and vulnerabilities.
  2738. > So you do want to be very explicit about generated instructions in
  2739. assembler.
  2740. >
  2741.  
  2742. Assembler is required precisely for what you say.
  2743.  
  2744. Nevertheless, the ability of specifying exactly a sequence of machine
  2745. instructions is something that it is completely independent from a
  2746. requirement of writing each machine instruction only as a mnemonic
  2747. followed by a list of operands.
  2748.  
  2749. It is possible to use any syntax that is used by any other kind of
  2750. programming languages, but nonetheless define rules that will determine
  2751. unambiguously the sequence of machine instructions that is generated.
  2752.  
  2753. I have already given in my other post an example program written for the
  2754. qhasm of D.J. Bernstein, which does not look at all like a traditional
  2755. assembly language, but it is close to a language like C.
  2756.  
  2757. Nonetheless, it specifies exactly the sequence of machine instructions,
  2758. like any other assembly language.
  2759.  
  2760. By: anon2 ([email protected]), March 11, 2022 5:37 pm
  2761. Room: [25]Moderated Discussions
  2762. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  2763. > I always wanted my assembly (and I have written a fair amount, although
  2764. not much lately) to be
  2765. > closer to a high level language. Instead of
  2766. >
  2767. > ADD R1,R2
  2768. >
  2769. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  2770. assembler, just write:
  2771. >
  2772. > R1 += R2
  2773.  
  2774. Little different than ADD R1,R2. It really takes all of about one hour of
  2775. serious assembly programming for the source destination ordering to become
  2776. something you don't need to think about.
  2777.  
  2778. >
  2779. > For a load:
  2780. >
  2781. > R1 = [R1+offset]
  2782.  
  2783. What kind of load would that give you, and how would you perform other
  2784. types?
  2785.  
  2786. Specifying instruction is superior here.
  2787.  
  2788. >
  2789. > and so on.
  2790. >
  2791. > For the more complex things (add packed single), a simple algebraic
  2792. statement is not going
  2793. > to work, so make it a function call like syntax:
  2794. >
  2795. > R1 = add_packed_single(R1, R2)
  2796. >
  2797. > Of course there are limitations on what is semantically allowed, but if
  2798. somebody wants to write:
  2799. >
  2800. > R3 = add_packed_single(R1, R2)
  2801. >
  2802. > The assembler *could* be smart enough to move R1 to R3 first, then do
  2803. the add.
  2804.  
  2805. You can do all this with a macro assembler like gas. Well not this exact
  2806. semantics but close.
  2807.  
  2808. > The result is something that is still as efficient and low level as
  2809. assembler (still pretty
  2810. > much one instruction per statement), but readable by programmers that
  2811. are familiar with C like
  2812. > languages.
  2813.  
  2814. Most use of assembly these days wants to know the exact machine
  2815. instructions executed.
  2816.  
  2817. The days of writing tens of thousands of lines of asm in applicatoins are
  2818. gone and never coming back, for good reason. Write anything
  2819. performance-critical in a high level language like C.
  2820.  
  2821. Most of the remaining few reasons for asm in performance critical places
  2822. are well-contained compute kernels that have no logic besides the
  2823. mathematical algorithm, and tend to be very microarchitecture specific so
  2824. you don't really want a high level assembler to pick or schedule your
  2825. instructions or allocate your registers anyway.
  2826.  
  2827. By: rwessel ([email protected]), March 11, 2022 7:44 pm
  2828. Room: [25]Moderated Discussions
  2829. Tim ([email protected]) on March 11, 2022 10:56 am wrote:
  2830. > I always wanted my assembly (and I have written a fair amount, although
  2831. not much lately) to be
  2832. > closer to a high level language. Instead of
  2833. >
  2834. > ADD R1,R2
  2835. >
  2836. > Which could be "add r1 to r2", or "add R2 to R1" depending on the
  2837. assembler, just write:
  2838. >
  2839. > R1 += R2
  2840. >
  2841. > For a load:
  2842. >
  2843. > R1 = [R1+offset]
  2844. >
  2845. > and so on.
  2846. >
  2847. > For the more complex things (add packed single), a simple algebraic
  2848. statement is not going
  2849. > to work, so make it a function call like syntax:
  2850. >
  2851. > R1 = add_packed_single(R1, R2)
  2852. >
  2853. > Of course there are limitations on what is semantically allowed, but if
  2854. somebody wants to write:
  2855. >
  2856. > R3 = add_packed_single(R1, R2)
  2857. >
  2858. > The assembler *could* be smart enough to move R1 to R3 first, then do
  2859. the add.
  2860. >
  2861. > The result is something that is still as efficient and low level as
  2862. assembler (still pretty
  2863. > much one instruction per statement), but readable by programmers that
  2864. are familiar with C like
  2865. > languages.
  2866.  
  2867. This is less than helpful, but there was an assembler that looked more
  2868. like arithmetic expressions, along the lines you suggested. 1960s, but I
  2869. can't remember which system it was. I was thinking CDC 6600 family, but
  2870. that's wrong. You'd code an add like:
  2871.  
  2872. r1=r2+r3
  2873.  
  2874. By: Heikki Kultala ([email protected]), March 9, 2022
  2875. 11:31 pm
  2876. Room: [25]Moderated Discussions
  2877. -.- ([email protected]) on March 9, 2022 5:39 am wrote:
  2878. > Plenty of weird names in many assembly dialects, to be honest.
  2879. > PALIGNR in x86 or EXT in AArch64 aren't obvious unless you already know
  2880. what the instruction does.
  2881. >
  2882. > Perhaps it's time to move away from compact assembly instruction names?
  2883.  
  2884. When they are using in RISC-V is totally wrong words, the problem is not
  2885. "compactness" of the asm syntax.
  2886.  
  2887. In common terminology:
  2888. Conditional move means 3-operand instruction (input, condition, result)
  2889. Select means 4-operand instruction (Input1, input2, select, result)
  2890.  
  2891. Gather means vector load from memory with vector addressing.
  2892. Shuffle means reordering of data inside the vector registers.
  2893.  
  2894. By: Adrian ([email protected]), March 10, 2022 7:33 am
  2895. Room: [25]Moderated Discussions
  2896. Heikki Kultala ([email protected]) on March 9, 2022
  2897. 10:31 pm wrote:
  2898. > -.- ([email protected]) on March 9, 2022 5:39 am wrote:
  2899. > > Plenty of weird names in many assembly dialects, to be honest.
  2900. > > PALIGNR in x86 or EXT in AArch64 aren't obvious unless you already
  2901. know what the instruction does.
  2902. > >
  2903. > > Perhaps it's time to move away from compact assembly instruction
  2904. names?
  2905. >
  2906. > When they are using in RISC-V is totally wrong words, the problem is not
  2907. "compactness" of the asm syntax.
  2908. >
  2909. > In common terminology:
  2910. > Conditional move means 3-operand instruction (input, condition, result)
  2911. > Select means 4-operand instruction (Input1, input2, select, result)
  2912. >
  2913. > Gather means vector load from memory with vector addressing.
  2914. > Shuffle means reordering of data inside the vector registers.
  2915. >
  2916.  
  2917. Yes, you are perfectly right.
  2918.  
  2919. I agree that failing to follow the traditional meaning of these operations
  2920. is bad.
  2921.  
  2922. By: anonymou5 ([email protected]), March 10, 2022 12:59 pm
  2923. Room: [25]Moderated Discussions
  2924. > Yes, you are perfectly right.
  2925. >
  2926. > I agree that failing to follow the traditional meaning of these
  2927. operations is bad.
  2928.  
  2929. If it bothers you enough, then join the RISC-V camp, and try to change
  2930. things.
  2931.  
  2932. Another possibility: use macros, to name things differently.
  2933.  
  2934. By: rwessel ([email protected]), March 11, 2022 10:42 am
  2935. Room: [25]Moderated Discussions
  2936. anonymou5 ([email protected]) on March 10, 2022 11:59 am wrote:
  2937. > > Yes, you are perfectly right.
  2938. > >
  2939. > > I agree that failing to follow the traditional meaning of these
  2940. operations is bad.
  2941. >
  2942. > If it bothers you enough, then join the RISC-V camp, and try to change
  2943. things.
  2944. >
  2945. > Another possibility: use macros, to name things differently.
  2946.  
  2947. I suspect that idea will (and should) get the same reception as people who
  2948. do:
  2949.  
  2950. #define begin {
  2951. #define end }
  2952.  
  2953. in C. And for mostly the same reasons.
  2954.  
  2955. By: Anon ([email protected]), March 11, 2022 11:44 am
  2956. Room: [25]Moderated Discussions
  2957. rwessel ([email protected]) on March 11, 2022 9:42 am wrote:
  2958. > I suspect that idea will (and should) get the same reception as people
  2959. who do:
  2960. >
  2961. > #define begin {
  2962. > #define end }
  2963. >
  2964. > in C. And for mostly the same reasons.
  2965.  
  2966. One thing I hate more than C {} is begin/end, some people are hard to
  2967. understand.
  2968.  
  2969. By: Adrian ([email protected]), March 11, 2022 1:45 pm
  2970. Room: [25]Moderated Discussions
  2971. Anon ([email protected]) on March 11, 2022 10:44 am wrote:
  2972. > rwessel ([email protected]) on March 11, 2022 9:42 am wrote:
  2973. > > I suspect that idea will (and should) get the same reception as people
  2974. who do:
  2975. > >
  2976. > > #define begin {
  2977. > > #define end }
  2978. > >
  2979. > > in C. And for mostly the same reasons.
  2980. >
  2981. > One thing I hate more than C {} is begin/end, some people are hard to
  2982. understand.
  2983.  
  2984. I also consider that replacing "{" and "}" with "begin" and "end" is
  2985. stupid.
  2986.  
  2987. On the other hand, having distinct keywords or symbols used as separators
  2988. in different kinds of statements or expressions, like in Algol 68, is a
  2989. definite improvement over the Pascal or C method of using a single kind of
  2990. statement brackets, which results in programs with an excessive number of
  2991. brackets, which are very difficult to read without using an editor which
  2992. highlights matching parentheses.
  2993.  
  2994. While the highlighting of matching brackets/parentheses is helpful, the
  2995. need of checking them still slows you a lot.
  2996.  
  2997. So in personal projects, where team programming rules do not matter, I
  2998. like definitions such as:
  2999.  
  3000. #define for for(
  3001. #define loop ){
  3002. #define next }
  3003.  
  3004. This solves common problems, like having a long string of "}", a part
  3005. closing "if" and a part closing "for", and it is difficult to distinguish
  3006. which are which.
  3007.  
  3008. It also solves what I consider a serious defect in C/C++, having to use
  3009. parentheses for the control expressions of if/while/for/switch. The
  3010. parentheses are needed only because the following braces are optional.
  3011. However in most cases you have to put braces anyway, but you still have to
  3012. write the redundant parentheses. The braces should have been mandatory and
  3013. no parentheses should have been used.
  3014.  
  3015. By: Anon ([email protected]), March 11, 2022 2:33 pm
  3016. Room: [25]Moderated Discussions
  3017. Adrian ([email protected]) on March 11, 2022 12:45 pm wrote:
  3018. > It also solves what I consider a serious defect in C/C++, having to use
  3019. parentheses for the control
  3020. > expressions of if/while/for/switch. The parentheses are needed only
  3021. because the following braces are
  3022. > optional. However in most cases you have to put braces anyway, but you
  3023. still have to write the redundant
  3024. > parentheses. The braces should have been mandatory and no parentheses
  3025. should have been used.
  3026.  
  3027. That's what Rust did, but the braces still annoys me because after the
  3028. opening brace there is always a new line, I think, after a if, for or
  3029. while a line break should be mandatory so we only need a block terminator.
  3030. Oh, and the ";", terminating an expression at line break is far more
  3031. common than continuing it.
  3032.  
  3033. By: Andrey ([email protected]), March 11, 2022 4:09 pm
  3034. Room: [25]Moderated Discussions
  3035. Anon ([email protected]) on March 11, 2022 1:33 pm wrote:
  3036. > Adrian ([email protected]) on March 11, 2022 12:45 pm wrote:
  3037. > > It also solves what I consider a serious defect in C/C++, having to
  3038. use parentheses for the control
  3039. > > expressions of if/while/for/switch. The parentheses are needed only
  3040. because the following braces are
  3041. > > optional. However in most cases you have to put braces anyway, but you
  3042. still have to write the redundant
  3043. > > parentheses. The braces should have been mandatory and no parentheses
  3044. should have been used.
  3045. >
  3046. > That's what Rust did, but the braces still annoys me because after the
  3047. opening brace there is always a new line,
  3048. > I think, after a if, for or while a line break should be mandatory so we
  3049. only need a block terminator.
  3050. > Oh, and the ";", terminating an expression at line break is far more
  3051. common than continuing it.
  3052.  
  3053. C/C++ are whitespace-neutral (and newline characters are whitespace),
  3054. which I consider a big advantage. Even if you maintain one expression per
  3055. line, this is still useful in macros, whether defined by you or system
  3056. headers.
  3057.  
  3058. By: Adrian ([email protected]), March 12, 2022 2:41 am
  3059. Room: [25]Moderated Discussions
  3060. Andrey ([email protected]) on March 11, 2022 3:09 pm
  3061. wrote:
  3062. > Anon ([email protected]) on March 11, 2022 1:33 pm wrote:
  3063. > > Adrian ([email protected]) on March 11, 2022 12:45 pm wrote:
  3064. > > > It also solves what I consider a serious defect in C/C++, having to
  3065. use parentheses for the control
  3066. > > > expressions of if/while/for/switch. The parentheses are needed only
  3067. because the following braces are
  3068. > > > optional. However in most cases you have to put braces anyway, but
  3069. you still have to write the redundant
  3070. > > > parentheses. The braces should have been mandatory and no
  3071. parentheses should have been used.
  3072. > >
  3073. > > That's what Rust did, but the braces still annoys me because
  3074. > > after the opening brace there is always a new line,
  3075. > > I think, after a if, for or while a line break should be mandatory so
  3076. we only need a block terminator.
  3077. > > Oh, and the ";", terminating an expression at line break is far more
  3078. common than continuing it.
  3079. >
  3080. > C/C++ are whitespace-neutral (and newline characters are whitespace),
  3081. which
  3082. > I consider a big advantage. Even if you maintain one expression per
  3083. line, this
  3084. > is still useful in macros, whether defined by you or system headers.
  3085. >
  3086.  
  3087. In 1965, CPL, the ancestor of C/C++, handled much better the issue of
  3088. whitespace and statement termination.
  3089.  
  3090. Any statement could be terminated by either a new line or a semicolon,
  3091. except that a new line was not considered as a statement terminator when
  3092. it occurred at a program point where a statement terminator is illegal.
  3093. (the usefulness of the exception is debatable, it saves typing, but it
  3094. might allow some bugs)
  3095.  
  3096. The CPL rule combined the previous rules used by Algol 60 (semicolon) and
  3097. Fortran (new line). The CPL rule has been inherited by the UNIX shell.
  3098.  
  3099. When semicolon and new line are synonymous, that minimizes the need of
  3100. typing terminators, while still allowing both for free formatting of the
  3101. program text and for writing any kind of macros.
  3102.  
  3103. By: Andrey ([email protected]), March 12, 2022 4:57 am
  3104. Room: [25]Moderated Discussions
  3105. Adrian ([email protected]) on March 12, 2022 1:41 am wrote:
  3106. > Andrey ([email protected]) on March 11, 2022 3:09 pm
  3107. wrote:
  3108. > > Anon ([email protected]) on March 11, 2022 1:33 pm wrote:
  3109. > > > Adrian ([email protected]) on March 11, 2022 12:45 pm wrote:
  3110. > > > > It also solves what I consider a serious defect in C/C++, having
  3111. to use parentheses for the control
  3112. > > > > expressions of if/while/for/switch. The parentheses are needed
  3113. only because the following braces are
  3114. > > > > optional. However in most cases you have to put braces anyway, but
  3115. you still have to write the redundant
  3116. > > > > parentheses. The braces should have been mandatory and no
  3117. parentheses should have been used.
  3118. > > >
  3119. > > > That's what Rust did, but the braces still annoys me because
  3120. > > > after the opening brace there is always a new line,
  3121. > > > I think, after a if, for or while a line break should be mandatory
  3122. so we only need a block terminator.
  3123. > > > Oh, and the ";", terminating an expression at line break is far more
  3124. common than continuing it.
  3125. > >
  3126. > > C/C++ are whitespace-neutral (and newline characters are whitespace),
  3127. which
  3128. > > I consider a big advantage. Even if you maintain one expression per
  3129. line, this
  3130. > > is still useful in macros, whether defined by you or system headers.
  3131. > >
  3132. >
  3133. >
  3134. > In 1965, CPL, the ancestor of C/C++, handled much better the issue of
  3135. whitespace and statement termination.
  3136. >
  3137. > Any statement could be terminated by either a new line or a semicolon,
  3138. except that a new line was not considered
  3139. > as a statement terminator when it occurred at a program point where a
  3140. statement terminator is illegal.
  3141. > (the usefulness of the exception is debatable, it saves typing, but it
  3142. might allow some bugs)
  3143. >
  3144. > The CPL rule combined the previous rules used by Algol 60 (semicolon)
  3145. and
  3146. > Fortran (new line). The CPL rule has been inherited by the UNIX shell.
  3147. >
  3148. > When semicolon and new line are synonymous, that minimizes the need of
  3149. typing terminators, while
  3150. > still allowing both for free formatting of the program text and for
  3151. writing any kind of macros.
  3152.  
  3153. This does not work in all contexts. For example:
  3154.  
  3155. struct foo
  3156. {
  3157. int value;
  3158. }
  3159. object = {10};
  3160.  
  3161. I'm fairly sure there are other contexts as well.
  3162.  
  3163. There is also a matter of further language extensibility. New language
  3164. constructs are easier to introduce and teach when the syntax rules are
  3165. simple and unambiguous. Granted, C/C++ syntax is not exactly simple as it
  3166. is, but introducing whitespace sensibility certainly doesn't make it
  3167. simpler. An unconditional rule "a statement or declaration ends with
  3168. semicolon" is easier to learn and follow than "a statement or declaration
  3169. ends with semicolon or newline if X, Y or Z conditions are satisfied".
  3170.  
  3171. By: Anon ([email protected]), March 12, 2022 5:01 am
  3172. Room: [25]Moderated Discussions
  3173. Andrey ([email protected]) on March 12, 2022 3:57 am
  3174. wrote:
  3175. > This does not work in all contexts. For example:
  3176. >
  3177. > struct foo
  3178. > {
  3179. > int value;
  3180. > }
  3181. > object = {10};
  3182. >
  3183. > I'm fairly sure there are other contexts as well.
  3184. >
  3185. > There is also a matter of further language extensibility. New language
  3186. constructs are easier to introduce
  3187. > and teach when the syntax rules are simple and unambiguous. Granted,
  3188. C/C++ syntax is not exactly simple
  3189. > as it is, but introducing whitespace sensibility certainly doesn't make
  3190. it simpler. An unconditional
  3191. > rule "a statement or declaration ends with semicolon" is easier to learn
  3192. and follow than "a statement
  3193. > or declaration ends with semicolon or newline if X, Y or Z conditions
  3194. are satisfied".
  3195. >
  3196.  
  3197. "A statement or declaration ends with a newline" sounds simple to me.
  3198.  
  3199. By: rwessel ([email protected]), March 12, 2022 7:12 am
  3200. Room: [25]Moderated Discussions
  3201. Anon ([email protected]) on March 12, 2022 4:01 am wrote:
  3202. > Andrey ([email protected]) on March 12, 2022 3:57 am
  3203. wrote:
  3204. > > This does not work in all contexts. For example:
  3205. > >
  3206. > > struct foo
  3207. > > {
  3208. > > int value;
  3209. > > }
  3210. > > object = {10};
  3211. > >
  3212. > > I'm fairly sure there are other contexts as well.
  3213. > >
  3214. > > There is also a matter of further language extensibility. New language
  3215. constructs are easier to introduce
  3216. > > and teach when the syntax rules are simple and unambiguous. Granted,
  3217. C/C++ syntax is not exactly simple
  3218. > > as it is, but introducing whitespace sensibility certainly doesn't
  3219. make it simpler. An unconditional
  3220. > > rule "a statement or declaration ends with semicolon" is easier to
  3221. learn and follow than "a statement
  3222. > > or declaration ends with semicolon or newline if X, Y or Z conditions
  3223. are satisfied".
  3224. > >
  3225. >
  3226. > "A statement or declaration ends with a newline" sounds simple to me.
  3227.  
  3228. Sure, but then you need a way to specify a continuation for statements you
  3229. can't fit on a line. We have that in C too, in the preprocessor.
  3230.  
  3231. And obviously that debate goes back to the dawn, with Fortran and Cobol
  3232. taking different directions (and with complications in both cases).
  3233.  
  3234. I think that by now we should have learned that significant whitespace in
  3235. a programming language is mostly a mistake. Obviously people disagree,
  3236. hence Python.
  3237.  
  3238. By: Anon ([email protected]), March 12, 2022 1:50 pm
  3239. Room: [25]Moderated Discussions
  3240. rwessel ([email protected]) on March 12, 2022 6:12 am wrote:
  3241. > Sure, but then you need a way to specify a continuation for statements
  3242. > you can't fit on a line. We have that in C too, in the preprocessor.
  3243.  
  3244. Basic uses "_", I don't like it because it is hard to see, things at the
  3245. end of the line are harder to see than at start, "_" makes it worse by
  3246. being a small sign, "" used in C preprocessor is better, but a symbol at
  3247. the start of the next line to say it is a continuation of the previous
  3248. lines would be easier to see.
  3249.  
  3250. > I think that by now we should have learned that significant whitespace
  3251. in a programming
  3252. > language is mostly a mistake. Obviously people disagree, hence Python.
  3253.  
  3254. The biggest problem with Python is that tab and normal space have the same
  3255. meaning but different visual sizes, if tabs didn't exist there would be
  3256. far less complains about Python, and, in my opinion, marking the end of a
  3257. block is far more important than marking the end of a statement.
  3258.  
  3259. By: Adrian ([email protected]), March 12, 2022 5:50 am
  3260. Room: [25]Moderated Discussions
  3261. Andrey ([email protected]) on March 12, 2022 3:57 am
  3262. wrote:
  3263. > Adrian ([email protected]) on March 12, 2022 1:41 am wrote:
  3264. > > Andrey ([email protected]) on March 11, 2022 3:09
  3265. pm wrote:
  3266. > > > Anon ([email protected]) on March 11, 2022 1:33 pm wrote:
  3267. > > > > Adrian ([email protected]) on March 11, 2022 12:45 pm wrote:
  3268. > > > > > It also solves what I consider a serious defect in C/C++, having
  3269. to use parentheses for the control
  3270. > > > > > expressions of if/while/for/switch. The parentheses are needed
  3271. only because the following braces are
  3272. > > > > > optional. However in most cases you have to put braces anyway,
  3273. but you still have to write the redundant
  3274. > > > > > parentheses. The braces should have been mandatory and no
  3275. parentheses should have been used.
  3276. > > > >
  3277. > > > > That's what Rust did, but the braces still annoys me because
  3278. > > > > after the opening brace there is always a new line,
  3279. > > > > I think, after a if, for or while a line break should be mandatory
  3280. so we only need a block terminator.
  3281. > > > > Oh, and the ";", terminating an expression at line break is far
  3282. more common than continuing it.
  3283. > > >
  3284. > > > C/C++ are whitespace-neutral (and newline characters are
  3285. whitespace), which
  3286. > > > I consider a big advantage. Even if you maintain one expression per
  3287. line, this
  3288. > > > is still useful in macros, whether defined by you or system headers.
  3289. > > >
  3290. > >
  3291. > >
  3292. > > In 1965, CPL, the ancestor of C/C++, handled much better the issue of
  3293. whitespace and statement termination.
  3294. > >
  3295. > > Any statement could be terminated by either a new line or
  3296. > > a semicolon, except that a new line was not considered
  3297. > > as a statement terminator when it occurred at a program point where a
  3298. statement terminator is illegal.
  3299. > > (the usefulness of the exception is debatable, it saves typing, but it
  3300. might allow some bugs)
  3301. > >
  3302. > > The CPL rule combined the previous rules used by Algol 60 (semicolon)
  3303. and
  3304. > > Fortran (new line). The CPL rule has been inherited by the UNIX shell.
  3305. > >
  3306. > > When semicolon and new line are synonymous, that minimizes the need of
  3307. typing terminators, while
  3308. > > still allowing both for free formatting of the program text and for
  3309. writing any kind of macros.
  3310. >
  3311. > This does not work in all contexts. For example:
  3312. >
  3313. > struct foo
  3314. > {
  3315. > int value;
  3316. > }
  3317. > object = {10};
  3318. >
  3319. > I'm fairly sure there are other contexts as well.
  3320. >
  3321. > There is also a matter of further language extensibility. New language
  3322. constructs are easier to introduce
  3323. > and teach when the syntax rules are simple and unambiguous. Granted,
  3324. C/C++ syntax is not exactly simple
  3325. > as it is, but introducing whitespace sensibility certainly doesn't make
  3326. it simpler. An unconditional
  3327. > rule "a statement or declaration ends with semicolon" is easier to learn
  3328. and follow than "a statement
  3329. > or declaration ends with semicolon or newline if X, Y or Z conditions
  3330. are satisfied".
  3331. >
  3332.  
  3333. C has many syntactic quirks and making new line synonymous with semicolon
  3334. in it will obviously not work without other changes.
  3335.  
  3336. However in a clean syntax it is trivial to avoid any problems due to that.
  3337.  
  3338. I have already said that the exception included in the CPL rule was
  3339. probably an attempt to be too clever.
  3340.  
  3341. When the simpler rule that semicolon and new line are synonymous (which
  3342. also requires a character like backslash for line continuations) is used,
  3343. that is simple enough in my opinion and it leads to programs that are
  3344. easier to read and write.
  3345.  
  3346. In general I agree that it is bad to depend on white space, but, like for
  3347. anything else, the extreme variant is bad.
  3348.  
  3349. During a half of century, millions of semicolons have been typed and they
  3350. have added pointless visual noise to program texts, for what?
  3351.  
  3352. To satisfy some fetish for the lack of significance of white space?
  3353. Even this theory is wrong, because white space is significant in C as a
  3354. separator, even if it does not matter what kind of white space that is.
  3355.  
  3356. It cannot be said that the early languages, like Fortran, were more
  3357. dependent on white space significance than C. While new line was
  3358. distinguished from other white space by being a statement terminator, the
  3359. other kinds of white space were ignored completely, so it did not matter
  3360. at all where you inserted blanks in the program text, unlike in C, where
  3361. it matters.
  3362.  
  3363. Making the blank significant was good, because it simplified parsing, but
  3364. making the new line insignificant was bad, by requiring lots of extra
  3365. characters to be written and read without any advantage from this.
  3366.  
  3367. By: Linus Torvalds ([email protected]), March 10,
  3368. 2022 1:25 pm
  3369. Room: [25]Moderated Discussions
  3370. Adrian ([email protected]) on March 10, 2022 6:33 am wrote:
  3371. >
  3372. > I agree that failing to follow the traditional meaning of these
  3373. operations is bad.
  3374.  
  3375. Well, at least it's not IBM.
  3376.  
  3377. The company where NIH was a way of life, and vowels were an enemy to be
  3378. defeated.
  3379.  
  3380. Bit 0 is the left-most (ie most significant) bit, of course, so it means
  3381. different things depending on context (ie when loading a word from memory
  3382. "bit 0 of the loaded word" means the high bit of the word, and is loaded
  3383. into bit 32 of the 64-bit register, with bits 0:31 being filled with a
  3384. copy of it).
  3385.  
  3386. "I'm not wrong - it's the rest of the world that is confused" is an IBM
  3387. motto.
  3388.  
  3389. W u mny ltrs whn f d th trck?
  3390.  
  3391. Linus
  3392.  
  3393. By: Ian Ameline ([email protected]), March 10, 2022 3:34 pm
  3394. Room: [25]Moderated Discussions
  3395. Linus Torvalds ([email protected]) on March 10,
  3396. 2022 12:25 pm wrote:
  3397. > Adrian ([email protected]) on March 10, 2022 6:33 am wrote:
  3398. > >
  3399. > > I agree that failing to follow the traditional meaning of these
  3400. operations is bad.
  3401. >
  3402. > Well, at least it's not IBM.
  3403. >
  3404. > The company where NIH was a way of life, and vowels were an enemy to be
  3405. defeated.
  3406. >
  3407. > Bit 0 is the left-most (ie most significant) bit, of course, so it means
  3408. different things depending on
  3409. > context (ie when loading a word from memory "bit 0 of the loaded word"
  3410. means the high bit of the word,
  3411. > and is loaded into bit 32 of the 64-bit register, with bits 0:31 being
  3412. filled with a copy of it).
  3413. >
  3414. > "I'm not wrong - it's the rest of the world that is confused" is an IBM
  3415. motto.
  3416. >
  3417. > W u mny ltrs whn f d th trck?
  3418. >
  3419. > Linus
  3420.  
  3421. When I worked at IBM on compilers (x86 optimizing back-end), there was one
  3422. very senior compiler code generation guru (who shall remain nameless) who
  3423. used to frequently ( and loudly) say that someone was "full of shit" if he
  3424. or she disagreed with his positions. Eventually HR got involved and
  3425. suggested he use the term "confused" instead of "full of shit". From then
  3426. on everyone used "confused", and everyone knew it meant "full of shit".
  3427. :-) So whenever I hear someone from IBM (especially the research division)
  3428. use the term "confused", I know what they really mean. :-)
  3429.  
  3430. By: gallier2 ([email protected]), March 11, 2022 12:42 am
  3431. Room: [25]Moderated Discussions
  3432. Linus Torvalds ([email protected]) on March 10,
  3433. 2022 12:25 pm wrote:
  3434. > Adrian ([email protected]) on March 10, 2022 6:33 am wrote:
  3435. > >
  3436. > > I agree that failing to follow the traditional meaning of these
  3437. operations is bad.
  3438. >
  3439. > Well, at least it's not IBM.
  3440. >
  3441. > The company where NIH was a way of life, and vowels were an enemy to be
  3442. defeated.
  3443. >
  3444. > Bit 0 is the left-most (ie most significant) bit, of course, so it means
  3445. different things depending on
  3446. > context (ie when loading a word from memory "bit 0 of the loaded word"
  3447. means the high bit of the word,
  3448. > and is loaded into bit 32 of the 64-bit register, with bits 0:31 being
  3449. filled with a copy of it).
  3450.  
  3451. Texas Instruments also has the Bit0 as highest bit, which is really a
  3452. stupid convention as depending on the bus width can designate completely
  3453. different lines (see TI-99/4A documentation).
  3454.  
  3455. >
  3456. > "I'm not wrong - it's the rest of the world that is confused" is an IBM
  3457. motto.
  3458. >
  3459. > W u mny ltrs whn f d th trck?
  3460. >
  3461. > Linus
  3462.  
  3463. By: konrad.schwarz ([email protected]), March 11, 2022 5:26 am
  3464. Room: [25]Moderated Discussions
  3465. Linus Torvalds ([email protected]) on March 10,
  3466. 2022 12:25 pm wrote:
  3467. > Bit 0 is the left-most (ie most significant) bit, of course, so it means
  3468. different things depending on
  3469. > context (ie when loading a word from memory "bit 0 of the loaded word"
  3470. means the high bit of the word,
  3471. > and is loaded into bit 32 of the 64-bit register, with bits 0:31 being
  3472. filled with a copy of it).
  3473.  
  3474. The IBM bit-numbering convention is logically consistent with big-endian
  3475. addressing
  3476. of multi-byte integers.
  3477.  
  3478. A big-endian machine places the most-significant byte (or minimal
  3479. addressable storage unit)
  3480. at offset 0 from the start of the word, with consecutively less
  3481. significant digits
  3482. placed in successively higher offsets.
  3483.  
  3484. The same rule is applied to bits.
  3485.  
  3486. Mathematically, this is the difference between denoting a fixed length
  3487. polynomial as
  3488.  
  3489. n i n (n - i)
  3490. sum a x vs. sum a x
  3491. i = 0 i i = 0 i
  3492.  
  3493. and I've seen mathematicians use the second notation. It in fact
  3494. matches western numerical conventions (most significant digits come first
  3495. when reading from left to right).
  3496.  
  3497. The disadvantage of big-endian is that you have to know n beforehand;
  3498. accessing a variable with incorrect size will lead to completely
  3499. false results, whereas if the values taken by the variable happen
  3500. to require fewer words than allocated, little endian machines
  3501. will still see the correct values.
  3502.  
  3503. The advantage of big-endian is that memory dumps are much easier
  3504. to scan & decipher for humans trained to use western numbers.
  3505.  
  3506. By: konrad.schwarz ([email protected]), March 11, 2022 5:31 am
  3507. Room: [25]Moderated Discussions
  3508. Improved ASCII math:
  3509.  
  3510. n i n (n - i)
  3511. sum a x vs. sum a x
  3512. i = 0 i i = 0 i
  3513.  
  3514. By: Adrian ([email protected]), March 11, 2022 6:25 am
  3515. Room: [25]Moderated Discussions
  3516. konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3517. wrote:
  3518. > Linus Torvalds ([email protected]) on March 10,
  3519. 2022 12:25 pm wrote:
  3520. > > Bit 0 is the left-most (ie most significant) bit, of course, so it
  3521. means different things depending on
  3522. > > context (ie when loading a word from memory "bit 0 of the loaded word"
  3523. means the high bit of the word,
  3524. > > and is loaded into bit 32 of the 64-bit register, with bits 0:31 being
  3525. filled with a copy of it).
  3526. >
  3527. > The IBM bit-numbering convention is logically consistent with big-endian
  3528. addressing
  3529. > of multi-byte integers.
  3530. >
  3531. > A big-endian machine places the most-significant byte (or minimal
  3532. addressable storage unit)
  3533. > at offset 0 from the start of the word, with consecutively less
  3534. significant digits
  3535. > placed in successively higher offsets.
  3536. >
  3537. > The same rule is applied to bits.
  3538. >
  3539. > Mathematically, this is the difference between denoting a fixed length
  3540. polynomial as
  3541. >
  3542. > n i n (n - i)
  3543. > sum a x vs. sum a x
  3544. > i = 0 i i = 0 i
  3545. >
  3546. > and I've seen mathematicians use the second notation. It in fact
  3547. > matches western numerical conventions (most significant digits come
  3548. first
  3549. > when reading from left to right).
  3550. >
  3551. > The disadvantage of big-endian is that you have to know n beforehand;
  3552. > accessing a variable with incorrect size will lead to completely
  3553. > false results, whereas if the values taken by the variable happen
  3554. > to require fewer words than allocated, little endian machines
  3555. > will still see the correct values.
  3556. >
  3557. > The advantage of big-endian is that memory dumps are much easier
  3558. > to scan & decipher for humans trained to use western numbers.
  3559.  
  3560. Yes, even if I consider little-endian as more convenient, I have always
  3561. appreciated IBM for being consistently big-endian.
  3562.  
  3563. I believe that the worst are the CPU architectures that are big-endian,
  3564. but which number the bits in reverse order, with bit 0 as the LSB (e.g.
  3565. Motorola).
  3566.  
  3567. By: cqwrteur ([email protected]), March 11, 2022 12:57 pm
  3568. Room: [25]Moderated Discussions
  3569. Adrian ([email protected]) on March 11, 2022 5:25 am wrote:
  3570. > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3571. wrote:
  3572. > > Linus Torvalds ([email protected]) on March
  3573. 10, 2022 12:25 pm wrote:
  3574. > > > Bit 0 is the left-most (ie most significant) bit, of course, so it
  3575. means different things depending on
  3576. > > > context (ie when loading a word from memory "bit 0 of the loaded
  3577. word" means the high bit of the word,
  3578. > > > and is loaded into bit 32 of the 64-bit register, with bits 0:31
  3579. being filled with a copy of it).
  3580. > >
  3581. > > The IBM bit-numbering convention is logically consistent with
  3582. big-endian addressing
  3583. > > of multi-byte integers.
  3584. > >
  3585. > > A big-endian machine places the most-significant byte (or minimal
  3586. addressable storage unit)
  3587. > > at offset 0 from the start of the word, with consecutively less
  3588. significant digits
  3589. > > placed in successively higher offsets.
  3590. > >
  3591. > > The same rule is applied to bits.
  3592. > >
  3593. > > Mathematically, this is the difference between denoting a fixed length
  3594. polynomial as
  3595. > >
  3596. > > n i n (n - i)
  3597. > > sum a x vs. sum a x
  3598. > > i = 0 i i = 0 i
  3599. > >
  3600. > > and I've seen mathematicians use the second notation. It in fact
  3601. > > matches western numerical conventions (most significant digits come
  3602. first
  3603. > > when reading from left to right).
  3604. > >
  3605. > > The disadvantage of big-endian is that you have to know n beforehand;
  3606. > > accessing a variable with incorrect size will lead to completely
  3607. > > false results, whereas if the values taken by the variable happen
  3608. > > to require fewer words than allocated, little endian machines
  3609. > > will still see the correct values.
  3610. > >
  3611. > > The advantage of big-endian is that memory dumps are much easier
  3612. > > to scan & decipher for humans trained to use western numbers.
  3613. >
  3614. >
  3615. > Yes, even if I consider little-endian as more convenient, I have
  3616. > always appreciated IBM for being consistently big-endian.
  3617. >
  3618. > I believe that the worst are the CPU architectures that are big-endian,
  3619. but which
  3620. > number the bits in reverse order, with bit 0 as the LSB (e.g. Motorola).
  3621. >
  3622. >
  3623. >
  3624. >
  3625. >
  3626. >
  3627.  
  3628. LOL. This forum complains about Risc-V being madness when rust is a truly
  3629. garbage which is 10000000000000x worse than Risc-v with CVE plagued.
  3630.  
  3631. HAHA. what a bunch of hypocrite. Probably C and C++ violate human rights?
  3632.  
  3633. By: Linus Torvalds ([email protected]), March 11,
  3634. 2022 1:28 pm
  3635. Room: [25]Moderated Discussions
  3636. konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3637. wrote:
  3638. >
  3639. > The IBM bit-numbering convention is logically consistent with big-endian
  3640. addressing
  3641. > of multi-byte integers.
  3642.  
  3643. It's actually not.
  3644.  
  3645. It's only consistent in documentation.
  3646.  
  3647. When you write out special register bits, and you do the usual arabic
  3648. numeral-inspired ordering, then numbering 0 at the left makes sense.
  3649.  
  3650. But then when actually writing code and running code, suddenly the bit
  3651. ordering doesn't make any sense at all when you start shifting bits
  3652. around. Not in memory, and not in registers.
  3653.  
  3654. Starting at MSB doesn't make sense in an ALU either. Arguably the most
  3655. fundamental of all operations - add - goes from LSB to MSB.
  3656.  
  3657. It's not just that "least significant bit is well-defined from an
  3658. addressing standpoint" (both in memory and in registers and in the ALU),
  3659. but it's also that small integers are way more fundamental than large
  3660. ones. Even IBM makes it easier to add by 1, than to add by the MSB. And
  3661. that's despite the architecture having special instructions to generate
  3662. bitmasks.
  3663.  
  3664. There's a reason C people use "1 << shift" to generate bitmasks. And no,
  3665. that reason is not "it's a C idiom". It's deeper than that. It goes to the
  3666. whole fundamental issue of "1" being a very very special number (not just
  3667. in computers, in mathematics).
  3668.  
  3669. You can argue that big-endian byte ordering is dying out due to market
  3670. pressure. But big-endian bit ordering is just fundamentally wrong.
  3671.  
  3672. (I will also argue that big-endian byte ordering is also inferior, and it
  3673. wasn't just market forces, but that argument is decades old and nobody
  3674. ever won it apart from a "the market decided". But I think that
  3675. "big-endian bit ordering doesn't make sense" is actually part of the whole
  3676. "big-endian byte ordering was a failure").
  3677.  
  3678. And yes, arabic numerals positioning system is odd too. And no, "Arabic is
  3679. written right-to-left" doesn't explain it either, since it came from
  3680. India. But you can see the numeral order oddities when you line up numbers
  3681. (right-justified, because LSB is fundamentally more important), and in
  3682. various languages too (ie "five and twenty" in German, or even "fifteen"
  3683. in English).
  3684.  
  3685. Big-endian: just say no.
  3686.  
  3687. Linus
  3688.  
  3689. By: hobold ([email protected]), March 11, 2022 5:29 pm
  3690. Room: [25]Moderated Discussions
  3691. Linus Torvalds ([email protected]) on March 11,
  3692. 2022 12:28 pm wrote:
  3693. [...]
  3694. > And no, "Arabic is written right-to-left"
  3695. > doesn't explain it either, since it came from India.
  3696.  
  3697. It does explain some of the confusion. Decimal integers kind of have an
  3698. invisible/implied decimal point next to their least significant digit,
  3699. which anchors the positional scale factor of each digit. That anchor is
  3700. usually to the right of the decimal integer (in English and other European
  3701. languages).
  3702.  
  3703. If the number in question is a decimal fraction however, then the integral
  3704. part and the fractional part are both anchored at the decimal point, and
  3705. kind of have different reading directions.
  3706.  
  3707. The few languages I know (all closely related of the Indo-European family)
  3708. acknowledge this by using redundant words like "million", "thousand", etc.
  3709. to give additional positional landmarks when speaking integer numbers (or
  3710. the integral part) from left to right, but only list digits when speaking
  3711. the fractional part (from left to right) after the decimal point. That is,
  3712. when the direction of text and the direction of numbers happen to both
  3713. align to what the speaker is used to, then no redundancy is required for
  3714. clarification.
  3715.  
  3716. If you store a short ASCII string in a multibyte register, then the
  3717. reading direction of a little endian integer value is different from the
  3718. reading direction of a text string.
  3719.  
  3720. In other words, if we all used scientific notation of numbers all the
  3721. time, then big endian would look as if it were the "natural" byte order
  3722. wherever European languages dominate. Except for the integral exponent
  3723. when it is larger than a single byte. :-)
  3724.  
  3725. By: RIIR ([email protected]), March 11, 2022 8:19 pm
  3726. Room: [25]Moderated Discussions
  3727. hobold ([email protected]) on March 11, 2022 4:29 pm
  3728. wrote:
  3729. > Linus Torvalds ([email protected]) on March 11,
  3730. 2022 12:28 pm wrote:
  3731. > [...]
  3732. > > And no, "Arabic is written right-to-left"
  3733. > > doesn't explain it either, since it came from India.
  3734. >
  3735. > It does explain some of the confusion. Decimal integers kind of have an
  3736. invisible/implied decimal point
  3737. > next to their least significant digit, which anchors the positional
  3738. scale factor of each digit. That
  3739. > anchor is usually to the right of the decimal integer (in English and
  3740. other European languages).
  3741. >
  3742. > If the number in question is a decimal fraction however, then the
  3743. integral part and the fractional
  3744. > part are both anchored at the decimal point, and kind of have different
  3745. reading directions.
  3746. >
  3747. > The few languages I know (all closely related of the Indo-European
  3748. family) acknowledge this by using redundant
  3749. > words like "million", "thousand", etc. to give additional positional
  3750. landmarks when speaking integer numbers
  3751. > (or the integral part) from left to right, but only list digits when
  3752. speaking the fractional part (from left
  3753. > to right) after the decimal point. That is, when the direction of text
  3754. and the direction of numbers happen
  3755. > to both align to what the speaker is used to, then no redundancy is
  3756. required for clarification.
  3757. >
  3758. > If you store a short ASCII string in a multibyte register, then the
  3759. reading direction of
  3760. > a little endian integer value is different from the reading direction of
  3761. a text string.
  3762. >
  3763. > In other words, if we all used scientific notation of numbers all the
  3764. time, then big
  3765. > endian would look as if it were the "natural" byte order wherever
  3766. European languages
  3767. > dominate. Except for the integral exponent when it is larger than a
  3768. single byte. :-)
  3769.  
  3770. C and C++ violate human rights. Deal with it.
  3771.  
  3772. Rewrite Linux kernel in Rust.
  3773.  
  3774. RIIR
  3775.  
  3776. By: anonymou5 ([email protected]), March 12, 2022 2:48 am
  3777. Room: [25]Moderated Discussions
  3778. RIIR ([email protected]) on March 11, 2022 7:19 pm wrote:
  3779. > C and C++ violate human rights. Deal with it.
  3780. >
  3781. > Rewrite Linux kernel in Rust.
  3782.  
  3783. when supergluing your hands to your keyboard in protest, don't inhale the
  3784. fumes ;-)
  3785.  
  3786. By: Konrad Schwarz ([email protected]), March 12, 2022 2:31 am
  3787. Room: [25]Moderated Discussions
  3788. Linus Torvalds ([email protected]) on March 11,
  3789. 2022 12:28 pm wrote:
  3790. > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3791. wrote:
  3792. > >
  3793. > > The IBM bit-numbering convention is logically consistent with
  3794. big-endian addressing
  3795. > > of multi-byte integers.
  3796. >
  3797. > It's actually not.
  3798. >
  3799. > It's only consistent in documentation.
  3800. >
  3801. > When you write out special register bits, and you do the usual arabic
  3802. > numeral-inspired ordering, then numbering 0 at the left makes sense.
  3803. >
  3804. > But then when actually writing code and running code, suddenly the bit
  3805. ordering doesn't make
  3806. > any sense at all when you start shifting bits around. Not in memory, and
  3807. not in registers.
  3808.  
  3809. It's unfortunate that my ASCII math drawing came out so poorly in HTML.
  3810. The key point is that in the big-endian notation for the polynomial,
  3811. the coefficient has index i, whereas the exponent has the value (n - i).
  3812.  
  3813. To work in a big-endian system, you have to know the size of the integer
  3814. beforehand.
  3815.  
  3816. Of course, you ultimately have to know this in a little-endian system too,
  3817. so
  3818. this is not a fundamental disadvantage of a big-endian system.
  3819.  
  3820. In practice, to make documentation and code match, in a big-endian
  3821. system, you need to introduce a macro that converts documented
  3822. bit number `i' into shift-width `(n - i)'.
  3823.  
  3824. > Starting at MSB doesn't make sense in an ALU either. Arguably the
  3825. > most fundamental of all operations - add - goes from LSB to MSB.
  3826. >
  3827. > It's not just that "least significant bit is well-defined from an
  3828. addressing standpoint" (both
  3829. > in memory and in registers and in the ALU), but it's also that small
  3830. integers are way more
  3831. > fundamental than large ones. Even IBM makes it easier to add by 1, than
  3832. to add by the MSB.
  3833. > And that's despite the architecture having special instructions to
  3834. generate bitmasks.
  3835.  
  3836. This completely irrelevant to the numbering convention used to identify
  3837. digits.
  3838.  
  3839. > There's a reason C people use "1 of "1" being a very very special number
  3840. (not just in computers, in mathematics).
  3841.  
  3842. I realize of course that on a RISC-style machine the size of literals
  3843. is limited and that smaller literals can often be more compactly encoded.
  3844.  
  3845. However, numbering the most significant bit `zero' doesn't actually
  3846. change any of the values used, except if the hardware designer happens
  3847. to fill hardware registers from the most significant bit downwards;
  3848. and even then, the literals available to shift instructions encompass
  3849. the word size in bits -- but immediate fields for boolean instructions
  3850. are not so lucky.
  3851.  
  3852. By: rwessel ([email protected]), March 12, 2022 7:04 am
  3853. Room: [25]Moderated Discussions
  3854. Konrad Schwarz ([email protected]) on March 12, 2022 1:31 am
  3855. wrote:
  3856. > Linus Torvalds ([email protected]) on March 11,
  3857. 2022 12:28 pm wrote:
  3858. > > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3859. wrote:
  3860. > > >
  3861. > > > The IBM bit-numbering convention is logically consistent with
  3862. big-endian addressing
  3863. > > > of multi-byte integers.
  3864. > >
  3865. > > It's actually not.
  3866. > >
  3867. > > It's only consistent in documentation.
  3868. > >
  3869. > > When you write out special register bits, and you do the usual arabic
  3870. > > numeral-inspired ordering, then numbering 0 at the left makes sense.
  3871. > >
  3872. > > But then when actually writing code and running code, suddenly the bit
  3873. ordering doesn't make
  3874. > > any sense at all when you start shifting bits around. Not in memory,
  3875. and not in registers.
  3876. >
  3877. > It's unfortunate that my ASCII math drawing came out so poorly in HTML.
  3878. > The key point is that in the big-endian notation for the polynomial,
  3879. > the coefficient has index i, whereas the exponent has the value (n - i).
  3880. >
  3881. > To work in a big-endian system, you have to know the size of the integer
  3882. beforehand.
  3883. >
  3884. > Of course, you ultimately have to know this in a little-endian system
  3885. too, so
  3886. > this is not a fundamental disadvantage of a big-endian system.
  3887. >
  3888. > In practice, to make documentation and code match, in a big-endian
  3889. > system, you need to introduce a macro that converts documented
  3890. > bit number `i' into shift-width `(n - i)'.
  3891. >
  3892. > > Starting at MSB doesn't make sense in an ALU either. Arguably the
  3893. > > most fundamental of all operations - add - goes from LSB to MSB.
  3894. > >
  3895. > > It's not just that "least significant bit is well-defined from an
  3896. addressing standpoint" (both
  3897. > > in memory and in registers and in the ALU), but it's also that small
  3898. integers are way more
  3899. > > fundamental than large ones. Even IBM makes it easier to add by 1,
  3900. than to add by the MSB.
  3901. > > And that's despite the architecture having special instructions to
  3902. generate bitmasks.
  3903. >
  3904. > This completely irrelevant to the numbering convention used to identify
  3905. digits.
  3906. >
  3907. > > There's a reason C people use "1 of "1" being a very very
  3908. > > special number (not just in computers, in mathematics).
  3909. >
  3910. > I realize of course that on a RISC-style machine the size of literals
  3911. > is limited and that smaller literals can often be more compactly
  3912. encoded.
  3913. >
  3914. > However, numbering the most significant bit `zero' doesn't actually
  3915. > change any of the values used, except if the hardware designer happens
  3916. > to fill hardware registers from the most significant bit downwards;
  3917. > and even then, the literals available to shift instructions encompass
  3918. > the word size in bits -- but immediate fields for boolean instructions
  3919. > are not so lucky.
  3920.  
  3921. On Z there are a few (new-ish) bit manipulation instructions that expose
  3922. the nominal bit order*, at least to an extent. Arguably some of the vector
  3923. instructions do as well, when addressing individual elements of the
  3924. vectors.
  3925.  
  3926. In some cases that's only a definitional matter - Find Leftmost One is
  3927. defined to return the bit position of the first one bit - which happens to
  3928. be exactly the same value as returned by (say) x86 count-leading-zeros.
  3929.  
  3930. But for the most part, it's not really visible (obviously the overall
  3931. big-endian architecture is, but the bit number, not so much).
  3932.  
  3933. *For example, in Rotate Then Insert Selected Bits the fourth and fifth
  3934. operands specify the starting and ending bit position to copy from the
  3935. second to first operand after the rotation of the first operand as
  3936. specified by the third operand.
  3937.  
  3938. By: dmcq ([email protected]), March 12, 2022 12:18 pm
  3939. Room: [25]Moderated Discussions
  3940. Linus Torvalds ([email protected]) on March 11,
  3941. 2022 12:28 pm wrote:
  3942. > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  3943. wrote:
  3944. > >
  3945. > > The IBM bit-numbering convention is logically consistent with
  3946. big-endian addressing
  3947. > > of multi-byte integers.
  3948. >
  3949. > It's actually not.
  3950. >
  3951. > It's only consistent in documentation.
  3952. >
  3953. > When you write out special register bits, and you do the usual arabic
  3954. > numeral-inspired ordering, then numbering 0 at the left makes sense.
  3955. >
  3956. > But then when actually writing code and running code, suddenly the bit
  3957. ordering doesn't make
  3958. > any sense at all when you start shifting bits around. Not in memory, and
  3959. not in registers.
  3960. >
  3961. > Starting at MSB doesn't make sense in an ALU either. Arguably the
  3962. > most fundamental of all operations - add - goes from LSB to MSB.
  3963. >
  3964. > It's not just that "least significant bit is well-defined from an
  3965. addressing standpoint" (both
  3966. > in memory and in registers and in the ALU), but it's also that small
  3967. integers are way more
  3968. > fundamental than large ones. Even IBM makes it easier to add by 1, than
  3969. to add by the MSB.
  3970. > And that's despite the architecture having special instructions to
  3971. generate bitmasks.
  3972. >
  3973. > There's a reason C people use "1 < is not "it's a C idiom". It's deeper
  3974. than that. It goes to the whole fundamental issue
  3975. > of "1" being a very very special number (not just in computers, in
  3976. mathematics).
  3977. >
  3978. > You can argue that big-endian byte ordering is dying out due to market
  3979. > pressure. But big-endian bit ordering is just fundamentally wrong.
  3980. >
  3981. > (I will also argue that big-endian byte ordering is also inferior, and
  3982. it wasn't just market forces, but that
  3983. > argument is decades old and nobody ever won it apart from a "the market
  3984. decided". But I think that "big-endian
  3985. > bit ordering doesn't make sense" is actually part of the whole
  3986. "big-endian byte ordering was a failure").
  3987. >
  3988. > And yes, arabic numerals positioning system is odd too. And no, "Arabic
  3989. is written right-to-left"
  3990. > doesn't explain it either, since it came from India. But you can see the
  3991. numeral order oddities
  3992. > when you line up numbers (right-justified, because LSB is fundamentally
  3993. more important), and in
  3994. > various languages too (ie "five and twenty" in German, or even "fifteen"
  3995. in English).
  3996. >
  3997. > Big-endian: just say no.
  3998. >
  3999. > Linus
  4000.  
  4001. I've done quite a bit of IBM assembler amongst others, and I never felt
  4002. any problem with their documentation. It's the one's that list ascending
  4003. bytes or words from left to right but number the bits right to left that
  4004. annoy me.
  4005.  
  4006. By: ** ([email protected]), March 12, 2022 2:20 pm
  4007. Room: [25]Moderated Discussions
  4008. Linus Torvalds ([email protected]) on March 11,
  4009. 2022 12:28 pm wrote:
  4010. > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  4011. wrote:
  4012. > >
  4013. > > The IBM bit-numbering convention is logically consistent with
  4014. big-endian addressing
  4015. > > of multi-byte integers.
  4016. >
  4017. > It's actually not.
  4018. >
  4019. > It's only consistent in documentation.
  4020. >
  4021. > When you write out special register bits, and you do the usual arabic
  4022. > numeral-inspired ordering, then numbering 0 at the left makes sense.
  4023. >
  4024. > But then when actually writing code and running code, suddenly the bit
  4025. ordering doesn't make
  4026. > any sense at all when you start shifting bits around. Not in memory, and
  4027. not in registers.
  4028. >
  4029. > Starting at MSB doesn't make sense in an ALU either. Arguably the
  4030. > most fundamental of all operations - add - goes from LSB to MSB.
  4031. >
  4032. > It's not just that "least significant bit is well-defined from an
  4033. addressing standpoint" (both
  4034. > in memory and in registers and in the ALU), but it's also that small
  4035. integers are way more
  4036. > fundamental than large ones. Even IBM makes it easier to add by 1, than
  4037. to add by the MSB.
  4038. > And that's despite the architecture having special instructions to
  4039. generate bitmasks.
  4040. >
  4041. > There's a reason C people use "1 of "1" being a very very special number
  4042. (not just in computers, in mathematics).
  4043. >
  4044. > You can argue that big-endian byte ordering is dying out due to market
  4045. > pressure. But big-endian bit ordering is just fundamentally wrong.
  4046. >
  4047. > (I will also argue that big-endian byte ordering is also inferior, and
  4048. it wasn't just market forces, but that
  4049. > argument is decades old and nobody ever won it apart from a "the market
  4050. decided". But I think that "big-endian
  4051. > bit ordering doesn't make sense" is actually part of the whole
  4052. "big-endian byte ordering was a failure").
  4053. >
  4054. > And yes, arabic numerals positioning system is odd too. And no, "Arabic
  4055. is written right-to-left"
  4056. > doesn't explain it either, since it came from India. But you can see the
  4057. numeral order oddities
  4058. > when you line up numbers (right-justified, because LSB is fundamentally
  4059. more important), and in
  4060. > various languages too (ie "five and twenty" in German, or even "fifteen"
  4061. in English).
  4062. >
  4063. > Big-endian: just say no.
  4064. >
  4065. > Linus
  4066.  
  4067. I guess, the above text is just another attempt to "rant" against
  4068. something, without touching what is fundamental.
  4069.  
  4070. Any ordering (any permutation) of bits inside of an 8-bit byte (including
  4071. a predefined/static random ordering) is OK as long as the machine
  4072. instruction is a single-cycle instruction. This includes ADD, SUB, CMP,
  4073. MOV, SHL and SHR instructions.
  4074.  
  4075. Bit-order and byte-order only matters for multi-cycle instructions.
  4076. Obviously, it matters for arbitrary-precision numbers.
  4077.  
  4078. A single-cycle machine instruction does not care about bit-order neither
  4079. about byte-order as long as the number of bits (the width of the
  4080. instruction's operands) is a constant/fixed quantity that is known in
  4081. advance and as long as the positions of bits and bytes in the operands are
  4082. known in advance.
  4083.  
  4084. The bit-order and byte-order of numbers not larger than 64 bit (that is:
  4085. int8_t, uint32_t, etc) is only helping the people reading, writing,
  4086. manipulating the numbers or working with the numbers (that is:
  4087. programmers, CPU designers, etc) - it doesn't matter to the machine.
  4088.  
  4089. For example, a CPU's physical register file could, in principle, be using
  4090. any particular random bit order (any permutation of bit positions inside
  4091. of a byte, any permutation of bytes inside of a word).
  4092.  
  4093. ----
  4094.  
  4095. Secondly, the subject that seems to be completely escaping your attention
  4096. is that the profitability/fitness/usefulness of a bit ordering is,
  4097. intuitively, very closely tied to compressibility: the more the data is
  4098. compressed, the less a particular bit ordering matters.
  4099.  
  4100. -atom
  4101.  
  4102. By: Heikki Kultala ([email protected]), March 13, 2022
  4103. 12:28 am
  4104. Room: [25]Moderated Discussions
  4105. ** ([email protected]) on March 12, 2022 1:20 pm wrote:
  4106. > Linus Torvalds ([email protected]) on March 11,
  4107. 2022 12:28 pm wrote:
  4108. > > konrad.schwarz ([email protected]) on March 11, 2022 4:26 am
  4109. wrote:
  4110. > > >
  4111. > > > The IBM bit-numbering convention is logically consistent with
  4112. big-endian addressing
  4113. > > > of multi-byte integers.
  4114. > >
  4115. > > It's actually not.
  4116. > >
  4117. > > It's only consistent in documentation.
  4118. > >
  4119. > > When you write out special register bits, and you do the usual arabic
  4120. > > numeral-inspired ordering, then numbering 0 at the left makes sense.
  4121. > >
  4122. > > But then when actually writing code and running code, suddenly the bit
  4123. ordering doesn't make
  4124. > > any sense at all when you start shifting bits around. Not in memory,
  4125. and not in registers.
  4126. > >
  4127. > > Starting at MSB doesn't make sense in an ALU either. Arguably the
  4128. > > most fundamental of all operations - add - goes from LSB to MSB.
  4129. > >
  4130. > > It's not just that "least significant bit is well-defined from an
  4131. addressing standpoint" (both
  4132. > > in memory and in registers and in the ALU), but it's also that small
  4133. integers are way more
  4134. > > fundamental than large ones. Even IBM makes it easier to add by 1,
  4135. than to add by the MSB.
  4136. > > And that's despite the architecture having special instructions to
  4137. generate bitmasks.
  4138. > >
  4139. > > There's a reason C people use "1 of "1" being a very very
  4140. > > special number (not just in computers, in mathematics).
  4141. > >
  4142. > > You can argue that big-endian byte ordering is dying out due to market
  4143. > > pressure. But big-endian bit ordering is just fundamentally wrong.
  4144. > >
  4145. > > (I will also argue that big-endian byte ordering is also
  4146. > > inferior, and it wasn't just market forces, but that
  4147. > > argument is decades old and nobody ever won it apart from
  4148. > > a "the market decided". But I think that "big-endian
  4149. > > bit ordering doesn't make sense" is actually part of the whole
  4150. "big-endian byte ordering was a failure").
  4151. > >
  4152. > > And yes, arabic numerals positioning system is odd too. And no,
  4153. "Arabic is written right-to-left"
  4154. > > doesn't explain it either, since it came from India. But you can see
  4155. the numeral order oddities
  4156. > > when you line up numbers (right-justified, because LSB is
  4157. fundamentally more important), and in
  4158. > > various languages too (ie "five and twenty" in German, or even
  4159. "fifteen" in English).
  4160. > >
  4161. > > Big-endian: just say no.
  4162. > >
  4163. > > Linus
  4164. >
  4165. > I guess, the above text is just another attempt to "rant"
  4166. > against something, without touching what is fundamental.
  4167. >
  4168. > Any ordering (any permutation) of bits inside of an 8-bit byte
  4169. (including a predefined/static
  4170. > random ordering) is OK as long as the machine instruction is a
  4171. single-cycle instruction.
  4172. > This includes ADD, SUB, CMP, MOV, SHL and SHR instructions.
  4173. >
  4174. > Bit-order and byte-order only matters for multi-cycle instructions.
  4175. > Obviously, it matters for arbitrary-precision numbers.
  4176.  
  4177. This is the most clueless claim in this forum during this year.
  4178.  
  4179. Instruction set is an abstraction which should not care about how many
  4180. cycles are spent for execution of an instruction.
  4181.  
  4182. > A single-cycle machine instruction does not care about bit-order neither
  4183. about byte-order as long as
  4184. > the number of bits (the width of the instruction's operands) is a
  4185. constant/fixed quantity that is known
  4186. > in advance and as long as the positions of bits and bytes in the
  4187. operands are known in advance.
  4188.  
  4189. .. which is an insanely stupid assumption.
  4190.  
  4191. Generic memcpy routines are used to copy ALL DATA TYPES.
  4192.  
  4193. Same file IO load/store routines are used for ALL DATA TYPES
  4194.  
  4195. etc.
  4196.  
  4197. By: Joern Engel ([email protected]), March 13, 2022 12:08
  4198. am
  4199. Room: [25]Moderated Discussions
  4200. Linus Torvalds ([email protected]) on March 11,
  4201. 2022 12:28 pm wrote:
  4202. > and in
  4203. > various languages too (ie "five and twenty" in German, or even "fifteen"
  4204. in English).
  4205.  
  4206. Actually, some older English books use the German order as well. It
  4207. appears as if most European languages were confused on that issue and it
  4208. is a relatively recent development that most languages use big-endian
  4209. order and base-10. Mostly. German is pdp-endian or something similar and
  4210. French with "four-score ten and seven" is just weird. Official French at
  4211. least, some dialects are less weird.
  4212.  
  4213. > Big-endian: just say no.
  4214.  
  4215. Should we use numbers like "five and twenty and three hundred and four
  4216. thousand" now? It would be consistent. ;)
  4217.  
  4218. By: Heikki Kultala ([email protected]), March 13, 2022
  4219. 12:31 am
  4220. Room: [25]Moderated Discussions
  4221. Joern Engel ([email protected]) on March 12, 2022 11:08 pm
  4222. wrote:
  4223. > Linus Torvalds ([email protected]) on March 11,
  4224. 2022 12:28 pm wrote:
  4225. > > and in
  4226. > > various languages too (ie "five and twenty" in German, or even
  4227. "fifteen" in English).
  4228. >
  4229. > Actually, some older English books use the German order as well. It
  4230. appears as if most European languages
  4231. > were confused on that issue and it is a relatively recent development
  4232. that most languages use big-endian
  4233. > order and base-10. Mostly. German is pdp-endian or something similar and
  4234. French with "four-score
  4235. > ten and seven" is just weird. Official French at least, some dialects
  4236. are less weird.
  4237. >
  4238. > > Big-endian: just say no.
  4239. >
  4240. > Should we use numbers like "five and twenty and three hundred
  4241. > and four thousand" now? It would be consistent. ;)
  4242.  
  4243. No need to say those tens , hundreds and thousands when using little
  4244. endian. Can just say only those digits.
  4245.  
  4246. The need to say those is big endian overhead crap.
  4247.  
  4248. By: Anne O. Nymous ([email protected]), March 13, 2022 3:40 am
  4249. Room: [25]Moderated Discussions
  4250. Heikki Kultala ([email protected]) on March 12, 2022
  4251. 11:31 pm wrote:
  4252. > Joern Engel ([email protected]) on March 12, 2022 11:08
  4253. pm wrote:
  4254. > > Linus Torvalds ([email protected]) on March
  4255. 11, 2022 12:28 pm wrote:
  4256. > > > and in
  4257. > > > various languages too (ie "five and twenty" in German, or even
  4258. "fifteen" in English).
  4259. > >
  4260. > > Actually, some older English books use the German order as well. It
  4261. appears as if most European languages
  4262. > > were confused on that issue and it is a relatively recent development
  4263. that most languages use big-endian
  4264. > > order and base-10. Mostly. German is pdp-endian or something similar
  4265. and French with "four-score
  4266. > > ten and seven" is just weird. Official French at least, some dialects
  4267. are less weird.
  4268. > >
  4269. > > > Big-endian: just say no.
  4270. > >
  4271. > > Should we use numbers like "five and twenty and three hundred
  4272. > > and four thousand" now? It would be consistent. ;)
  4273. >
  4274. > No need to say those tens , hundreds and thousands when using little
  4275. endian. Can just say only those digits.
  4276. >
  4277. > The need to say those is big endian overhead crap.
  4278. >
  4279.  
  4280. Not tp derail the discussion, there are quite some uses of numbers where
  4281. order of magnitude is more important than individual positions, so people
  4282. can and will ignore the fine-detail after getting an idea about the order
  4283. of magnitude...
  4284.  
  4285. From a german perspective the Einer vor Zehner inversion is mostly mildly
  4286. weird in transcribing numbers from dictation as you need to wait for the
  4287. zehner before entering/writing the number. My take is that is a left-over
  4288. from a time when numbers were hard and numbers above 10 rarely used, but
  4289. that is based on thin air and a vivid imagination, no science involved ;)
  4290.  
  4291. By: dmcq ([email protected]), March 13, 2022 2:30 pm
  4292. Room: [25]Moderated Discussions
  4293. Heikki Kultala ([email protected]) on March 13, 2022
  4294. 12:31 am wrote:
  4295. > Joern Engel ([email protected]) on March 12, 2022 11:08
  4296. pm wrote:
  4297. > > Linus Torvalds ([email protected]) on March
  4298. 11, 2022 12:28 pm wrote:
  4299. > > > and in
  4300. > > > various languages too (ie "five and twenty" in German, or even
  4301. "fifteen" in English).
  4302. > >
  4303. > > Actually, some older English books use the German order as well. It
  4304. appears as if most European languages
  4305. > > were confused on that issue and it is a relatively recent development
  4306. that most languages use big-endian
  4307. > > order and base-10. Mostly. German is pdp-endian or something similar
  4308. and French with "four-score
  4309. > > ten and seven" is just weird. Official French at least, some dialects
  4310. are less weird.
  4311. > >
  4312. > > > Big-endian: just say no.
  4313. > >
  4314. > > Should we use numbers like "five and twenty and three hundred
  4315. > > and four thousand" now? It would be consistent. ;)
  4316. >
  4317. > No need to say those tens , hundreds and thousands when using little
  4318. endian. Can just say only those digits.
  4319. >
  4320. > The need to say those is big endian overhead crap.
  4321.  
  4322. It makes very little difference what order they are said in sayin 5723 as
  4323. five seven two three or three two seven five are just as informative - or
  4324. uninformative. If one is just interested in the highest two digits and the
  4325. exponent you have to remember an then forget the digits and count the
  4326. number of digits at the same time in little endian mode. In big endian
  4327. mode you get the digits immediately and can then count how mant digits
  4328. follow. Saying hundreds or thousands gets rid of a lot of potential
  4329. errors.
  4330.  
  4331. By: gallier2 ([email protected]), March 14, 2022 8:09 am
  4332. Room: [25]Moderated Discussions
  4333. Joern Engel ([email protected]) on March 13, 2022 12:08 am
  4334. wrote:
  4335. > Linus Torvalds ([email protected]) on March 11,
  4336. 2022 12:28 pm wrote:
  4337. > > and in
  4338. > > various languages too (ie "five and twenty" in German, or even
  4339. "fifteen" in English).
  4340. >
  4341. > Actually, some older English books use the German order as well. It
  4342. appears as if most European languages
  4343. > were confused on that issue and it is a relatively recent development
  4344. that most languages use big-endian
  4345. > order and base-10. Mostly. German is pdp-endian or something similar and
  4346. French with "four-score
  4347. > ten and seven" is just weird. Official French at least, some dialects
  4348. are less weird.
  4349.  
  4350. Blame the Celts, they were the folks counting to twenty. They were
  4351. probably barefoot when they learnt to count. At least leave us the few
  4352. Gallic heritage there is in French.
  4353.  
  4354. >
  4355. > > Big-endian: just say no.
  4356. >
  4357. > Should we use numbers like "five and twenty and three hundred
  4358. > and four thousand" now? It would be consistent. ;)
  4359.  
  4360. By: -.- ([email protected]), March 10, 2022 9:00 pm
  4361. Room: [25]Moderated Discussions
  4362. Heikki Kultala ([email protected]) on March 9, 2022
  4363. 10:31 pm wrote:
  4364. > In common terminology:
  4365. > Conditional move means 3-operand instruction (input, condition, result)
  4366. > Select means 4-operand instruction (Input1, input2, select, result)
  4367.  
  4368. So what would you call a non-destructive 'conditional move'?
  4369. Or if your ISA doesn't support 4-operand instructions, what would a
  4370. 3-operand 'select' be?
  4371.  
  4372. > Gather means vector load from memory with vector addressing.
  4373.  
  4374. So what about a register gather?
  4375.  
  4376. > Shuffle means reordering of data inside the vector registers.
  4377.  
  4378. ARM calls it a 'Table vector lookup'.
  4379. x86 uses both 'shuffle' and 'permute' to describe the operation (even with
  4380. some references to 'index'/'table', e.g. VPERMT2B vs VPERMI2B)
  4381.  
  4382. The one thing certain about software engineering is that no-one can truly
  4383. agree on correct terminology.
  4384.  
  4385. Having said that, I do prefer 'shuffle' and use that myself (and I think
  4386. it's more widely adopted), but there doesn't seem to be a complete
  4387. consensus of its appropriate naming.
  4388.  
  4389. By: Anon ([email protected]), March 10, 2022 9:42 pm
  4390. Room: [25]Moderated Discussions
  4391. -.- ([email protected]) on March 10, 2022 8:00 pm wrote:
  4392. > So what would you call a non-destructive 'conditional move'?
  4393.  
  4394. select
  4395.  
  4396. > Or if your ISA doesn't support 4-operand instructions, what would a
  4397. 3-operand 'select' be?
  4398.  
  4399. cmov
  4400.  
  4401. > So what about a register gather?
  4402.  
  4403. permute
  4404.  
  4405. By: Heikki Kultala ([email protected]), March 10,
  4406. 2022 10:59 pm
  4407. Room: [25]Moderated Discussions
  4408. -.- ([email protected]) on March 10, 2022 8:00 pm wrote:
  4409. > Heikki Kultala ([email protected]) on March 9, 2022
  4410. 10:31 pm wrote:
  4411. > > In common terminology:
  4412. > > Conditional move means 3-operand instruction (input, condition,
  4413. result)
  4414. > > Select means 4-operand instruction (Input1, input2, select, result)
  4415. >
  4416. > So what would you call a non-destructive 'conditional move'?
  4417.  
  4418. select
  4419.  
  4420. > Or if your ISA doesn't support 4-operand instructions, what would a
  4421. 3-operand 'select' be?
  4422.  
  4423. cmov
  4424.  
  4425. > > Gather means vector load from memory with vector addressing.
  4426. >
  4427. > So what about a register gather?
  4428.  
  4429. permute or shuffle
  4430.  
  4431. > The one thing certain about software engineering is that no-one can
  4432. truly agree on correct terminology.
  4433. >
  4434. > Having said that, I do prefer 'shuffle' and use that myself (and I think
  4435. it's more widely
  4436. > adopted), but there doesn't seem to be a complete consensus of its
  4437. appropriate naming.
  4438.  
  4439. That there is multiple terms for same thing is not a problem. The terms
  4440. still always means the same thing.
  4441.  
  4442. That same term is used for DIFFERENT thins is a problem. That adds
  4443. confusion. And that's what RISC-V guys are doing.
  4444.  
  4445. By: -.- ([email protected]), March 11, 2022 1:21 am
  4446. Room: [25]Moderated Discussions
  4447. Heikki Kultala ([email protected]) on March 10, 2022
  4448. 9:59 pm wrote:
  4449. > > So what would you call a non-destructive 'conditional move'?
  4450. >
  4451. > select
  4452. >
  4453. > > Or if your ISA doesn't support 4-operand instructions, what would a
  4454. 3-operand 'select' be?
  4455. >
  4456. > cmov
  4457.  
  4458. Ah, so you'd prefer to give instructions different names depending on if
  4459. they're destructive or not.
  4460.  
  4461. So what would you name a constructive add?
  4462. A destructive add?
  4463.  
  4464. Let me guess: add and accumulate?
  4465.  
  4466. How about constructive and destructive multiply?
  4467.  
  4468. > That there is multiple terms for same thing is not a problem. The terms
  4469. still always means the same thing.
  4470. >
  4471. > That same term is used for DIFFERENT thins is a problem. That
  4472. > adds confusion. And that's what RISC-V guys are doing.
  4473.  
  4474. Well, we're doing a gather, but instead of sourcing from memory, we're
  4475. sourcing from a register (or multiple registers).
  4476. Who said that gather must also source from memory?
  4477.  
  4478. By: rwessel ([email protected]), March 11, 2022 10:56 am
  4479. Room: [25]Moderated Discussions
  4480. -.- ([email protected]) on March 11, 2022 12:21 am wrote:
  4481. > Heikki Kultala ([email protected]) on March 10,
  4482. 2022 9:59 pm wrote:
  4483. > > > So what would you call a non-destructive 'conditional move'?
  4484. > >
  4485. > > select
  4486. > >
  4487. > > > Or if your ISA doesn't support 4-operand instructions, what would a
  4488. 3-operand 'select' be?
  4489. > >
  4490. > > cmov
  4491. >
  4492. > Ah, so you'd prefer to give instructions different names depending on if
  4493. they're destructive or not.
  4494. >
  4495. > So what would you name a constructive add?
  4496. > A destructive add?
  4497. >
  4498. > Let me guess: add and accumulate?
  4499. >
  4500. > How about constructive and destructive multiply?
  4501. >
  4502. > > That there is multiple terms for same thing is not a problem. The
  4503. terms still always means the same thing.
  4504. > >
  4505. > > That same term is used for DIFFERENT thins is a problem. That
  4506. > > adds confusion. And that's what RISC-V guys are doing.
  4507. >
  4508. > Well, we're doing a gather, but instead of sourcing from memory,
  4509. > we're sourcing from a register (or multiple registers).
  4510. > Who said that gather must also source from memory?
  4511.  
  4512. Z has grown many of those over six decades. Three operand cmov ended up as
  4513. load-on-condition (which actually makes a fair bit of sense), select is
  4514. the common four-operand instruction. As S/360 started as a (almost)
  4515. exclusively two-operand ISA, the three operand forms of things like add
  4516. are part of the "distinct operand" facility, and usually get a "K" suffix.
  4517. Thus two-operand add register-to-register is AR, the three-operand form is
  4518. ARK.
  4519.  
  4520. By: Anon ([email protected]), March 11, 2022 12:07 pm
  4521. Room: [25]Moderated Discussions
  4522. -.- ([email protected]) on March 11, 2022 12:21 am wrote:
  4523. > Ah, so you'd prefer to give instructions different names depending on if
  4524. they're destructive or not.
  4525.  
  4526. It makes sense, where they matter.
  4527.  
  4528. And in the case of cmov it matter, because it is a predication, select
  4529. will* always change state, cmov may not change state, add and mul always
  4530. change state.
  4531.  
  4532. * Except when the registers are the same or the values are the same,
  4533. obviously.
  4534.  
  4535. By: -.- ([email protected]), March 11, 2022 9:29 pm
  4536. Room: [25]Moderated Discussions
  4537. Anon ([email protected]) on March 11, 2022 11:07 am wrote:
  4538. > It makes sense, where they matter.
  4539.  
  4540. To you perhaps, but giving out different names for the same action,
  4541. differing only in constructive/destructive behaviour, and only for this
  4542. one instance, seems like weird logic to me.
  4543.  
  4544. Feel free to disagree - the point I'm making is that there can be many
  4545. different opinions out there, and the one you have isn't some universal
  4546. truth.
  4547.  
  4548. By: Andrey ([email protected]), March 10, 2022 9:55 am
  4549. Room: [25]Moderated Discussions
  4550. -.- ([email protected]) on March 9, 2022 5:39 am wrote:
  4551. > Plenty of weird names in many assembly dialects, to be honest.
  4552. > PALIGNR in x86 or EXT in AArch64 aren't obvious unless you already know
  4553. what the instruction does.
  4554. >
  4555. > Perhaps it's time to move away from compact assembly instruction names?
  4556. I'd say the number
  4557. > of people writing assembly is relatively small compared to the number of
  4558. people reading
  4559. > it, and being less compact could help beginners understand the code more
  4560. easily.
  4561. > We're no longer stuck with technology where long names are problematic.
  4562. > We aren't using 80 character wide screens any more.
  4563. > Why not make opcode names longer and more descriptive? You could always
  4564. keep a
  4565. > more compact version to cater to the few assembly writers without
  4566. autocomplete.
  4567. >
  4568. > I just don't see why assembly syntax today still has to follow the
  4569. design principles of ~50 years ago.
  4570.  
  4571. Assembler is still generated by certain compilers as an intermediate
  4572. output. I'm not sure making instructions more verbose would measurably
  4573. affect compile times and resource consumption, but that's still something
  4574. to consider.
  4575.  
  4576. By: Matt Sayler ([email protected]), March 10, 2022 2:56 pm
  4577. Room: [25]Moderated Discussions
  4578. Andrey ([email protected]) on March 10, 2022 8:55 am
  4579. wrote:
  4580. > Assembler is still generated by certain compilers as an intermediate
  4581. output.
  4582. > I'm not sure making instructions more verbose would measurably affect
  4583. compile
  4584. > times and resource consumption, but that's still something to consider.
  4585.  
  4586. Is there any drawback to having two supported names? dense/traditional vs.
  4587. verbose&easier to understand at a glance? At input, either would be
  4588. supported. At output, choose your poison based on preference.
  4589.  
  4590. Surely someone has proposed this before. A quick search didn't turn up
  4591. anything, but I'm positive I've encountered the idea.
  4592.  
  4593. By: Andrey ([email protected]), March 10, 2022 6:01 pm
  4594. Room: [25]Moderated Discussions
  4595. Matt Sayler ([email protected]) on March 10, 2022 1:56 pm
  4596. wrote:
  4597. > Andrey ([email protected]) on March 10, 2022 8:55 am
  4598. wrote:
  4599. > > Assembler is still generated by certain compilers as an intermediate
  4600. output.
  4601. > > I'm not sure making instructions more verbose would measurably affect
  4602. compile
  4603. > > times and resource consumption, but that's still something to
  4604. consider.
  4605. >
  4606. > Is there any drawback to having two supported names?
  4607.  
  4608. Other than doubling the number of instruction names to support and
  4609. remember? That is in addition to other dialect differences we have today
  4610. (e.g. Intel vs. AT&T x86).
  4611.  
  4612. Honestly, I don't think instruction naming is the biggest problem with
  4613. assembler, when it comes to humans reading/writing it. Certainly not
  4614. something that is worth inventing two names per instruction. It'd be
  4615. better if other stuff, like operand order and register, constant and
  4616. addressing mode syntax were better unified. Special syntax like the one
  4617. used for AVX-512 instructions also isn't helping.
  4618.  
  4619. By: Matt Sayler ([email protected]), March 11, 2022 10:10
  4620. am
  4621. Room: [25]Moderated Discussions
  4622. Andrey ([email protected]) on March 10, 2022 5:01 pm
  4623. wrote:
  4624. > Matt Sayler ([email protected]) on March 10, 2022 1:56 pm
  4625. wrote:
  4626. > > Andrey ([email protected]) on March 10, 2022 8:55
  4627. am wrote:
  4628. > > > Assembler is still generated by certain compilers as an intermediate
  4629. output.
  4630. > > > I'm not sure making instructions more verbose would measurably
  4631. affect compile
  4632. > > > times and resource consumption, but that's still something to
  4633. consider.
  4634. > >
  4635. > > Is there any drawback to having two supported names?
  4636. >
  4637. > Other than doubling the number of instruction names to support and
  4638. remember? That is
  4639. > in addition to other dialect differences we have today (e.g. Intel vs.
  4640. AT&T x86).
  4641. >
  4642. > Honestly, I don't think instruction naming is the biggest problem with
  4643. assembler, when it comes to humans
  4644. > reading/writing it. Certainly not something that is worth inventing two
  4645. names per instruction. It'd
  4646. > be better if other stuff, like operand order and register, constant and
  4647. addressing mode syntax were
  4648. > better unified. Special syntax like the one used for AVX-512
  4649. instructions also isn't helping.
  4650.  
  4651. Fair, but as assembly is relegated to narrower use cases over time,
  4652. there's value in separating out the important parts from the merely
  4653. historical ones.
  4654.  
  4655. There's an argument to be made for "systems languages," sure. However, I'm
  4656. just saying the cost of having 2 names for opcodes is minuscule in
  4657. comparison to the costs of everything else. The only question would be:
  4658. does it add anything?
  4659.  
  4660. If I were involved with a new ISA, I'd definitely look into this as part
  4661. of the spec because it feels like low-hanging fruit.
  4662.  
  4663. By: -.- ([email protected]), March 10, 2022 9:03 pm
  4664. Room: [25]Moderated Discussions
  4665. Andrey ([email protected]) on March 10, 2022 8:55 am
  4666. wrote:
  4667. > Assembler is still generated by certain compilers as an intermediate
  4668. output.
  4669. > I'm not sure making instructions more verbose would measurably affect
  4670. compile
  4671. > times and resource consumption, but that's still something to consider.
  4672.  
  4673. Well, if it's anything to go by, there already the x86 instruction,
  4674. VGF2P8AFFINEINVQB, if long instructions would be problematic.
  4675.  
  4676. Of course, if naming is such an issue, the compiler could just jump
  4677. straight to machine code (if it isn't already), or even develop some
  4678. internal compact representation.
  4679. In reality, it's highly unlikely that length of instructions plays any
  4680. significance in compilation time - I'd say optimisation passes probably
  4681. contribute way more.
  4682.  
  4683. By: Andrey ([email protected]), March 11, 2022 4:01 am
  4684. Room: [25]Moderated Discussions
  4685. -.- ([email protected]) on March 10, 2022 8:03 pm wrote:
  4686. > Andrey ([email protected]) on March 10, 2022 8:55 am
  4687. wrote:
  4688. > > Assembler is still generated by certain compilers as an intermediate
  4689. output.
  4690. > > I'm not sure making instructions more verbose would measurably affect
  4691. compile
  4692. > > times and resource consumption, but that's still something to
  4693. consider.
  4694. >
  4695. > Well, if it's anything to go by, there already the x86 instruction,
  4696. > VGF2P8AFFINEINVQB, if long instructions would be problematic.
  4697.  
  4698. How often that instruction appears in the generated code? Compared to
  4699. something like mov, add, mul, cmp, jmp or ret, I don't think it adds much
  4700. weight to the generated output.
  4701.  
  4702. > Of course, if naming is such an issue, the compiler could just jump
  4703. straight to machine
  4704. > code (if it isn't already), or even develop some internal compact
  4705. representation.
  4706.  
  4707. Generating assembler output is a valid design choice that has its pros and
  4708. cons. First and foremost, it allows to reuse the assembler tool, which has
  4709. to be implemented anyway and isn't quite trivial in its own right.
  4710.  
  4711. > In reality, it's highly unlikely that length of instructions plays any
  4712. significance
  4713. > in compilation time - I'd say optimisation passes probably contribute
  4714. way more.
  4715.  
  4716. Probably. Still, I don't find the argument for more verbose instruction
  4717. names compelling enough. There are some more cryptic outliers that could
  4718. be better, but in general I don't find that much of a problem.
  4719.  
  4720. By: sr ([email protected]), March 9, 2022 12:26 pm
  4721. Room: [25]Moderated Discussions
  4722. Heikki Kultala ([email protected]) on March 9, 2022
  4723. 12:35 am wrote:
  4724.  
  4725. > In the V-extension, they have an instruction named "vrgather".
  4726. >
  4727. > But that instruction is not a gather load instruction. This instructoin
  4728. is just a shuffle instruction.
  4729. >
  4730. > What have the guys deciding the naming of these instructions have been
  4731. smoking?
  4732. >
  4733.  
  4734. Risc-V V is vector instruction set, not SIMD instruction set. That
  4735. instruction is better known as load vector index -instruction in vector
  4736. CPU - loads non-continuous data from index register locations into vector
  4737. register. So it is a very powerful gather instruction. Why do you consider
  4738. it just a shuffle instruction?
  4739.  
  4740.  
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!