I'm surprised, and a little disappointed, that no one in this thread has mentioned parsing expression grammars (https://en.wikipedia.org/wiki/Parsing_expression_grammar) which are a much more human-friendly form of grammar for real-world parsing tasks.
Yes, but I'm concerned about the number of existing browser engines that have fallen by the wayside, as the project founders have become exhausted. The scope of such a project is incredibly easy to underestimate, and it has only ever gotten larger.
ME: How can I get you to fuck off and leave me alone?
META AI: I understand that you may be frustrated, but I'm here to help and provide information. I am not capable of taking offense or feeling emotions, but I want to assure you that my purpose is to assist and provide helpful responses. If you have any specific questions or topics you would like to discuss, I am here to help. If you would like to take a break from our conversation, I understand, and you can always come back when you are ready. Please feel free to ask me any questions or clarify how I can assist you further.
What I want is a dollar for every evangelist and every early adopter that has told me that the ?R explosion is right around the corner. I have worked in the game industry for 30 years and would be well retired by now, had I made my money by listening to people tell me how ?R would be mainstream in Just A Few Years Now. The tech industry NEVER tires of telling that story and hearing it. Yet it never, ever, EVER happens as a mainstream product.
Classic premature optimization, assuming that hardware functions must be revealed in language features. If you can't get your integers closed under addition from the get-go, what hope do you have of writing a secure programming language?
We don’t need any more computer languages. Still, you will run right off and invent another one. Let me guess, your amazing new language uses IEEE-754 math and fixed-precision integers. Your amazing new language is broken.
Seems like your problem is more with the venerable 6502 itself rather than the compiler. Most of that assembly code is spent calculating the offsets inside the Ball struct, which must be done at 16 bits of resolution in every case. The compiler's using the indirect indexed (zero page address with Y offset) 6502 addressing mode to get at all the fields in your struct. It has placed all the variables in zero page, so no instruction is more than two bytes long; additionally, the code in question is entirely linear, with no JSRs or other subroutines. Note in particular how it efficiently uses DEY/INY pairs of one byte instructions to get at low and high bytes of 16-bit memory. Hand-written assembly might be speedier, but not by much and still deal with all the corner cases that your generated code does. "While writing Apple BASIC for a 6502 microprocessor I repeatedly encountered a variant of Murphy's Law. Briefly stated, any routine operating on 16 bit data will require at least twice the code that it should." -Steve Wozniak
Says you. llvm-mos generates surprisingly efficient 6502 code given its age and maturity. Don't take my word for it, try some experiments with it on godbolt.
Onno Kortman has taken semu, a minimal RISC-V emulator, and cross-compiled it with llvm-mos, an LLVM port to the MOS 6502 processor, in order to run Linux on the Commodore 64. Kortman writes: "The screenshots took VICE a couple hours in 'warp mode' to generate. So, as is, a real C64 should be able to boot Linux within a week or so."
https://www.llvm-mos.com