|
18 | 18 | em{font-style:italic} |
19 | 19 | </style> |
20 | 20 | <h1>#jam:polkadot.io</h1> |
21 | | -<p><small>last updated 2025-06-07 03:32 UTC</small></p> |
| 21 | +<p><small>last updated 2025-06-08 03:38 UTC</small></p> |
22 | 22 | <p><a href='room_log.txt'>⇩ plaintext</a> · <a href='../../'>⇦ all rooms</a></p> |
23 | 23 | <hr> |
24 | 24 | <div class='msg'><a class='ts' href='#$we4SYXTHwmKn094X9Zs_7mWUOoUVh4icvVdxD83RZfs'>#</a> <a class='ts' name='$we4SYXTHwmKn094X9Zs_7mWUOoUVh4icvVdxD83RZfs' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$we4SYXTHwmKn094X9Zs_7mWUOoUVh4icvVdxD83RZfs' target='_blank'>2024-04-20 02:08</a> <span class='u' style='color:#d0709e'>johnjiao123</span>: </div> |
@@ -8822,6 +8822,9 @@ <h1>#jam:polkadot.io</h1> |
8822 | 8822 | <div class='msg reply'><a class='ts' href='#$t_UElO7X7E62QY6vlR8zo9QbuufpNP6HHAUJe3Gf4Zg'>#</a> <a class='ts' name='$t_UElO7X7E62QY6vlR8zo9QbuufpNP6HHAUJe3Gf4Zg' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$t_UElO7X7E62QY6vlR8zo9QbuufpNP6HHAUJe3Gf4Zg' target='_blank'>2025-06-03 13:53</a> <span class='u' style='color:#be2950'>clearloop</span>: hmm, I assume I forgot to sync gas at sort of invocation interactions, debugging the instructions is endless ...</div> |
8823 | 8823 | <div class='msg reply'><a class='ts' href='#$HgSdg9BYqoFFqY9j5CdwESbdxSJDOmf_bcqXrgiAbQw'>#</a> <a class='ts' name='$HgSdg9BYqoFFqY9j5CdwESbdxSJDOmf_bcqXrgiAbQw' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$HgSdg9BYqoFFqY9j5CdwESbdxSJDOmf_bcqXrgiAbQw' target='_blank'>2025-06-03 18:18</a> <span class='u' style='color:#c67452'>sourabhniyogi</span>: Is there some way to get a dump of all the registers out of polkajam, prior or after the execution of each compiled block. </div> |
8824 | 8824 | <div class='msg reply'><a class='ts' href='#$E-NytBv42QadGBEXduqw8dFe-FlJ-AzdAZrRSkKEt28'>#</a> <a class='ts' name='$E-NytBv42QadGBEXduqw8dFe-FlJ-AzdAZrRSkKEt28' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$E-NytBv42QadGBEXduqw8dFe-FlJ-AzdAZrRSkKEt28' target='_blank'>2025-06-04 06:29</a> <span class='u' style='color:#da5c80'>jan</span>: No. Only the registers changed by the program are printed out, and some of the source registers depending on the instruction.</div> |
| 8825 | +<div class='msg reply'><a class='ts' href='#$Hcuikh3ki9Y4awQYUjcakv04hJ-1jLrf1_16S81mdjM'>#</a> <a class='ts' name='$Hcuikh3ki9Y4awQYUjcakv04hJ-1jLrf1_16S81mdjM' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$Hcuikh3ki9Y4awQYUjcakv04hJ-1jLrf1_16S81mdjM' target='_blank'>2025-06-07 22:45</a> <span class='u' style='color:#d470bf'>jaymansfield</span>: > <@jan:parity.io> PolkaVM charges gas per basic block, not per instruction. |
| 8826 | + |
| 8827 | +Is it expected then that everyone charges per block and not per instruction? Otherwise on all non-successful invocations (accessing bad memory, etc) our work results gas used will differ.</div> |
8825 | 8828 | <div class='msg'><a class='ts' href='#$hGkued8hyVV2TnuEdqluVjHYazoLiNFylQSe0I2pybU'>#</a> <a class='ts' name='$hGkued8hyVV2TnuEdqluVjHYazoLiNFylQSe0I2pybU' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$hGkued8hyVV2TnuEdqluVjHYazoLiNFylQSe0I2pybU' target='_blank'>2025-06-04 07:26</a> <span class='u' style='color:#bcd429'>subotic</span>: </div> |
8826 | 8829 | <div class='msg'><a class='ts' href='#$ZIqASXlnL6wWtUe1nU-5WJRqM-jtjO8Xq7YRpaIlZqE'>#</a> <a class='ts' name='$ZIqASXlnL6wWtUe1nU-5WJRqM-jtjO8Xq7YRpaIlZqE' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$ZIqASXlnL6wWtUe1nU-5WJRqM-jtjO8Xq7YRpaIlZqE' target='_blank'>2025-06-04 08:20</a> <span class='u' style='color:#c9419d'>davxy</span>: New batch of import traces: <a href="https://github.com/davxy/jam-test-vectors/pull/70" rel="noopener" target="_blank">PR #70</a> |
8827 | 8830 |
|
@@ -8910,3 +8913,13 @@ <h1>#jam:polkadot.io</h1> |
8910 | 8913 |
|
8911 | 8914 | Are you using this fork of asn1tools? <a href="https://github.com/davxy/asn1tools/" rel="noopener" target="_blank">https://github.com/davxy/asn1tools/</a> </div> |
8912 | 8915 | <div class='msg'><a class='ts' href='#$Wu4z5tQt-ovdrS99sK_ux-ZCKWZckiPSd-AP2dYj9mE'>#</a> <a class='ts' name='$Wu4z5tQt-ovdrS99sK_ux-ZCKWZckiPSd-AP2dYj9mE' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$Wu4z5tQt-ovdrS99sK_ux-ZCKWZckiPSd-AP2dYj9mE' target='_blank'>2025-06-05 13:41</a> <span class='u' style='color:#dc865f'>interweb_</span>: </div> |
| 8916 | +<div class='msg'><a class='ts' href='#$GQj32bw9KZKbgpW_B3dtzSROOH4nQCsUkAaI7wb-FWA'>#</a> <a class='ts' name='$GQj32bw9KZKbgpW_B3dtzSROOH4nQCsUkAaI7wb-FWA' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$GQj32bw9KZKbgpW_B3dtzSROOH4nQCsUkAaI7wb-FWA' target='_blank'>2025-06-07 17:05</a> <span class='u' style='color:#d470bf'>jaymansfield</span>: If anyone is interested in comparing compatibility and cross testing with more JAM implementations, I've released 0.6.5 binaries for JavaJAM. <a href="https://github.com/javajamio/javajam-releases" rel="noopener" target="_blank">https://github.com/javajamio/javajam-releases</a> </div> |
| 8917 | +<div class='msg'><a class='ts' href='#$h39eBcr6-2AMEIjaqoI3K3J2HKon15GBgKTVsf5k9ww'>#</a> <a class='ts' name='$h39eBcr6-2AMEIjaqoI3K3J2HKon15GBgKTVsf5k9ww' href='https://matrix.to/#/!wBOJlzaOULZOALhaRh:polkadot.io/$h39eBcr6-2AMEIjaqoI3K3J2HKon15GBgKTVsf5k9ww' target='_blank'>2025-06-07 21:38</a> <span class='u' style='color:#c67452'>sourabhniyogi</span>: Jan Bujak: We have gotten knee-deep into linear recompilation work following <a href="https://www.youtube.com/watch?v=iXsng4YCDQg" rel="noopener" target="_blank">your Recompilers 101</a>, now doing pvm byte => X86\_64 recompiles (in Go) and gotten 80 pvm instructions to pass in compiler mode. |
| 8918 | + |
| 8919 | +Some questions: |
| 8920 | + |
| 8921 | +1. What X86 registers can we safely "clobber", if any? |
| 8922 | +2. In many cases, our PoC implementation maps a single PVM instruction to 2-8 x86\_64 instructions and I'd like to check that the larger cases (5-8) are sensible. Some of these larger cases appear necessary to cover the "inst\_{divide,rem}\*\_by\_zero" situations and we're wondering if we're off track? |
| 8923 | +3. Does it make sense to have a battery of pvm-to-x86 target outputs as public test vectors for M3 linear recompilation? Or, can we see polkatool's "recompiled x86\_64" output somehow, block by block, or across an entire disassembled .pvm file to check for cases where we are doing a few too many x86\_64 instructions per PVM Instruction? How do we do this if so? |
| 8924 | +4. there are many PVM opcodes (ROT\_R\_64\_IMM, MUL\_UPPER\_S\_S, COUNT\_SET\_BITS\_32, SIGN\_EXTEND\_16, REVERSE\_BYTES ...) that do not yet have a simple test case in the <a href="https://github.com/w3f/jamtestvectors/pull/3" rel="noopener" target="_blank">pvm test vectors</a> like <a href="https://github.com/koute/jamtestvectors/blob/master_pvm_initial/pvm/programs/inst_add_64.json" rel="noopener" target="_blank">inst\_add\_64</a> (powering both interpreter and compiler testing) -- is this something we should expect from you or should we be on our own for this? |
| 8925 | +5. Generically, for different recompiler efforts, if in the end, we had exactly one public "best" way to map each PVM instruction to some number of x86\_64 instructions, how do you expect PVM executions (excluding host function calls) to actually differ? If you expect they will differ very little to none, why not have a single open-source high-performance C recompiler that maps into this "best" way per architecture (starting with x86_64) that we all build and FFI into just like w3f bls+bandersnatch libs? <span class="edited">(edited)</span></div> |
0 commit comments