Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Build Your Own Programming Language

You're reading from   Build Your Own Programming Language A programmer's guide to designing compilers, interpreters, and DSLs for modern computing problems

Arrow left icon
Product type Paperback
Published in Jan 2024
Publisher Packt
ISBN-13 9781804618028
Length 556 pages
Edition 2nd Edition
Languages
Tools
Arrow right icon
Author (1):
Arrow left icon
Clinton  L. Jeffery Clinton L. Jeffery
Author Profile Icon Clinton L. Jeffery
Clinton L. Jeffery
Arrow right icon
View More author details
Toc

Table of Contents (27) Chapters Close

Preface 1. Section I: Programming Language Frontends
2. Why Build Another Programming Language? FREE CHAPTER 3. Programming Language Design 4. Scanning Source Code 5. Parsing 6. Syntax Trees 7. Section II: Syntax Tree Traversals
8. Symbol Tables 9. Checking Base Types 10. Checking Types on Arrays, Method Calls, and Structure Accesses 11. Intermediate Code Generation 12. Syntax Coloring in an IDE 13. Section III: Code Generation and Runtime Systems
14. Preprocessors and Transpilers 15. Bytecode Interpreters 16. Generating Bytecode 17. Native Code Generation 18. Implementing Operators and Built-In Functions 19. Domain Control Structures 20. Garbage Collection 21. Final Thoughts 22. Section IV: Appendix
23. Answers
24. Other Books You May Enjoy
25. Index
Appendix: Unicon Essentials

Questions

  1. Suppose a specific Unicon value, such as the null value, was particularly common when marking live data. Under what circumstances would it make sense to modify the PostDescrip() macro to check for that value to see if the tests in the Qual() and Pointer() macros can be avoided?
  2. What would be the advantages and disadvantages of creating a separate heap region for each class type?
  3. The reclaim() operation of Unicon’s mark-and-sweep collector moves all the live non-garbage memory up to the top of the region. Would it be beneficial to modify this collector so that live data did not move?

Join our community on Discord

Join our community’s Discord space for discussions with the authors and other readers:

https://discord.com/invite/zGVbWaxqbw

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image