New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Overview of the Solang Solidity Compiler by Sean Young

DevconFri, Oct 9, 2020, 12:00 AM

"In this talk you'll learn more about the Solang Compiler: - Why Solang (rust, llvm) - What targets are supported (substrate, ewasm) - What is implemented - Roadmap - Compiler stages: - parser (lalrpop) - resolver - code emitter - standard library - linker - future ideas/directions"

Transcript

my name is Sean Young and thank you sandy sandy compiler so I have about 20 slides to go through so I'll go through these fairly quickly so what is so long it's a it's 30 compiler with compulsivity into webassembly it targets different block tanks so currently target substrate he wasn't and so and sawtooth and other that you see if they're interested could add themselves now that the LLVM EVM back-end is getting more a stabilizing there will be very interesting target to add so so line is written with different tooling than non-saucy so it's written in rust in when you write in compiler yesterday STS and control flow graphs and these are represent is actually quite well in Ross enums so I think Russ is quite suitable language it uses our VMs library so uses LLVM for its optimization passes and to write out the the wasm file itself there also some other advantages to using our VM which I'll talk about later it absolutely grammar from that the past we've generated so recently I've been adding tried catch and adding this to the parser which is about 10 lines of code so it's fairly straightforward I generated grammar so on different block chains there are some underlying differences which might be visible in in the language it's an substrate the address type is 256 bits by default it they can actually it can actually be different from that depending on how something is compiled so the address type infinity is different also constructors can be overloaded in in substrate and substrate uses different avi encoding them and aetherium lastly there's a print function which is just useful for debugging this is only available in development chains but it does really help so here's a little example of a acidity contract on on substrate so we have an overloaded constructor the ABI encodes a function selector for the constructor the ABI encoding for m64 is simply eight bytes little-endian so all the types of fairly simply encoded so we have a function hello which takes a string a string simply has a single field with length followed by the bytes of the string in the ABI encoding and then we have a print function call which is built-in which calls the substrate print and we also can do string concatenation I'll talk a little bit more about that later so a brief history of so long it's nice being very blurry no it was crystal clear for me okay okay okay so in March I wrote a prototype so this was a simple grammar for a very limited set of solidity some LLVM and would within a weekend of hacking I could get a very primitive contract to run so late in December I was awarded a grant from the web free foundation and this was specifically to compete slingers completely language support for substrate this was divided into ten milestones five of those have already completed so these are the remaining milestones for a web free grant and this in in September this way end this should mean that just so long has feature language support complete doesn't mean any output is optimal this the first aim is to get language correct also there will be differences between saucy and and so long language but for example on unwisdom it would be quite difficult with the current scheme to support assembly statements also there are some additions so it's like to print thing I just talked about 70 different ABI encoding um on different chains it's a little bit about the house of long has been when I set out to write so long I wanted to build a traditional compiler I didn't want it I didn't want to do anything revolutionary I also wanted to be simple so there are some fairly simple stages to the compiler so the first thing compiler always does is its parsing so we have lalr grammar and we have a custom nexor and the lecture is really needed because of the pragma statements so if a lexer token isis pragma facility with the assembler then it will use a lot of tokens when it shouldn't it should just take the value as everything up to the first semicolon so the next stage in the compiler is is to resolve them so the parser outputs the abstract syntax tree and resolve them well resolves all the symbols in that generates all the warnings and errors etc and so long in all of it also makes simple it goes straight from a ste to a control flow graph this is actually where the bulk of the code is in in the project this is where all the the language support really is and this is so a front-end and pilot because it uses LLVM so the next part is this there's also a standard library so this is some C code which gets compiled into all of them our VM irr by clang and this gives us a heap so we have mallow can reallocate cetera we can implement things like string compare I'm sorry concatenate you have a case like hash for change that don't provide it that's we have at the moment but this can be expanded to have much more things you might want in a in a language so in the print statement earlier it would be useful to be able to print int or address this or so so string formatting would be a very useful thing and I would be implemented in C added to this other library and then compiles into L of AM i-are and then this will be linked into one big LLVM code and then using global dead code elimination any unused functionality we were removed so having a large standard library doesn't mean that that resulting wasn't far would be any bigger so the last dates of the compilation is the anisa the control flow graph generated by the resolver is specifically geared towards LLVM so there's no C you want to one mapping we have to do some tricks for firing nodes we also have to generate some specific links for wasn't so because wasn't doesn't support two five six bit arithmetic we have to have some arithmetic functions we have to have an ABI encoder/decoder so we have an ABI encoder/decoder for if area maybe eyes and we have one for party scale ABI it also does tear so just a linking it's done mid stolen library and it does have to do some touch-ups to define Eliza them in order to make it correct and there's this custom code for each particular target to generate target specific calls to the externals for example lastly we also need a be ice so the the in this directory can source ABI we have some some codes to generate a B is in substrate these are called metadata files this is because in in substrate that the falkland is more than just the function constructors on event C contains names comments what compiler version generated the file if you may contain the hash of the of the wisdom so you can check the ABI against the wiser make sure it's took the crack warm so so long is a high planchet project and high Pelageya have the mentorship program which is big like google or google Summer of Code and through this this year there's a mentorship program for so long so long language server so this is for IDs so in an ID when you write acidity it can tell you where errors and warnings are it can do syntax highlighting deformation about identifiers etc things that make life easier when you're when you're writing code so that's immense ships having this year hopefully been more next spring after wait and see of course future ideas or things I would like to work on but nothing has been done so far so what are the advantages of using LLVM is that we can use the LLVM linker so anything that can compile to LLVM ir can can be linked so if literally had a foreign function interface then any C code or or rust or whatever could be called from facility and then linked int into the Azzam people want to run all those crazy stuff on chain so this would help them do that also this could be helpful to add crypto which is written in C to C smart contracts another thing is we would like push and pop on memory erase because we have a heap in a solid library and a real lock it actually isn't that hard to to implement this is just a question of wiring things up the other thing that I've had many people ask about is improved data structures instead of T so we will hash maps linked list sets trees also all those sorts of things either in memory or in contract storage and that'll be great to have those available if you have those if you have hash inaptitude so etc you might want to egg types to use those so something like coming typescript will be great well this is all hypothetical really and I really would like to collaborate with witness all C team and see what they think I do not want necessarily want to take 17 intern direction and away from from the official solidity kind of just ideas of war would be good so the other thing with the solid library could have much better string processing and it just makes life easier for when you're debugging code as Linus Torvalds said all you need is is print printf in order to debug any problem so this would be just make life so much easier and well that's it actually yeah so it's it's just me working on a project now there are people interested but if you want to get in touch your asking questions please do and thank you very much for your time great awesome Thank You Sean all right same procedure is every talk if you have a question in the room please do raise your hand or shout so that I know that you would like to speak and for the people on the live stream we will give you a minute now to think about if you have questions then please put them in the guitar chat you know you have it today so we are waiting for you anybody here in the room has any questions with regards to the so long civility compiler yes Chris you thinks we are you talk so I agree that we should yeah come together more and talk about potential features the main problem I see is that the language you're working on has substrate as the main and maybe only target and this is why your language and solidity yes sometimes have to make different trade-offs right so I don't know I just wanted to say that for example that memory push and pop right if you have a heap and memory is cheap and then this is certainly a good idea but as a feature facility and we try to not add features that lure people into thinking that the operation might be cheap but it is not in the end so there is a certain trade if we have to make here I think you're muted thank you I totally agree so when when as and when he wasn't happens then somebody's concerns might what some would go away around memory usage etc also now that the LLVM EVM back-end is to come quite stable I think it's it would be quite quite interesting to add that as a target of so long as well yeah would be very much interested in in some benchmarks there with the back end yes

Automatic transcript — names and jargon may be misspelled.