RIP Syndrome posted:

Rust seems nice. It's a bigger language, though, and it doesn't support dynamic linking yet.

netcat posted:

Every time I take a look at rust it just seems ugly, verbose and complex and I immediately lose interest.

VikingofRock posted:

I thought you could just specify crate-type="cdylib". Is there some issue with doing so? I haven't actually played around with dynamic linking in Rust.

quote:

Rust has been committed to a stable language and API since 1.0, but ABI stability has never been claimed. Your code is compatible; your binaries are not.

Subjunctive posted:

xgalaxy posted:

One Rust project I like to look at is: https://github.com/ggez/ggez
I find it to be a good example of easy to read and reason about Rust code that isn't complex for complexity sake.

Blotto Skorzany posted:

Looking through the source, I see some functions with names that end in !, which I assume they got from scheme. Did they also pick up the convention of ending functions with ? to indicate that they return a boolean?

Ralith posted:

Nix with a binary cache is a very powerful solution to this kind of problem, but probably the better solution is to fix your project not to require a patched Qt.

Brownie posted:

Does anyone have any advice on how to debug broken preprocessor statements? I tried adding tinygltf as a dependency to my rendering project and on Windows I start getting all these syntax errors in other, unrelated dependencies as soon as I include the required preprocessor #defines in my code. I am not even sure how preprocessor stuff gets evaluated -- is it lazily evaluated using import order?

Also I have a feeling this has to do with both tinyglft and bgfx having stb_image as a header only dependency that also requires its own preprocessor definitions... but I really hope not!

Brownie posted:

EDIT: Hmmm I may have spoken too soon. It's not bx that has the #define STB_IMAGE_IMPLEMENTATION, it's bimg (also a BGFX dependency) but the problem does go away when I move the bx import... time to do some more digging.

RIP Syndrome posted:

The way it's set up it's important that STB_IMAGE_IMPLEMENTATION is defined before one and only one instance of #include "stb_image.h". You could potentially #undef it yourself between #includes. There're also some random macros still set after the inline code gets emitted which might hork things up.

I really don't like the practice of making definitions via headers, it causes messes like this. If you have to do it, at least provide a macro that lets you namespace the generated code, i.e. MAKE_FUN_BOILERPLATE(mynamespace)

Alternately they could've just protected the definitions against multiple inclusion like they did with the prototypes (#ifndef STBI_INCLUDE_STB_IMAGE_H etc).

Also don't exclude the possibility of the problem being in some other part of the included sources

Brownie posted:

I created a "minimal" reproduction here, where I'm only include BGFX (and its helper libs) and tinygltf: https://github.com/BruOp/tinygltf_bug_reproduction

Lime posted:

Compiling with MSVC, I got these (excerpted) errors:

code:

[...]\bx\include\bx\bx.h(51): error C2988: unrecognizable template declaration/definition
[...]\bx\include\bx\bx.h(51): error C2059: syntax error: 'const'
[...]\bx\include\bx\tbx.h(51): error C2059: syntax error: ')'
[...]\bx\include\bx\bx.h(55): error C2988: unrecognizable template declaration/definition
[...]\bx\include\bx\bx.h(55): error C2059: syntax error: 'const'
[...]\bx\include\bx\bx.h(55): error C2059: syntax error: ')'
[...]\bx\include\bx\bx.h(59): warning C4002: too many arguments for function-like macro invocation 'min'
[...]\bx\include\bx\bx.h(59): error C2988: unrecognizable template declaration/definition
[...]\bx\include\bx\bx.h(59): error C2059: syntax error: 'const'
[...]\bx\include\bx\bx.h(59): error C2059: syntax error: ')'
[...]\bx\include\bx\bx.h(63): warning C4002: too many arguments for function-like macro invocation 'max'
[...]\bx\include\bx\bx.h(63): error C2988: unrecognizable template declaration/definition
[...]\bx\include\bx\bx.h(63): error C2059: syntax error: 'const'
[...]\bx\include\bx\bx.h(63): error C2059: syntax error: ')'

What happens on lines 51, 55, 59, and 63? Definitions of min and max functions. This made me immediately suspect somebody was including windows.h in a header somewhere, which infamously #defines a buttload of unhelpful junk and in particular all lowercase min and max macros. Sure enough, tiny_gltf.h itself does.

Two solutions: you can #undef min and max immediately after including tiny_gltf.h, or you can #define NOMINMAX before including tiny_gltf.h (which is really what tiny_gltf ought to do themselves, if they really must include windows.h in a header). Doing either lets me compile main.cpp just fine.

hackbunny posted:

A cute trick that Microsoft uses in their C++ standard library headers is parenthesizing the min and max tokens, like this:

C++ code:

template<> class numeric_limits<char>
	: public _Num_int_base
	{	// limits for type char
public:
	_NODISCARD static constexpr char (min)() noexcept

The preprocessor only matches function-like macros if they're followed by a ( token, so it'll leave those alone

hackbunny posted:

A cute trick that Microsoft uses in their C++ standard library headers is parenthesizing the min and max tokens, like this:

C++ code:

template<> class numeric_limits<char>
	: public _Num_int_base
	{	// limits for type char
public:
	_NODISCARD static constexpr char (min)() noexcept

The preprocessor only matches function-like macros if they're followed by a ( token, so it'll leave those alone

Brownie posted:

Didn't realize that this is valid C++, would assume you'd get a syntax error! I... don't know how I feel about this.

peepsalot posted:

Anyone familiar with design of interpreters and/or compilers? I contribute to an open source project that is sort of a compiler (but idk probably acts like an interpreter in some ways too), and I'm currently interested in optimizing how it handles scope and variable lookup. Currently it has a Context class that keeps its own unordered_map<string, Value> for variable lookup by name. It creates a Context object in every scope, and has a pointer to the parent Context, so to look up a variable, it tries to find the variable name string in the current map, and if not found, recurs up the stack to lookup the variable in the parent etc.

This seems really inefficient and I'm thinking about changing it to have a single "Context" that would be an unordered_map<string, vector<Value>>, so every time you go to a new scope you do a push_back of the value assignments onto the appropriate vectors and to find the current value you just read the last element in the vector, then you pop_back when you go out of that scope. Does this sound like a solid approach? I'm wondering if there are any particularly performant interpreters that have other methods of doing such things.

Bruegels Fuckbooks posted:

does your language have anonymous functions/lambdas? if scope capturing is in your language, your approach definitely isn't going to work.

peepsalot posted:

This seems

rjmccall posted:

Optimizing the representation of the local-variables dictionary shouldn't be particularly important for you because it should be an aim of your implementation to avoid ever doing lookups during actual evaluation. What you can achieve here depends a lot on the semantics of your language, but the right first step is generally to flatten all of your locals into a vector and resolve all locals to an offset into that vector at parse-time. Keep track of how many local variables there are, and whenever you parse a new local variable, store the current count in the dictionary for that name and then increment the count. If locals have sensible lifetime (unlike, say, in JS), you can reset the count whenever you pop a scope. The key thing is that now you can write that index down in the AST instead of the variable name, both for the declaration and for any references to it, so you won't have to do a dictionary lookup during evaluation. In a totally lexically-scoped language, you can actually throw the dictionary away completely after parsing; if you have dynamic-scoping features, you will need to preserve the dictionary to support dynamic lookups, but at least you won't be doing that for every local-variable reference.

The next step beyond that is to recognize that you don't need to allocate a separate vector of locals for every call because you can just use a single vector as a stack. In the parser, you remember the max number of locals that were alive at once, and then on function entry you just need to push space for that many variables, then pop that many variables on exit. Local variable access is then relative to whatever the depth was when you entered the function.

If you do need to optimize dictionary lookups (e.g. because dynamic-scope lookups are hot in typical code), there are a few techniques. The first is that you should intern your identifiers so that you can (1) avoid storing a hundred different copies of the identifier in your AST and (2) do lookups based on the unique string pointer instead of having to do a string hash every time. The second is just dynamic caching: a hot dynamic lookup will probably happen with the same functions on the call stack, so whenever you have to do the lookup, try to remember how you resolved it and then set things up so that you can quickly validate that you have the same caller stack and then immediately jump to the right offset. There are several ways to optimize that further, but don't bother unless it's important.

fritz posted:

I read your post as suggesting you weren't sure that this is a major part of the runtime, and just wanted to say please be sure to profile before you put in a lot of time doing optimizations.

rjmccall posted:

"Symbol table" is a pretty general term for any sort of lookup table in a language implementation. Your current identifier-to-current-value dictionary is totally a symbol table.

The right way to start is probably to do some silly refactor of the symbol table, like maybe rename the field that holds the dictionary and any obvious methods that access it. You don't have to commit that change, just make sure you know about all the code that accesses the table and (more importantly) why it accesses the table and what it's trying to do. What you're doing at this point is trying to understand the semantics of the language you're working on, and if you're working with some ad hoc, hacked-up scripting language that's going to be a pretty big step because those semantics might be pretty wild, and more importantly they might be pretty different from what you think the semantics are.

The next step beyond that is to just do what I said before, but without the phase distinction: that is, make the dictionary an unordered_map<string, int> that's stored right next to a vector<Value>. That's not an optimization — it's really a pessimization — but if you can get that working, the next step is just to try to build that dictionary "statically" when you parse the code.

Incidentally, it sounds like what you have here is an interpreter, not a compiler. Compilation means translating a programming language into some independently-specified language, often (but not always) a machine language (but possibly a virtual machine like the JVM or CLR). The line between that and an interpreter can get pretty blurry, but usually we call something an interpreter if it only translates the code into some fairly faithful representation of the original source which it can evaluate directly. If you've still got a symbol table and an expression tree when you're executing code, you've got an interpreter.

Jeffrey of YOSPOS posted:

When you say gaps, are those gaps with other things in them that you don't want to alias, or just unused space? You can used a packed struct with filler bytes there if they're just addresses that nothing uses. You can define macros/inline functions that give you the address of the nth version of this register.

Can you show an example with a gap you're worried about? I don't even necessarily need the whole thing. Fundamentally it's going to be repetitive to type in register addresses one by one but that's life, there's no way to solve this without telling the compiler the addresses or how to compute them, but it will do most of the arithmetic for you if you let it.

Jeffrey of YOSPOS posted:

Oh and there are packed bitfields within these - you can do bit-packed structs as well if you need to, though you should verify your compiler is doing it how you expect. I see why that can be a pain in the rear end.

Qwertycoatl posted:

If at all possible, get the register definitions as a header supplied by the hardware manufacturer, instead of pasting from the PDF. It's easy to make a very confusing mistake, and also it wouldn't be unusual for the PDF to be wrong too.

quote:

However you do it, you have to be reading/writing through something volatile or the compiler might skip out accesses that it shouldn't.

quote:

I've normally seen it done something like this:

code:

#define OVL_UI_FILL_COLOR_BASE 0x018 
#define OVL_UI_FILL_COLOR_SKIP 0x20
#define OVL_UI_TOP_HADD 0x080

#define write_reg(reg, val) do { *(volatile uint32_t*)(reg) = value; } while (0)
#define write_reg_idx(reg, idx, val) do { *(volatile uint32_t*)(reg ## _BASE + idx * reg ## _SKIP) = value; } while  (0)

(with all the register address #defines off in their own file, autogenerated from some machine-readable description of the hardware supplied by the manufacturer)