twinBASIC Weekly Update

twinBASIC Update: December 31, 2023

A quiet week of development with a fascinating conversation on Wayne's decision to write a custom compiler rather than transpile twinBASIC into C/C++.

Mike Wolfe

Dec 31, 2023 • 4 min read

On April 23, 2021, I helped Wayne Phillips introduce the world to twinBASIC at the Access DevCon Vienna conference. I boldly predicted that twinBASIC (along with the Monaco editor) would replace VBA and its outdated development environment by 2025. With that goal in mind, this weekly update is my attempt to keep the project fresh in the minds of the VBA development community.

Every Sunday, I will be providing updates on the status of the project, linking to new articles discussing twinBASIC, and generally trying to increase engagement with the project. If you come across items that should be included here, tweet me @NoLongerSet or email me at mike at nolongerset dot com.

Here are some links to get involved with the project:

Highlights

All quiet on the Western Front.

Discord Chat Summary

^{* Auto-generated via Claude-2-100k on poe.com}

twinBASIC General Channel Summary

The conversations so far have centered around holiday well-wishes, community engagement, and discussion of the twinBASIC compiler architecture.

Recent Updates

No major project updates in this timeframe, just holiday messages

Looking Ahead

Some early interest expressed in localizing the IDE, but no concrete plans yet

Compiler Architecture

Discussion of merits of custom compiler vs transpiling to C/C++
- Custom compiler better supports features like edit-and-continue, error handling
- Integrated debugging experience faster with custom compiler
- Using LLVM for optimized final code generation
- Custom compiler more work to implement but avoids limitations of transpiling

Community

Members exchanged holiday greetings and appreciation
Wayne thanked the community for their support in 2023
New members continuing to join Discord

The overall tone is excitement about twinBASIC's potential as we head into 2024. The holiday break has paused major development updates, but conversations around the compiler architecture and community relationships continue.

Around the Web

Custom Compiler vs. "Transpiling" to C/C++

In an otherwise quiet week, there was one conversation that I found interesting in the Discord server.

nextKast asked, "this may have been answered before, but what is twinBasic written in, what compiler underneath achieves cross platform capabilities?"

fafalone responded first: "afaik it's mostly c++ and a custom compiler. always wondered why a custom compiler rather than going with C or C++ intermediates and an established compiler, like the original VB and many other languages these days. cross-platform ability maybe?"

Wayne clarified things with the authoritative answer. "It's true that using a transpiler simplifies many things... hence why RB is going that route.

"However, it also hinders many things. Features like GoSub-Return, and edit-and-continue would be significantly more difficult to implement using a C transpiler. That's before you start to think about having an integrated debugger, and also how flexible VB is with regards to error handling, with allowing branching to different labels depending on the error handler state. There's good reason why VB compiled to a custom intermediary format, 'pcode', to allow better support of these things.

"In fact, tB native codegen can be thought of as 'pcode on steroids', in that allows for all these complex VB features, yet by outputting to direct x86/x64 native code it offers much better performance. Internally we pretty much use LLVM IR representation as an intermediary before final codegen, and it is ultimately LLVM that will offer us the final 'performance' codegen that we need.

"Apart from being more complicated to implement, there are no real downsides to the approach we are using. The same cannot be said for the transpiler route.

"There's also significant value, IMO, in having that 'integrated' feeling in the IDE. What I mean by that is, when you press F5, your debug session starts almost instantly. That would be hard to achieve with an external compiler."

nextKast responded, "[S]o its not using .net core or anything like that? sorry I am not versed in compiler talk."

Wayne answered, "No, nothing like that. It's C++ at the heart of the project for now, until full LLVM support is available in tB, and then parts of the compiler will likely be ported to tB itself in future."

nextKast: "[S]orry I keep asking... so if its c++ is it like a gtk compiler? How do get cross platform? My reference point is lazarus as I have had to resort to that for a small project I need in linux."

Wayne: "No, the compiler doesn't output c++ in any shape or form. The compiler is written in c++ and outputs native code directly (or via LLVM). Cross platform support requires the codegen stages to support the target architecture. Currently, tB only supports x86 and x64 codegen. In future we'll support ARM, risc-v, etc.

"The LLVM backend compiler already supports these other architectures, so that is a big bonus.

"There is, of course, more to it than just codegen changes, as each OS also has different requirements. But codegen is where we start, and work outwards from there to build the full eco system for each target platform."

Maybe it's just me, but I found this to be a fascinating insight into Wayne's thinking. It also highlights the tour de force twinBASIC truly is already. I'm excited to see what 2024 brings.

Merry Christmas!

Changelog

Here are the updates from the past week. You can also find this information by visiting the GitHub twinBASIC Releases page.

No new releases this week.