CppCast - Building Debuggers and Keyboards

Episode Date: August 17, 2017

Rob and Jason are joined by Sy Brand from Codeplay Software to talk about building C++ debuggers and the hardware and C++ firmware of a custom keyboard. News N3886: A Proposal to add a Databa...se Access Layer to the Standard Library C++ London "University" C++17 Features and STL Fixes in VS 2017 15.3 The reviews have begun Links minidbg - A mini x86 linux debugger for teaching purposes Building my first custom keyboard Accelerating your C++ on GPU with SYCL Codeplay Software Sponsors Backtrace Hosts @robwirving @lefticus

Transcript
Discussion (0)
Starting point is 00:00:00 This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. CppCast is also sponsored by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket today. Episode 114 of CppCast with guest Simon Brand, recorded August 16th, 2017.
Starting point is 00:00:48 In this episode, we talk about the changes in the latest Visual Studio update. Then we talk to Simon Brand from Codeplay Software. Simon talks to us about building debuggers and keyboards. Welcome to episode 114 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob B rob berving joined by my co-host jason turner jason how you doing today i'm doing all right rob uh we i guess technically things went all right last week after we said that there might be some audio problems so uh maybe we'll continue experimenting some more in future weeks yeah i don't think i heard any complaints about the audio from last week. Good. Yeah, you tried out the web Skype client on Linux and found it to be pretty adequate?
Starting point is 00:01:53 Yes, I would say for people who are on Linux, if you're interested in using Skype, the web.skype.com is definitely the best option over trying to get some official download to work or something. Yeah, the Linux desktop client is just really, really far out of date, right? Yeah, apparently. But we had no problems with multiple video Skype calls and file sharing and all kinds of things using the web client last week. Awesome. Well, at the top of our episode, I'd like to read a piece of feedback.
Starting point is 00:02:20 This week we got a tweet from TJ Chip, and he's actually just sending us a link to um a paper that he thinks we might be interested in talking about and he asked is there much interest in adding a standard database access library as proposed in this link and i'll put the link in the show notes of course and this is paper3886, a proposal to add a database access layer to the standard library. And I'm not really sure how I feel about this, Jason. I'm interested in what your thoughts are on it. Obviously, we have, you know, standard file system coming in C++ 17. But I'm not really sure if a SQL client built into the C++ standard is something we need.
Starting point is 00:03:05 I feel like we have enough libraries for that. Yeah, I mean, all of the Java and C Sharp, I guess, have standard ways of doing these things. It would be pretty low on my list, although I could see maybe perhaps a generic kind of way, just like a data access layer of some sort. And then it would be up to implementations as to what backends, if any, they supported.
Starting point is 00:03:30 But I don't know. I haven't spent a lot of time thinking about it. Yeah, to give you a little snippet, it says this document describes an easy-to-use database abstraction layer for C++. It describes a set of classes which can be used to access an arbitrary SQL-based relational database system. So it's calling itself database abstraction, but it is saying
Starting point is 00:03:47 specifically for SQL. Right. Yeah. It's interesting to see what other people think about it, but my initial thoughts are just that it would be kind of lower on the priority list. There's plenty of other things C++ needs first,
Starting point is 00:04:04 I would think. I would agree, yes. Well, we'd love to hear your thoughts about the show as well. You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes. Joining us today is Simon Brand. Simon is a GPGPU toolchain developer at CodePlay Software in Edinburgh. He turns into a metaprogramming fiend
Starting point is 00:04:27 every full moon when he can be found bringing compilers to their knees with template errors and debating undefined behavior on the C++ Slack channel. He co-organizes the Edinburgh C++ user group and contributes to various programming standards bodies. Outside of programming, he enjoys experimental films,
Starting point is 00:04:44 homebrewing, and board games. Simon, welcome to the show. Hi, thanks for having me. So let's talk about this metaprogramming fiend that you turn into every full moon. Yeah, so I got interested in metaprogramming quite soon after I got into C++. I guess I learned most of my knowledge on metaprogramming by going on Stack Overflow, answering questions incorrectly, and having people tell me why I was an idiot, essentially.
Starting point is 00:05:15 Well, I've never heard of that method of educating yourself. That sounds pretty... It's pretty surprisingly recommended, actually. It worked pretty well. It seems kind of intense I have to have a thick skin for that I guess yeah the MED program has always been an interest of mine I love the idea of
Starting point is 00:05:34 the kinds of abstractions you can build with it and the power it can give you for building higher level abstractions to map down onto more efficient code in the low level, which is what I've been doing a lot with my mechanical keyboard framework, which maybe we can talk about a little bit later.
Starting point is 00:05:53 Yeah, we'll definitely talk about that later, but do you use these advanced metaprogramming techniques in your day-to-day job as a GP, GPU tools developer? Bits and pieces. They come up from time to time if we're trying to build reusable components that we can use across some of our different toolchain
Starting point is 00:06:11 elements. So we have our own internal libraries which we try and make sure they're unit tested and high quality and reusable. So we have to use a lot of templates for that. And then particularly the SQL standard which have to use a lot of templates for that. And then particularly the SYCL standard, which we work on a lot, is a very heavily templated C++.
Starting point is 00:06:31 I'm not familiar with that, I don't believe. What is that? So SYCL is a high-level single-source C++ programming model for heterogeneous systems and parallelism. So if you're familiar with OpenCL, it's kind of a higher level than OpenCL. So similar to CUDA, but it's all built using completely standard C++. Interesting. And it supports, I guess, OpenCL or whatever GPU hardware on the back end? Yeah, so the idea is it's mostly commonly associated with OpenCL, but you could have other backends, so things like HSA or maybe Vulkan Compute, things like that.
Starting point is 00:07:11 Okay, interesting. That's a technology we're working with a lot and using it to port things like TensorFlow over to OpenCL because it's a much nicer programming model to work with rather than OpenCL, which is quite verbose at times, shall we say. I have not actually done any GPU programming at all myself. And maybe, again, this is something we could talk about a little bit later, but do you have any recommendations for someone who wants to get started in GPU programming? I think having a look at some of the tutorials on the AMD website,
Starting point is 00:07:45 if you're looking for OpenCL or the CUDA website, sorry, on their various CUDA tutorials. I also did an introduction to SYCL blog post on my blog, so that's a good one to look at. It's meant for the C++ programmer rather than the GPU programmer. So maybe that's even a good resource to get started with. Okay. And what is your website again? blog.tartanlama.xyz
Starting point is 00:08:13 Okay. You'll have to include a link to the Sickle blog post. It's interesting learning a little bit more about that. So Simon, we've got a couple news articles to discuss. Feel free to comment on any of these, and then we'll start talking more about your keyboard and your interest in debuggers and everything else you've got going on. Okay?
Starting point is 00:08:31 Yeah, sure. Okay, so this first one is actually a post on the C++ London user group's message board on meetup.com. And they're trying something new where they're going to be putting together what they call C++ London University. And the basic idea is that they recognize that the average user group attendee is already pretty experienced in the language,
Starting point is 00:08:56 but they occasionally get people coming in who maybe are still students or they're just programmers who are more familiar with other languages and they want to learn a little bit more about C++. And they're trying to put something together to target those types of attendees who want to just learn more about C++ from more of a beginner level. And their idea is to put together this kind of like coding dojo type thing where newer programmers could be paired with more experienced members of the community. It sounds like a pretty good idea, and I was wondering what your thoughts were on this, Simon, as an organizer in the Edinburgh user group. Yeah, I think this is something
Starting point is 00:09:36 which is really valuable. We've talked about it briefly quite recently for our meetup as well, having something which is more aimed at beginners because we'll have a time at the start of our meetup as well, having something which is more aimed at beginners, because we'll have a time at the start of our meetup where we say, oh, so what's everyone interested in? Why are you here? And a lot of people say, oh, I'm a student, or I'm just learning C++, and
Starting point is 00:09:56 I want to kind of get more of a feel for language. And we say, great, you're very welcome here. And then we have two talks on crazy metaprogramming tricks, and I have no idea what's going on. So I think something like this is really valuable, and they have some great teachers and speakers in the C++ London group. So I think it's a really good idea,
Starting point is 00:10:17 and I hope it goes really well. Maybe we can steal it for our Edinburgh group. Let them prove it for you first. It is true that the C++ London community as well, I mean, lots of friends of the podcast anyhow, shall we say. There's lots of people who we know there. Yeah, definitely. Okay, next one is from the Visual C++ blog,
Starting point is 00:10:41 and this post is C++ 17 features and and STL Fixes in VS 2017 15.3. And this article is authored by STL. And one thing I noticed immediately when breezing through the article is a numerous meow and kitten references, which I don't think I would have noticed without talking to STL during our interview a couple months ago. But now they really jump out at you. Yeah, I didn't even actually realize that STL was the author, although I think I probably assumed that he was.
Starting point is 00:11:15 But as soon as I saw the first meow, I'm like, yep, definitely STL. But there is a lot in this. Yeah, apparently this 15.3 release is supposed to be pretty big as far as new C++ features and improvements come. And this is just one of, you know, they'll kind of do like a blog post dump right before a release. And this one came out five days ago. And then there were four more posts three three days ago i think about the new features in visual studio for c++ developers um so definitely encourage everyone to to go and
Starting point is 00:11:53 check those out i actually just upgraded to 15.3 i started a few minutes before we got on the air and it just finished up well and also we didn't mention uh that GCC 7.2 was just released a couple of days also ago, something like 90 bug fixes in it. Wow. But I do have a couple of questions about this Microsoft update. The first one, and the correctness fixes, fixed missing specialization of autopointer void. That was my favorite one, definitely. Isn't autopointer officially removed in c++ 17 yeah so i guess i don't know if this is a back port for um if you're running it in a older standard yeah i think i saw something about this in the comments actually and
Starting point is 00:12:39 and they did say that they're fixing it for c++ 14. That still was never a good idea. Sure. Yeah, and that's true, I guess, in later, the most recent versions of MSVC, you can actually choose which standard you want finally. Yeah. Yeah, it made me laugh. Okay, and then this last article is from Meeting C++.
Starting point is 00:13:06 And I think we talked just a few weeks ago about this idea that Jens Weller started with C++ reviews for libraries that don't necessarily want to get involved with something big and kind of complicated like Boost, but they want to get some feedback on their libraries. And he put together this new subreddit called CPP Review and if you are interested you can now go and submit a comment after looking at these two first libraries that are for review Bulk and Dynamics
Starting point is 00:13:36 and I checked the subreddit and both of the posts do have a couple comments with people giving feedback. I think Dynamics was getting a bunch of good feedback and people saying that they accept the proposal. Yeah, one of the things I liked about the review of Dynamics was the reviewer who called out, like, they made specific comments on CMake usage in there
Starting point is 00:14:05 and how to apply best practices into the CMake also, which is I think people are becoming more aware of the fact that you need to be, you know, using best practices and treating your build tools, you know, seriously. But I thought it was good to see someone reviewing the CMake file also. Yeah.
Starting point is 00:14:23 Yeah, I know one thing Gore brought up when we had him on and we mentioned this was he was a little concerned that maybe there wouldn't be people willing to, you know, spend some time reviewing these libraries. But it seems like, at least initially, that it is getting some attention and some interest in doing it. So that's good. Yeah.
Starting point is 00:14:39 I think my only real concern looking at the first reviews is that they need to have some kind of shared idea of how much time should be spent on reviews or the kind of amount of feedback they should have because you look at them and I think at least when I looked at one of the reviews was this
Starting point is 00:14:57 long really great list of points of pros and cons and constructive feedback and it was obvious that the author had spent a lot of time looking at the library and constructing feedback and then there was another review which was just, yes it's good
Starting point is 00:15:14 except and Jens said in his original post that he wanted this to be that you have a badge to place on your library or something saying saying oh this is verified by the C++ review community
Starting point is 00:15:29 I think if that is to hold any weight then there needs to be a good idea of quality in the reviews otherwise it's just a badge which anyone could achieve if they appease enough people on the Reddit.
Starting point is 00:15:48 Right. Yeah, from that standpoint, it doesn't seem quite as rigorous as the boost review process, I guess, which we've talked about a lot lately. Yeah. But it has different goals, too. Sure, yeah.
Starting point is 00:16:02 And we're actually going to have Jens on, I think, next week, so we'll definitely be talking more about this, I'm sure. Oh, too. And we're actually going to have Jens on, I think, next week. So we'll definitely be talking more about this, I'm sure. Okay. Okay. So speaking of meeting C++, you're going to be speaking there in a few months, right, Simon?
Starting point is 00:16:19 Do you want to tell us a little bit about what you have planned for your talk there? Yeah, sure. So I'm going to be speaking on how C++ debuggers work. So it's quite a large topic, especially this will be my first talk at a major conference like this. So I definitely started small. My main idea for it was, so I got into debuggers in my first job which is at Codeplay my first project was maintaining a compiler
Starting point is 00:16:50 and debugger for OpenCL and the first thing I thought was well I know nothing about debuggers so I'll go and research them surely there should be some great resources on how debuggers work and turns out there aren't there are a handful of posts um
Starting point is 00:17:08 eli bendersky i don't know pronounce his name but he has a three um a series of three blog posts about um debuggers which is quite excellent but they don't actually show you like here's how all of these different pieces work and fit together and here's how you would actually write a debugger and things like that. So I ended up just reading the sources for LLDB and learning that way. And now, like four years later, I'm now in a position where I actually do know quite a lot about debuggers. And so I was talking with some of my colleagues and saying, oh, yeah, there's still not any great resources on debuggers there. Actually, you know what, I should make some.
Starting point is 00:17:51 So this Meeting C++ talk is part of that and then I also have a 10-part blog post series on writing a debugger for Linux. So it goes all the way from starting the process to setting breakpoints on addresses to setting breakpoints on source lines and function names and reading variables. And then it goes off on some advanced things that you might want to add yourself, like threading support or shared library loading and things like that. So I tried to cover all of the major topics that people would want to know about debuggers.
Starting point is 00:18:26 And then this talk, I mean, C++ is hopefully going to be a kind of video which I could send to people as a good resource for the company as well. If we get a new debugger project and we need people and they don't know about debuggers, we can say, well, read this talk. Sorry, watch this talk. And that can be a good starting point. So that was the kind of aim for it. So there's a handful. I mean, there's at least GDB and LLDB. And I know a couple other lesser-known debuggers that are open source.
Starting point is 00:18:56 Kind of curious why you decided to start by reading the source to LLDB specifically. Yeah, so that's a lot because all of the toolchains which we work on at CodePlay are LLVM based so the debugger projects that we do are built on top of LLVM so it made sense to
Starting point is 00:19:15 read the sources in order to understand debuggers and also LLVM because they would have to work on it but LLVM is also quite nicely architected for the most part and has a fair amount of explanation, some of the header files and things like that. So it was a good enough base to just kind of get stuck in
Starting point is 00:19:35 and start understanding things. And you mentioned it was a 10-part article you ended up writing. That's a pretty big commitment. Yeah, it took me about three or four months. I ended up with that's a pretty big commitment yeah it took me about three or four months ended up about 10 000 words or something so uh yeah it took a while did you know it was going to be 10 parts when you started um no i originally planned it to be three and i said oh i want to write about this and i want to write about that and i need to go into more details about this and yeah so it it got out of control a bit yeah when i heard 10 parts i wondered if this was one
Starting point is 00:20:10 of those projects where you wouldn't have started it if you had known how big it was going to end up being yeah that's probably right what are uh some of the more interesting things you learned about you know programming while writing these C++ debuggers? I think the most interesting one was when I started the blog post series, I knew pretty much all that I wanted to write about beforehand, and I understood all the concepts already. I just had to put them into words. But the one thing which I never understood, could never quite get my head around, was how the debugger traced loading of shared libraries on Linux.
Starting point is 00:20:51 So I had a look at the sources for LLDB and just did not understand it at all. I knew it relied on some arcane communication with the dynamic loader, but I had no idea how it actually worked. So eventually I said, okay, right, if I'm going to write these posts, I need to understand this. So it turns out that the dynamic linker
Starting point is 00:21:12 puts a structure into the processes address space, which is updated every time a shared library is added or removed so it has like a linked list which is stored in your program's address space and you can go and parse that to look at all of the shared libraries which are loaded then the really interesting thing is how do you get told when something is loaded or unloaded so the structure also has an address in it, which points to a function which is called every time a library is loaded or unloaded. So internally to your debugger, you can set a breakpoint on that.
Starting point is 00:21:55 And when you hit that breakpoint, you know that there's been a change and you can read the linked list and update your internal data structures. So that was kind of a really fascinating point for me to finally understand. And when it clicked, I was like, okay, I know how to implement this now, and I could build a little proof of concept and things like that. So that felt good when I finally got it.
Starting point is 00:22:19 So to make sure I understand that, that linked list is in every Linux process, regardless of whether or not it's being debugged um yes i think anything which is um links against any dynamic libraries um right maybe even not i'm not sure if it would eliminate it it's essentially the the underscore dynamic section of the elf file is okay the process so anything which has that on linux will have this this structure and then the debugger just takes advantage of that fact yep cool so how uh excuse me how has working on this debugger changed the way that you program c++ i don't think it's so much changed how I program, but it's certainly helped me understand and use the tools more effectively,
Starting point is 00:23:14 particularly when there's a problem. So actually shortly after I was looking into this dynamic loader thing, I was doing some remote debugging with GDB, and I got this error message it said oh error cannot find the um dynamic linker function to set a breakpoint on it i know what this means now i wasn't just like frantically googling for something which i didn't understand i actually had some context to base it off of and I knew what the debugger was trying to do, and I knew why it was failing, and I could then go and make the necessary changes to make it work. Whereas if I didn't know, I would just be like, Google error message, and it would probably give me the same your experience but to me it seems like that kind of error is the kind of thing that you would find three people who had the same problem 10 years
Starting point is 00:24:10 ago and they never posted the solution oh never mind i fixed it right no after learning all this info you have now about debuggers did you make any like contributions to either ldb or gdb or anything like that um i haven't yet i would like to um do some work on ldb which can actually be upstreamed um most did some work on it as a prototype to debug HSA systems, which is another heterogeneous programming standard. But it was very much a prototype and wasn't able to get upstreamed. I think I would like to work some more
Starting point is 00:25:04 on the threading model of LLDB. There are a few things that GDB has which LLDB doesn't, or at least has a better support for. Non-stop mode is one of them. So when you can have some threads, one thread stopped while the others are all running, LLDB kind of supports that, but it's mostly just in the
Starting point is 00:25:25 remote backend rather than actually reflected in the threading model of LDB. And then GDB also has a really nice follow forks mode for if you're forking off some child processes and you want to decide, actually now I want to debug the child rather than
Starting point is 00:25:41 the parent. GDB handles that really nicely, so it would be nice to stick these things in LDB as well. And maybe building on Rob's question, in a more general sense, is there anywhere that you see that debuggers could be improved to make debugging C++ experience better? I think a lot of the reversible debuggers,
Starting point is 00:26:01 like RR and UndoDB and things like that they're definitely going a really good way to solve a lot of the problems with more traditional command line debuggers I think that a lot of the problems going forward as we move to more heterogeneous
Starting point is 00:26:22 systems will be having debuggers which can handle multiple architectures on the same system. I've spent a lot of time on standards calls talking about this, and I do think that the best place to build that in is
Starting point is 00:26:38 at the operating system level. But getting those are some big changes, and getting those into the Linux kernel and things like that would be difficult. So I think that's a, an interesting path, which more research needs to be put into.
Starting point is 00:26:55 Great. I want to interrupt this discussion for just a moment to bring you a word from our sponsors. Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state.
Starting point is 00:27:25 Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. Do you want to tell us a little bit about the custom keyboard you worked on? Yeah, sure. So there are actually two of them now.
Starting point is 00:28:05 I started a new one. I'm right down that rabbit hole. The first one I did was a small 40% keyboard, so it didn't have your function key row or your number row, and it didn't have a numpad, and it had maybe a column shaved off or something. So it was very small because I wanted something portable which could be taken to
Starting point is 00:28:30 conferences and things like that. So I had to design it right from scratch. So there's a great site online where you can visually design your keyboard layout and then it will generate you a CAD drawing which you can send to
Starting point is 00:28:46 like custom laser cut shops and things like that so I did that I got CAD drawings for these plates and got aluminium plates cut at some place down in Cornwall and then they sent the plates up and I got switches from States and then just hand wired the entire thing so it's i'm using a tnc2 which runs a abr chip so everything every column and every row is just soldered together and then soldered to the microcontroller and it has diodes everywhere to prevent um like you pressing some keys another one showing up that was a really cool project um my one problem when i did the kind of first pass of it and i got everything working and i got uh the basic firmware done using this um tmk framework
Starting point is 00:29:40 because i was very um annoyed that the framework was all C and all macros everywhere. So I spent a lot of time debugging my keyboard, which was debugging these things is horrible at the best of times. There's an entire column on my keyboard which wasn't working. It took me ages to work out. I just missed a comma somewhere and a macro was screwing up. Oh, my.
Starting point is 00:30:10 If this was all in C++ with templates, this would be so much better. I was like, maybe I could build something which is better with C++. So I spent a few weeks writing firmware for C++ 17. So it's all, you give a kind of high-level description of your keyboard. So you say which pins on the microcontroller your columns and your rows are soldered to, and you tell it which parts of the matrix have keys soldered them and which ones don't, because keyboards usually aren't just like a straight matrix. They're staggered and have keys missing in different rows and columns and things like that.
Starting point is 00:30:54 And then you have to tell it what your key maps are. So you do that at a really high level with just enums and variadic templates. And then the library generates all of the codes to actually run the firmware because it's all done at compile time and with templates it's actually got a lot of room for optimizations so as i noted where some keys won't actually be present in your matrix in most c firm firmwares they would loop over all of the keys in your keyboard and say okay well do I need to test this key?
Starting point is 00:31:29 Yes or no? Do I need to test this key? Yes or no? Do I need to test this key? Yes or no? And they'll do this every single time whereas they're always making the same decision it's just they're making that decision at run time whereas with my C++ firmware
Starting point is 00:31:44 at compile time I can say do I need to test this key ever at runtime. Whereas with my C++ firmware, at compile time, I can say, do I need to test this key ever? And if I don't, then it's never ever tested and it doesn't get into the final code. So you can actually... We should take a quick step back. So each
Starting point is 00:31:59 key on the keyboard is not individually addressable. You've got rows and columns, you're saying and so how are you actually testing to see if a key is been pressed so you test the keys being pressed by um i said this is simplified but essentially every key makes its own circuit with the microcontroller. So if you send power down some row and then test to see if you get any
Starting point is 00:32:32 current at the relevant column for the key you're trying to read, if you get current and the key is pressed because that closes the circuit and if you don't get any current and the key is not pressed because the circuit's still... The switches are just
Starting point is 00:32:51 closing the circuit or opening the circuit. Okay. And so you just do that for every single combination of row and column. Okay. So you're saying with your firmware you you are able to, at compile time, optimize away testing for spaces that you know are impossible to ever happen. Yeah, exactly. Were you able to show any empirically how more efficient your version is than the C version or anything like that? I haven't. It's something that I would like to do, some of the problem with this application of mechanical keyboards is if the user doesn't notice it, then it doesn't really make a difference. I mean, you can say, like, oh, I can do so many different loops of my, of reading my
Starting point is 00:33:38 keyboard or in such and such a time, but if it doesn't make a difference to the user, then it's not really making a difference. But I still thought it was an interesting approach of just a high-level template description and trying to get as optimal code as possible. I think for the mechanical keyboards, there's more usability of the API, which is the good thing to come out of it.
Starting point is 00:34:07 But I think there would be a lot of other applications where you could have kind of template-based embedded domain-specific languages, which you can use to very aggressively optimize the final code. So the AVR that you're using for your control, that's an 8-bit CPU, right? I literally do not know. Okay. But it's a very tiny platform regardless. Yeah.
Starting point is 00:34:34 And no problem modern C++ compiler with it. Yeah, I mean, I don't... I just built GCC from source, and I can't use any. But the standard library for C++. So anything I needed, I just wrote myself, and it was fine. Right. Cool. So you said you built the first keyboard as a really small, portable one that you could bring with conferences. What's the second keyboard you're working on?
Starting point is 00:35:01 So the second one is a split-hand, which means that it essentially looks like two keyboards one for each hand and they're connected by an audio cable um so split hands and each hand is kind of a pooled ergonomic design so if you've ever seen the Kinesis Advantage I haven't. I think I know something about that. Yeah, it's quite a popular well, relatively popular mechanical ergonomic keyboard. This is kind of like
Starting point is 00:35:36 the Kinesis Advantage but instead of one unit, it's one unit for each hand. So it's a lot smaller takes up a lot less desk space and I can choose all the switches myself and things like that but it turns out because the the keys are in a kind of pool rather than just um flat on your desk it's really difficult to hand wire especially if you have terrible soldering skills like I do.
Starting point is 00:36:08 You said you ordered your key switches from the US. Are you able to get high-quality keys? Yeah, there's, as I said, deep rabbit hole. There are whole communities dedicated to these things. People build custom switches and get exactly what they want and things like that. So, yeah, it goes deep. But you did not go the route of building custom switches yourself? I did not. I did get some community-designed ones, and they are very, very nice.
Starting point is 00:36:40 Interesting. I'm also curious about the interconnect. You said you're using an audio cable between the two halves? Yeah, so it has a microcontroller on one hand and then an input-output expander on the other hand. So it communicates through that. And then the audio cable just so happens that it has enough wires to communicate easily. Okay. Maybe this is a silly question, but could you have made the two halves each individually their own separate USB keyboard effectively? You could, and I think some split keyboards do that,
Starting point is 00:37:16 but if you want to hold down a special modifier key and have that change the layer of your keyboard then it's best to do that with a single microcontroller because otherwise you'd have to like communicate with the operating system to say okay i press the special modifier and this should change what the other keyboard is saying so it's easier to do if it's just one single controller so generally speaking if you have multiple keyboards on a computer, they're completely independent from each other. Like if I hit caps lock on one keyboard,
Starting point is 00:37:50 it's not going to turn on caps lock on the other keyboard? Or do you know? No, that probably would turn on caps lock because the normal modifiers are built into the USB protocol. It's only if you had special layers on your keyboard that you would need something like I was describing. So if you had to implement the USB side of it yourself, or is that something built into the platform you're using? That's something where I found a very shady-looking C implementation. Which I should probably rewrite at some point.
Starting point is 00:38:27 But on the operating system side, it's a standard USB HID device or whatever. Yeah, exactly. Okay. That's really cool. Yeah. Do you want to tell us a little bit about the work you do at Codeplay Software? I don't think I've heard too much about that company before. Yeah, sure.
Starting point is 00:38:43 So, as I said, we work on heterogeneous platforms. So, we're very involved with the Kronos group and specifications for bringing parallelism to as many systems as possible. I said Cicla is kind of one of our main targets at the moment because we quite firmly believe that as the industry moves towards having more specialized hardware for more specialized domains, you need to have some high-level programming model in order to get performance portability. So if you have lots of different vendors competing over different parts and you don't want to train your programmers to code this programming model for this component and this one for this one and this one for this one
Starting point is 00:39:38 and then integrate all of those programming models together, you need a good high-level model. So that's what we think sickle can support as it's a single source programming model so that means that rather than something like open CL where you have your host code which expends up your device and tells it what the arguments to your kernel are and allocates memory and things like that and then you have your device and tells it what the arguments to your kernel are and allocates memory and things like that. And then you have your device code,
Starting point is 00:40:09 which is the actual code you want to run on your GPU and things like that. And those are written in two different languages and source files. So OpenCL has its own C dialect with its own set of built-ins and things like that. But that's not a very nice programming model to work with because you have to explicitly deal with the compilation of the separate language and things like that, whereas SQL allows you to just say, okay, here's a lambda or a function or a function object. I want to run this on the GPU.
Starting point is 00:40:49 Here's how I want to run it. Here's how the data should work. And you let the compiler and the runtime figure it all out for you. So it's a little bit different from CUDA as well. In CUDA, you have to explicitly say, okay, this function is a device function. I want to run this on device. Please compile or compile this for the device. Whereas on SYCL, you can say,
Starting point is 00:41:13 here's a normal sqls plus function, and it calls some other sqls plus functions. And it's up to the implementation to work out every single function which you want to call on the device and all the functions which are called by those and then compile them separately. So it essentially requires multiple compilers for the same program, but all of the compiling for different devices
Starting point is 00:41:41 is just handled for you magically. Wow. But you can use modern C++ stuff with it? Yeah, so it's all C++ 14 and 17. So, for example, there's an implementation of the parallel SDL using SYCL. Okay. So is SYCL an open source project? So it's an open standard developed by the Kronos group. Okay.
Starting point is 00:42:13 And so CodePlayer might be a very heavy contributor to the SYCL standard as well as OpenCL. So what operating systems does it support? So the Cycle itself is just a standard, so it's agnostic to platform. The implementation, which Codeplay have, is currently only running on Linux.
Starting point is 00:42:40 Okay. Sounds very interesting. Do you maybe have any advice about running meetups? I know you've been running the Edinburgh C++ user group. Do you have any advice for people who might want to start their own user group? Yeah, I think a lot of the considerations are the same as for any community physical meetup which you want to run. You need to have a venue which actually supports the number of people you want and the kind of talks you want to give. Probably good to get some sponsorship, especially because sponsors will often help you find a venue or host it themselves if they can. And then a lot of it is reaching out to speakers.
Starting point is 00:43:31 We've had some difficulties getting speakers at some points, and then other meetups where, like, who wants to speak? And we get too many people and we have to choose um so it's good to um if you do have to choose try and get a good diverse range of topics and of speakers um so that it's not just as i said like here's a bunch of crazy mech programming talks uh if you don't understand this well tough i think it's um the thing which i've most appreciated about um the meetup which we've been running for um i guess a couple of years now maybe maybe one year a while now is that um we actually have built up a sense of community so whereas at the start um we would have a meeting every few months and you would see people and maybe you kind of recognize them and you would talk about something
Starting point is 00:44:32 and then you would go away and come back the next time and maybe talk to some other people now we're at a stage where um people actually know each other they know what each other work on, they can talk about problems that they've been encountering, get enthusiastic about C++. So I think the community aspect is really the most important, and that takes a lot of intentionality in how you format the meetup and in the language that you use and in the facilities that you have available. And if you decide to go out somewhere after the meetup, things like that.
Starting point is 00:45:12 So I think those are the most important considerations for me. So what would you say, I mean, specifically that we can do to try to build that kind of community in our meetings, besides going out for beer afterward i think a lot of it is making sure that there's the space for the community to grow um so if you if you just come in and you have some food maybe and then you have some talks and then you go and there's no space for a community to grow. You need to have a kind of intentional part of your meetups where you say, okay, have a chat, get to know each other. As an organizer, as a speaker, you can then go around this area
Starting point is 00:46:02 and try and get conversations started, get people talking about what they're interested in because um a lot of people who come to our meetup um as soon as you get them talking about something they're interested in like that's it you get great conversations for for the rest of the meetup it It's all about making people comfortable enough to actually enter into that kind of feeling. Because if they're not comfortable, then they're not going to talk. Okay.
Starting point is 00:46:35 Okay. Well, Simon, it's been great having you on the show today. You obviously have a lot going on. Where can people find you online and read more about the stuff you're up to? Yeah, so you can get in touch with me on twitter I am at tartanlama my blog is blog.tartanlama.xyz
Starting point is 00:46:53 and you can the C++ Slack channel on probably most of the sub channels which are there so feel free to grab me if you want to ask any questions about debuggers or compilers or GPGPU or keyboards or just C++ in general.
Starting point is 00:47:12 Yeah, so those are probably the best places to get me. You do seem to kind of always be around on Slack. It makes me wonder what time zone you live in or something. I find it's a good way to um like i'm stuck on a problem at work or something i can take a break from it and solve some small
Starting point is 00:47:34 problem that someone has on slack or something and then i can come back and i'm still thinking about um programming and c++ and problems but it just gives me a break while still learning things and helping people. Very cool. Yeah, for our listeners who haven't checked out the Slack channels yet, it is a great way to get questions answered and meet other C++
Starting point is 00:47:58 developers. Okay. Thanks again for your time today, Simon. Yeah, thanks very much for having me. Thanks for joining us. Thanks so much your time today, Simon. Yeah, thanks so much for having me. Thanks for joining us. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic, I'd love to hear about that too.
Starting point is 00:48:17 You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Leftkiss on Twitter. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.