Compiler Explorer (for the Compiler guys) #offtopic
I'm sure we could do this with ease, because we already can see the bytecodes. https://godbolt.org/ Regards! Esteban A. Maringolo
You can do that with the VMMaker package loaded. There is not all the UI, but you can print the assembly code in the Transcript. On Tue, Oct 17, 2017 at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
heheheheh I had a similar idea years ago [1]. It looks like I start implementing it [2], but I cannot find if I finished it or not LOL. [1] http://forum.world.st/Re-The-idea-of-VM-Learning-Toolkit-td3461173.html [2] https://www.list.inf.unibe.ch/pipermail/moose-dev/2011-April/007655.html On Tue, Oct 17, 2017 at 6:52 PM, Clément Bera <bera.clement@gmail.com> wrote:
You can do that with the VMMaker package loaded. There is not all the UI, but you can print the assembly code in the Transcript.
On Tue, Oct 17, 2017 at 10:03 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve d <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> 'Ascq <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>
-- Mariano http://marianopeck.wordpress.com
Hi, This is already available since some time in the GTInspector. You can just inspect a compiled method. You will get both the bytecode and the AST (with source tracking, too). In fact, this was one of the original reasons why GTInspector exists: I wanted to figure out how the AST is structured so that I can write queries against it :). Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."
Yeap GTInspector was the first thing that came to my mind , great tool :) On Wed, Oct 18, 2017 at 9:37 AM Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is already available since some time in the GTInspector. You can just inspect a compiled method. You will get both the bytecode and the AST (with source tracking, too). In fact, this was one of the original reasons why GTInspector exists: I wanted to figure out how the AST is structured so that I can write queries against it :).
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
Dolphin's debugger was what came to my mind, it had the "dissasembly" way of debugging VM bytecode. It doesn't provide was native code ASM, and as I understand GTInspector neither. Regards! Esteban A. Maringolo 2017-10-18 6:55 GMT-03:00 Dimitris Chloupis <kilon.alios@gmail.com>:
Yeap GTInspector was the first thing that came to my mind , great tool :)
On Wed, Oct 18, 2017 at 9:37 AM Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is already available since some time in the GTInspector. You can just inspect a compiled method. You will get both the bytecode and the AST (with source tracking, too). In fact, this was one of the original reasons why GTInspector exists: I wanted to figure out how the AST is structured so that I can write queries against it :).
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is already available since some time in the GTInspector. You can just inspect a compiled method. You will get both the bytecode and the AST (with source tracking, too). In fact, this was one of the original reasons why GTInspector exists: I wanted to figure out how the AST is structured so that I can write queries against it :).
Sure, we just miss machine code :) But...AFAIR to get the machine code of a method it needs VMMaker to be loaded....
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
-- Mariano http://marianopeck.wordpress.com
On Wed, Oct 18, 2017 at 1:42 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Oct 18, 2017 at 3:36 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
This is already available since some time in the GTInspector. You can just inspect a compiled method. You will get both the bytecode and the AST (with source tracking, too). In fact, this was one of the original reasons why GTInspector exists: I wanted to figure out how the AST is structured so that I can write queries against it :).
Sure, we just miss machine code :)
Yeah the machine code is what matters.
But...AFAIR to get the machine code of a method it needs VMMaker to be loaded....
I was thinking of changing that, adding a primitive which answers a CogMethod as a bytearray, but you still need to use external libs such as gdb/lldb to disassemble your binary (which is possible but not working out of the box everywhere and it does not make sense to include that as part of the VM), and you still need something extracted from VMMaker to make sense out of the CogMethod header and CogMethod map, which has a lot of dependencies, so likely the whole VMMaker itself. And I'm not talking about all the different CogMethod flavors. With VMMaker loaded you can do it with in-image compilation but you will have the machine code with only unlinked sends. With linked send it's more difficult as you need to really simulate the whole runtime. Overall there's no amazing solution. In the example shown it's easier as in C++ the code is not modified while it runs and you've already have gdb/lldb APIs to show what they show.
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
-- Mariano http://marianopeck.wordpress.com
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Hi,
I was thinking of changing that, adding a primitive which answers a CogMethod as a bytearray, but you still need to use external libs such as gdb/lldb to disassemble your binary
I use udis86 [1] for that purpose. Tiny, clean & dead easy to use. x86 only, though. HTH. Jan [1]: http://udis86.sourceforge.net/
(which is possible but not working out of the box everywhere and it does not make sense to include that as part of the VM), and you still need something extracted from VMMaker to make sense out of the CogMethod header and CogMethod map, which has a lot of dependencies, so likely the whole VMMaker itself. And I'm not talking about all the different CogMethod flavors.
With VMMaker loaded you can do it with in-image compilation but you will have the machine code with only unlinked sends. With linked send it's more difficult as you need to really simulate the whole runtime.
Overall there's no amazing solution. In the example shown it's easier as in C++ the code is not modified while it runs and you've already have gdb/lldb APIs to show what they show.
Â
Â
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@ gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
--Â Mariano http://marianopeck.wordpress.com
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
On Wed, Oct 18, 2017 at 3:27 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi,
I was thinking of changing that, adding a primitive which answers a CogMethod as a bytearray, but you still need to use external libs such as gdb/lldb to disassemble your binary
I use udis86 [1] for that purpose. Tiny, clean & dead easy to use. x86 only, though.
HTH. Jan
Tiny that's good. I normally use the facilities provided by the processor simulators (but that's not tiny). Not sure the production environment should have those features anyway
(which is possible but not working out of the box everywhere and it does not make sense to include that as part of the VM), and you still need something extracted from VMMaker to make sense out of the CogMethod header and CogMethod map, which has a lot of dependencies, so likely the whole VMMaker itself. And I'm not talking about all the different CogMethod flavors.
With VMMaker loaded you can do it with in-image compilation but you will have the machine code with only unlinked sends. With linked send it's more difficult as you need to really simulate the whole runtime.
Overall there's no amazing solution. In the example shown it's easier as in C++ the code is not modified while it runs and you've already have gdb/lldb APIs to show what they show.
Cheers, Doru
On Oct 17, 2017, at 10:03 PM, Esteban A. Maringolo <emaringolo@ gmail.com> wrote:
I'm sure we could do this with ease, because we already can see the bytecodes.
Regards!
Esteban A. Maringolo
-- www.tudorgirba.com www.feenk.com
"The coherence of a trip is given by the clearness of the goal."
-- Mariano http://marianopeck.wordpress.com
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
participants (6)
-
Clément Bera -
Dimitris Chloupis -
Esteban A. Maringolo -
Jan Vrany -
Mariano Martinez Peck -
Tudor Girba