Subroutines for the EVM #1

Transcript

Greg Colvin: Good morning!

Ben Adams: Hey.

Paweł Bylica: Okay.

Greg Colvin: Hello, kids note-taker. I assume there's a.

Paweł Bylica: I assume… Bye.

Ben Adams: I'll drop a link in ACD in there.

Greg Colvin: Can people hear me?

Ben Adams: Yep.

Greg Colvin: I just switch computers. The one seems flaky. I wish Tesla had figured out how to fill the air with electricity. and I didn't have a huge collection of dongles and power supplies. I guess. Wait just a few minutes.

No, I guess we want… we might as well start, mail Mainly, I'm here to answer questions. And the main thing I have. Questions about… We'll just… Generally, what people think And the specific… The specific things are, Since John Max passed the validation code, I'm not as sure of as I would like to be. Cause… The proof that it works was his work. Yeah, and, the effect on, on ZK work.

I'm not sure that section is right, because I don't under… I don't understand ZK like he did. So I had to lean on… I had to lean on Claude to produce the Vyper code and, for some of the ZK discussion. No, I'm good. And Kev, you might be the right person to tell me if the ZK stuff makes sense. It made sense to me, but every time I turn around, there's been more progress.

Ben Adams: I think it's just the AI note-taker, so… He wouldn't respond.

Greg Colvin: So there's nobody here but Kev's note-taker.

Ben Adams: No, no, no. I mean, Kev's not here.

Greg Colvin: Okay, so Kev's note-taker is here, but not Kev.

Ben Adams: Yeah, yeah.

Greg Colvin: Okay.

Ben Adams: So he'll, he'll probably see Oh. After the call.

Greg Colvin: Okay, well, well. I'll ping him afterwards. And a question for… Yeah, more for client devs. Yeah. is, One notion there was to get the validation code out of the clients to go ahead and put it on the blockchain. I noticed Vitalik has suggested putting the identity pre-compiled on the blockchain, and researchers have suggested that for other for other things that are currently pre-compiles. And the notion is, if we get it on the blockchain, we only need to get it right once. Then it makes client jobs really easy. If a contract

has a magic header, then the header will point at the address of the validation code. It's not any harder than running the init code, and if it doesn't pass validation, then it Then it fails and doesn't get run. So this is… This is an answer to… To Marius's continuous… continuing concern about technical debt. To try and get it down to… all the clients need to do is to add a return stack, and the… the opcodes amount to, a little bit of instruction, decoding, push the return, push the return address and to return, pop the return address. Oh. So… Try and make it as simple as possible and if it turns out nobody in the world ever uses this, we're carrying on a very tiny amount of debt and it will get used.

and I don't have a whole lot to say about it until I know what what it is people want to do, what questions they have, what comments. and just speak. I'm not gonna deal with with people's hands being up.

Ben Adams: Okay, so. As I understand it, only… These opcodes will only be valid. Inside, A contract that starts with the magic header and to deploy that. If your contract starts with the magic header, it will be validated at create time. And then, after that, It's sort of like your life.

Greg Colvin: The opcodes are valid whether or not. They're in magic code. The opcodes are simply being added, so they're backwards compatible. If they're in, if they're in code that's labeled, that's valid, that's magic. then they have to obey the rules. But if they're not in Magic Cove, they don't have to obey the rules. But they're still there and can be used. Oh. And this is important that this is genuine backwards compatibility. It's not hand waving that just says, well, yeah, we've we've got a tag here. So it's it's really a different interpreter. So it's it's backwards compatible in that sense. And I don't think that's I don't think that's… the level of compatibility we want. We want the interpreter itself not to care whether it's validated.

So…

Lightclient (Matt Garnett): What's the point of the validation?

Greg Colvin: Umm. Basically… A client can check it. Luke's not here, but he was trying to actually write a compiler for his client and discovered he just could not do it. Could not do it efficiently. Could not optimize what he had. So it will affect clients that are trying to optimize the code. That was my initial motivation. I set out to to do what I'd done for a JVM at Oracle, which was simply make one pass over the one pass over the byte code and translate it to register code, which would make it run faster, and then one pass over the register code and convert it to machine code. And it turned out to be

Impossible. Yeah. And it was… oh! put in these 2 instructions and arrange that the instructions be used properly, and it becomes possible, just like it is for the Jvm. Just like it is for Wasm, just like it is for cli, and I'm scratching my head and going. You know. Why? And it's too late to fix legacy code, but at least we can have a marker that says at least this code, you know that you can traverse it in one pass and therefore you can do all kinds of nice things. Oh.

Lightclient (Matt Garnett): I guess I'm just trying to understand, like, how… required it is to do the validation in the protocol with the introduction of these opcodes, because I think most clients won't implement these optimizations from the get-go. And the validation is probably the most contentious point of this, these proposals.

Greg Colvin: Well, not having it was a contentious point in 2315. Some devs specifically objected that it wasn't there. Yeah. and then for EOF. The other devs objected that the code would only run in EOF, so EOF essentially marked a whole new interpreter. And I don't know that all clients will want to take advantage of this right away. They're going to need to wait for compilers to catch up. you know, you know, it's… it's not gonna be possible to get everything to land all at once. Yeah,

Ben Adams: So, yeah. So… As I understand it, the magic header guarantees that the code is well behaved. But you can use the up codes. Without the header, but it doesn't necessarily, it's not necessarily well structured. Right. So if you put the magic pedal, you deploy it. You… you guarantee at deployment time. It's valid. Never have to check it again.

Greg Colvin: Right.

Ben Adams: And then you can optimize it.

Luis Pinto: What's the benefit of having that Because if we want to use these new opcodes, and there's no guarantees what is… What do we gain with that? Can we not just restrict those opcodes to that magic? But…

Greg Colvin: Yeah. I'm a little confused here. the alternative is is simply to do the check every time you Every time you want to run the code.

Lightclient (Matt Garnett): I think he was just asking, like, why allow this backwards compatibility?

Greg Colvin: Well, one, just because backwards compelled, it's a good thing to have it. If you don't have it, there will be objections that, gee, you know, I wind up needing two interpreters here. One… one for the new code, and one for the old code. Not that I can choose to have two interpreters so that I can interpret the new code in a faster way or a different way, but I'm forced to. You know, I can't just use a simple interpreter. Another reason to have it is the opcodes are useful in their own right. There's useful ways to use them that won't pass that that validation algorithm. that can still be traversed in one pass. The EOF validation algorithm was a more complicated algorithm. It required that the code be organized in blocks, that the blocks be in a certain order.

So… You could… you can do the code in different ways that are still you know, still useful. So I don't want to upfront. Just say there's only one way to use these new opcodes when, in fact, there's useful things you can do with them that are not going to pass that validation. and the validation isn't fixed for all time. It's… The header points to a function on the blockchain and over time different validation can be put in there. It can both be less restrictive with fewer constraints. With fewer constraints, with better algorithms, we can prove more. With more constraints, we can prove more.

That's completely open to the future. But… As core devs, we long since lost the opportunity to drive this. That was something we could have done 10 years ago. But now we have a huge ecosystem, and it's it's gonna be a market, basically. Okay. Okay. And most of the advantage is downstream of the clients. It's people who've got the bytecode that need to do things with it. They might need to compile it, they might need to do proofs of correctness, any number of things you can do downstream of the bytecode. And… Those aren't very visible to the core devs. It's a lot of people. Lots of them are very small shops doing auditing. And for the most part they've given up talking to us.

They've they've got work to do, and fighting with the core devs to get something to change doesn't. Doesn't make them any money. and the academics. They spend their time writing papers to get just a few percent gain, and how many programs they can analyze. So, we're creating a huge amount of technical debt downstream of us. It's mostly invisible. For years, I meet people at conferences that just say, please, get rid of dynamic jump. We don't care how, just get rid of it. Oh.

Łukasz Rozmej: How useful would that be? Well, this is the first step, definitely, because it's just introducing static jumps, but we won't get reading of dynamic jumps, right? So this is only partially useful.

Greg Colvin: Invalidated code. The form is still there, but. You know, we insist that… that the jump Address be a constant. I don't try to introduce a new kind of jump instruction. EOF tried to do that. but then you've gotta figure out how to put the immediates in, you know, without breaking other things. there's an eip to do that, but I think it's currently stalled. All right. Don't want to wait around on that. Last time I talked to Martin, he was just going… What's the point? Just to to maybe save a bite.

Ben Adams: So we, The constraint that the jump and the call sub, et cetera, must be preceded by the push makes it. Started. Is that correct?

Greg Colvin: Right, right.

Luis Pinto: About the validation phase and the performance, I think Light Client is worried about that. Yeah, I think the disk write for… The contract creation might actually be, though, the most overhead part of it, and that the validation in itself might not really be That much overhead, added on top of the contract creation. So…

Greg Colvin: No, it's very fast and easy.

Luis Pinto: Yeah, for 64 kilobyte contracts. I don't think we're gonna go much higher than that, soon.

Greg Colvin: Yeah, it's… it's a one-pass algorithm that doesn't do… Very much work, first step. Mmhm.

Luis Pinto: Regarding the deployed contracts, I guess in the… most clients, since there's such a performance concern about having them being performant, I think most clients will eventually have their own baked-in validation, which just avoids the EVM interpreter altogether. I think that that will happen. So I'm not sure. I feel a bit neutral about having that deployed on-chain.

Greg Colvin: Mmhm.

Ben Adams: I mean, we can measure. the EVM. And. the… How long it takes. Maybe it's faster.

Greg Colvin: It gets done, you know, once at create time. and it substitutes for jump test analysis. You don't need to do jump test analysis. So I… I just don't… I don't see that it's a big deal, and clients are free to put their own in, for better performance. Yum. But it makes it possible to write a simple client that's a simple interpreter. And pulls. Pulls the algorithm off the chain, runs it after the init code, and otherwise… otherwise, it's just a very simple interpreter that you can write right now. Yum. And.

The validation is… You know, it's a one-pass algorithm, but it's a bit tricky.

Luis Pinto: I had a question about call sub. So, from what I'm understanding, the call sub, can… see the operand stack before it, right? It's not like the… like in programming languages, when you jump to, A function, you have your own, operand stack. I don't have access to the ones previously. Have you given any thought to that? Are there any security concerns about… And that case, or… I guess we have call… we have call, that does not have previous information about operand stacks. From previous frames. But, yeah.

Greg Colvin: Higher level languages make it look as if it has its own operand stack. Oh. It may or may not be a separate piece of memory. It's not easy to get at anything higher up. I'd have to think as to whether it's even possible. But… There's an EIP that would make it possible, but it stalled.

Ben Adams: It's… All within the same contract, though, so… You. You'd be worrying about the security of the code group. I don't see that would be a problem. It's not… it's not a call into a different contract.

Luis Pinto: Yep.

Greg Colvin: Yeah, you're just… if you can even do it, Yeah, I mean, I guess you could use a duper swap to reach up higher. Grab some data. From the contra… from the function that called you. But the validation is, is still gonna catch. catch whether that's causing a problem, at least within the constraints we're validating. I mean, the validation is weaker than the type checking for a higher level language.

EOF puts enough information in the header that it's pretty much as strong as a higher level language, but it meant that it cost 14 bytes to create a function at all. Yeah, So they paid a price for being able to prove more things. And then they needed special opcodes to do jumps between routines. so… There's no free lunch here. It's engineering. You make compromises. sort of in the end. It doesn't matter one way or the other. We need to get these in. come. And we've been bouncing back and forth between this is too simple, and this is too complicated for years. To me it makes sense to just get the simplest thing in, and then we can build on that. The mechanism is the same as every proposal we've had.

time.

Luis Pinto: Yeah, still on that on-prem stack, like you may not have security concerns, but I wonder if the compilers could not benefit from the restriction of not accessing variables outside of its scope. Like, better escape… escape analysis, But, yeah, I'm not sure.

Greg Colvin: I mean. Compilers are free to… Put more restrictions on themself. Compilers do fine without this. Mmhm. They're… they're compilers. They're… they can target pretty much anything. Solidity is highly optimized for dealing with jumps. So implementing Implementing subroutines with jumps costs them just a little bit more, and then they optimize it all the way. Okay. So this really isn't a huge advantage for compilers. It's probably more of an imposition on compilers. They have to be able to generate code that meets certain structural that meets these rules that otherwise they wouldn't have to follow. And it's not to their advantage to doing it. It's to the advantage of people downstream of them.

And that's a very diffuse, Very diffuse effect downstream. Affects a lot of people. But… Yep. A lot of very quiet people. They were more involved way back in the six EIP 615 days. and have pretty much wandered off. They're no longer working for the foundation. What? I'm forgetting the name now. and I'm forgetting if we still supported the foundation was supporting a a static analysis tool. whose name I forget. If anyone remembers. and one of the restrictions in that tool is that it would not analyze jump statements.

That seemed a pretty severe restriction. It wasn't just that it wouldn't analyze inter-contract calls, it wouldn't analyze jump statements, which are, of course, very common. Oh. So.

Ben Adams: We did try and implement an AOT compiler in Nethermind. Well, we did. But when it was working on… Current contract. you would… commonly come across ones that just exploded. So. this would hopefully… Results of it.

Greg Colvin: Sorry.

Ben Adams: Anyway.

Greg Colvin: So it would be a matter of. Convincing compilers to produce. To produce valid code. And trying to get it… trying to get a compiler to promise to do that up front. I know… I know Bryant at VIPERS has just said he's… he's not going to devote resources to it. He devoted a lot of resource to EIP615, and we decided to go with WASM instead. He put some more resources into EIP-615 when it was reintroduced after WASM failed. And… Yeah, his attitude is he's just not going to waste company resources on things that take a lot of work and then fail in the end. Oh. Yeah, the solidity team eip 6, 1, 5 was actually

authored by the team lead, was a co-author. and EOF was partially offered by Solidity Team people. And I don't think any of those people are still there, even. and,

Ben Adams: Do you think this… EIP… Is enough to… Umm. Provide what? Static. analysis, and… Aotd.

Greg Colvin: If compilers implement it, it's enough. Yeah, I'd implement a compiler myself if I could. but for for 10 years I haven't been able to.

Ben Adams: Well, I mean, if we… If we ignore the compilers, but if a contract is marked as magic and is validated as such. could the bike… is it enough to… Then be able to rely on the bytecode for static analysis.

Greg Colvin: Yes. it becomes possible to extract the control flow graph in one pass. It becomes possible to extract the abstract syntax tree in one pass. It becomes possible to do any sort of analysis that requires traversing the control flow in one pass. And, it's easy to… it's easy to understand, I think, that if you cannot traverse the control flow in one pass, all kinds of things get more difficult, if not impossible. Oh. and my understanding and everyone I talk to. It just says any way of getting rid of them is enough. Oh, man. There's many ways to do it, and it doesn't matter how just do it. So.

Ben Adams: I mean, for the compilers, because of… how… Things haven't landed before. I assume they might. put the work in after the EIP last, but I don't think that's necessarily a problem.

Greg Colvin: I don't see an alternative. I don't. At this point I don't see why anybody would bother until it actually exists. Too many times people have put in the work, sometimes years of work, to have it die in the very end. often for reasons that aren't even clear. In most cases, I'm not sure if anyone could actually articulate why things died. Ask different people. You'll get different reasons. so it's just too risky to to put the work in.

Ben Adams: Only.

Greg Colvin: Go on.

Ben Adams: On the backwards compatibility side. Does it… Complicate. dump best analysis, so I'm wondering about… If the constraint should still apply, so, like, a call sub should… Colon and to sub, that kind of thing. when… when you're not in… not in validated code.

Greg Colvin: I'm not quite following.

Ben Adams: In validated code, you're saying a call sub must call and enter sub. And it has to be preceded by a push. In non-validated code. Do those constraints still apply?

Greg Colvin: No.

Ben Adams: Okay, so you could pull anywhere around them.

Greg Colvin: Yes.

Luis Pinto: But for those cases, they will fail on execution, is that right?

Greg Colvin: They may or may not just. Just like current code.

Luis Pinto: Yeah, so if there's a call sub and there's no enter sub following, what would an EVM interpreter, what should it do? Should it fail? A halt.

Greg Colvin: Okay. Some some of it will get caught by jump test analysis as far as preventing it from from jumping into immediate data. Otherwise, it'll… If it hits a valid instruction, it'll it'll implement it, and it'll keep running until it hits a stop, or it hits an invalid instruction. So no different than current legacy code that that's wrong. It'll do the wrong thing. So arguably, you've you've added some other ways to go wrong. But There's so many ways to go wrong now. So what? because you've also introduced some op codes that are that are useful in their own right.

Ben Adams: So… I suppose… what Return Sub does. in, A non-validated perk might. He's gone. Hello. You still here?

Greg Colvin: Yeah, okay.

Ben Adams: Oh, sorry, your other… So, return stub. What that would do in backwards compatible code, if you hadn't called Cool, so… If that makes sense.

Greg Colvin: It would be.

Ben Adams: Would that would…

Greg Colvin: It would be the same as a jump into immediate data or a jump. Outside of the… Yep. To a destination outside of the contract.

Ben Adams: OK, so like return or fault.

Greg Colvin: A return is just a jump to the address on the return stack. so it can. It can go wrong in any of the ways that a jump can go wrong.

Ben Adams: Okay. That's fine.

Greg Colvin: Okay. That might be something I need to clarify. Precisely in the proposal.

Ben Adams: Yeah, whether it's like, and exit. Oh, I suppose. For exit, contract, or… Or a sweat. I'm not sure.

Greg Colvin: It's… It's a constraint that things have to… be valid, but that's a constraint on validated code. It's it's also a constraint on legacy code. But it's it's You can point at the yellow paper. I don't know how we're supposed to refer to constraints in the executable specification. It's not really a spec… it's not really a specification. But But. Yeah, pretty much. It will either land in immediate data. It will land on an instruction that's not valid. or it will land on a good instruction.

And the first two cases, it's an exceptional halting state, and if it hits a valid instruction, it will execute it. because the machine does not know the intent of the programmer. So It's really. If you don't have the backwards compatibility, it becomes like EOF. You're really introducing a whole new machine. So. And… With it, the simplest way to implement it, if it's on-chain, is simply to add a add a little bit of code that says if it's marked call the… Call what's on the chain.

So. Everything else can stay just the same about your client. If you need to write a new client, you can write the interpreter in the totally straightforward way. That's fine. alright. Are people satisfied? with satisfied that your questions are answered here.

I guess I see thumbs going up. Then, if there's nothing else, I guess we're done.

Ben Adams: Okay. I just think some… it needs a little bit more clarity on… Like what happens in the. Legacy, for instance, like, the return sub one, there's no… returns pointer. I can… I can make a PR for that, if you want, or… It's up to.

Greg Colvin: Let me see. Yeah, a small Pr. Would help. it might already be implied either by what's there or by rules that already exist. But to make that clear. that pretty much the return obeys the same rules as a jump. and the jump desk would get expanded to include. to include, to include return subs and call subs in the jump test analysis the same as the same as jump tests and jumps. Damn.

And yeah, that could be done with references to the yellow paper, because nothing has changed about that. So I didn't. I didn't plan another one of these for a month, probably. What I'd like to do is is push this towards CFI. As soon as possible. Because the list of PFIs is just going to keep getting longer. Umm. And, if it's going to fail, the sooner the better, so I can get on with my life.

Ben Adams: Is it on the Hegota? here, if I…

Greg Colvin: It's proposed, yeah, it's proposed for inclusion.

Ben Adams: Okay.

Greg Colvin: I don't… I don't know what the next step is to… to get it to CFI. And The people helping with that have left the foundation. And when I asked them why, One just said, it's a shitshow. So… So I'm I'm not even sure who to push on anymore to make that happen. but I'll… I will try to find out. Hopefully I won't get told that I have to put it on Twitter and deal with all the abuse there. Be cut, sorry. I simply refuse… I refuse to interact on Twitter whatsoever.

If I'm mentioned, I might reply, but… Otherwise, I won't. Oh. So…

Ben Adams: I can… I can put it on Twitter for you. I'd take that abuse.

Greg Colvin: Okay. If. So the main thing I need is. as far as volunteers is renewing, reviewing, What… oh gosh… 8173… I don't have the numbers right in front of me. 8173, the the higher level explanation goes into advantages for For roll-ups and such, and I just don't know if it's true. And then, the. Validation algorithm took some pseudo-python. And turned it into an actual Vyper contract.

And I think it got it right. First, it had to teach itself Vyper. It did that amazingly quickly. And then I had to kick it a few times to get it from the 3-pass algorithm into the 1-pass algorithm. And it looks right to me, but I'm not a Vyper reader. So, let alone a Vyper Rider. It's enough like Python, I can follow it. Go. But I… I thought it would be good to have an actual contract and not just pseudocode. And I guess the steel group is there to help me, get it into the… Get it into the, executable spec. I don't… I don't know if they're still in operation or not. So…

Ben Adams: Yeah, there's still groups still there.

Greg Colvin: Okay, so I'll contact them and see if it's a point that they're able to help. Get them. And I'll contact Kev directly. He wasn't sure if he could make it, and apparently couldn't. Oh. Okay,

Luis Pinto: Just one last remark. I guess one benefit of subroutines is also… deduplication of codes, where you can reuse code as well, in smart contracts, because there's some cases where people just, redeploy the same smart contracts. They don't make use of the same codes, or deployed, but redeploy the same. contract with slightly… slight modifications. And, I think that could help also on the, Code load side of things. I'm not sure if you added that on your motivation section.

Greg Colvin: It would help a little. EOF was more helpful for that, or even a stage. I suggested a stage past that. with actual modules with sort of multiple EOF code sections inside of them. You know, and then you can have actual packages with… here's a module, multiple functions that it wraps up. And, you know, then more have, like, something that's ready to be reused. This would help, but… you know, I can't do all that much work, and it was a whole team of people that did EOF, and they're all gone. Almost all gone. Oh.

Luis Pinto: Okay.

Greg Colvin: Axic is here, but I don't think he's interested in doing that kind of work anymore.

Ben Adams: There is another EIP that's being worked on for that. deploying existing… Contracts to deal with that. And. Different. Covering it, it covers a different… aspect from it.

Greg Colvin: What is that?

Ben Adams: It's… You have a number. Yep. And. Let me find it.

Greg Colvin: a number or a name to look up.

Ben Adams: Alright. He'll be in… here. I don't know.

Greg Colvin: So it would be a core draft here.

Ben Adams: Yep.

Greg Colvin: Okay.

Ben Adams: It's like set code from maybe. Yeah, okay,

Greg Colvin: You found it.

Ben Adams: Yeah, I'll put it in chat.

Greg Colvin: If you could tell me the number, I'm on that page right now.

Ben Adams: Okay, it's one… oh, it's in PR. as 11800.

Greg Colvin: 11800.

Ben Adams: Yeah, so it's not, it's not a lot… it would be… It would be EIP. It's not been reviewed yet, so it's not been mer.

Greg Colvin: Okay.

Ben Adams: The the idea is you can. You could either… at the moment, you can reuse… Headfire. Delegate call. But that adds overhead, so… So instead, you can deploy a contract saying, copy this Addresses code hash to my code hash. Essentially. So then you could build up libraries on chain. that way. And not have to use delegate.

Greg Colvin: Okay. That sounds like a whole nother thing.

Ben Adams: Yeah, yeah, it's different, but so it'd still be… Libraries via call. Rather than, Okay.

Greg Colvin: I'll have to look at this.

Ben Adams: But at the moment, if you were trying to reuse deployed code. In a different address, you'd have to do, cool. You've had a proxy. And then you do delegate call, which is, like, quite inefficient.

Greg Colvin: Orbit.

Ben Adams: All people deployed it. I think 90% of contracts are duplicates on check. But each of them pay for… the cost of… Putting all the code on chain, even though they just… how that happens is, I go, oh, the clients go, oh, this code's already deployed, I'll just do this code hash. So, the fact you had All the code in the transaction is irrelevant. So it's just trying to make an efficient way to say. I want this address to have the code from this other address. And then you could… you could start deploying libraries on chain, and you could say. I want to use that library. At this address.

Greg Colvin: Okay.

Ben Adams: But yeah, it's orthogonal to this subroutine.

Greg Colvin: It seems independently useful. you know. So.

Ben Adams: So hopefully… If we did both of them, hopefully we could, we could start having. Libraries, and well-structured code, and… You know, we'd move into a new… More enlightened. Okay, there.

Greg Colvin: Oh, no, the whole… Zoom has completely disappeared from my screen. It's the 21st century, why don't things work? Anyway, it's worth quickly bringing up… And there was a huge objection about jumping in and out of subroutines. It was brought up as if it was a curse or something. And… that has not been fixed. It's a feature. It is not a bug. And I don't… I don't know if I'm going to be running into that again. Yeah, I don't. I'm not sure how to explain sometimes that it's a feature, it's not a bug.

Ben Adams: It shouldn't be much more overhead than… Just jumping all over the place.

Greg Colvin: Well… Because it's validated, the subroutines don't need to be a continued contiguous stretch of code. In structured computer languages, you do that, and the argument is, well, it's okay because the compiler is free to rip it all apart and do something more efficient. And this is machine code, so the compiler should be free to rip it all apart and do something more efficient. Yeah, And the validation indicates that even though you've taken the subroutine and thrown parts of it in different places, it's… the stacks are still going to align. So, that's one thing I might run into. Because when it was pulled out, people were just very unhappy about that.

And, DOF did keep code sections. Intact that way. And then ran into the fact that, the V. 8. The V. 8. Compiler they were using, partly because of that, and for other reasons, was a huge attack surface. Yeah, would go quadratic. So. In fact, the register allocator could actually go polynomial at higher degrees. Quadratic, so it was great fun. And then they had to introduce specific instructions to handle particular kinds of jumping in and out of subroutines. Okay. There we go. A quick comment. When I was on the C++ committee.

which included a number of compiler vendors who were competitors. Yeah. The argument that a language change was going to make it more difficult for your compiler was simply not an argument. Nobody was going to listen to that argument. The competitive advantage of one compiler over the other was simply not the committee's concern. come. So here the concern is to have. is to have a An up-to-date, good virtual machine. And if a compiler has to do a little work to take advantage of it, well, then it does. so… And it's after 10, so… Thank you all very much for being here. And, there are discussion threads on magicians, so we can carry on there.

Thank you. Yeah.

Luis Pinto: Thanks for your time, Greg.

Greg Colvin: Thank you. My my time is I'm supposedly retired, so I supposedly have lots of time.

Ben Adams: Okay, bye.

Greg Colvin: Very well.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.