|
giogadi posted:I always find it sad when we have to give context like “it’s for an assignment” to justify doing something in a weird (or worse) way. Surely if something is worth learning about in school, then there must be some way to apply it that actually makes sense in practice too. For what it's worth, I wouldn't reach for lockfree as a default option for a low-contention shared queue in the real world either. It seems insane to me that there isn't a simple blocking synchronized bounded queue in the stdlib or boost.
|
# ? Mar 22, 2024 17:57 |
|
|
# ? May 2, 2024 22:12 |
|
giogadi posted:I always find it sad when we have to give context like “it’s for an assignment” to justify doing something in a weird (or worse) way. Surely if something is worth learning about in school, then there must be some way to apply it that actually makes sense in practice too. Good classes are trying to teach you how to solve problems which are much more complicated than can actually be solved in a one-week (or even one semester) assignment, and they usually do that by having you apply solutions to problems that you don't actually have and hope that you learn how to apply them when you do have those problems. The typical end result of a school assignment is a pile of code that you immediately throw away because it doesn't actually do anything useful. You're allowed to write throwaway code for educational purposes without it literally being an assignment, but you should not confuse the process of completing assignments with solving actual problems.
|
# ? Mar 22, 2024 19:53 |
|
Twerk from Home posted:For what it's worth, I wouldn't reach for lockfree as a default option for a low-contention shared queue in the real world either. Even for a high contention, is not always the best option. Mutexes are not the devil. Well .. not always. Blocking and allowing other threads to do stuff can sometimes yield better overall performance. Or sometimes the usage of resources is a bit more important than being lock free. Of course, this should all be benchmarked for your use case to determine which option is absolutely better.
|
# ? Mar 22, 2024 21:35 |
|
That question got me thinking: Do colleges today have assignments along the lines of "Find available libraries that implement X, discuss some details about how to use them and conceptually how they work"? The idea being that sometimes you need to write it, sometimes you need to find it, and focusing too much on either part is dangerous.
|
# ? Mar 23, 2024 19:54 |
|
Over 10 years ago, and a different country, but I did have something like that for cryptography class. Each student would get a random algorithm and needed to create a program that would encrypt/decrypt a file with a password in ECB/CBC/OFB/CFB modes. Language and library choice was up to the student. I managed to get a very niche one (MARS) that the only library I found was with a bespoke Eclipse+Java installation.
|
# ? Mar 24, 2024 09:35 |
|
ECB, the "why does it exist, it's basically useless" mode?
|
# ? Mar 24, 2024 14:17 |
|
Sure? All the negatives about it were given at the lectures, but it was still a good starting point for all the clueless students for interfacing with the various libraries and designing the file format, since there were fewer parameters needed to pass along and you could debug any errors easier if you saw one block with an error instead of half the file.
|
# ? Mar 24, 2024 16:01 |
|
Is there any way to tell a linker script to put a data structure at a specific location in memory? My situation is that I'm working on an embedded microcontroller with two processors and I want to set up some FIFO queues to pass messages between them. Each processor has its own project with its own linker script, but they need to agree exactly on where the FIFOs are located so they can take turns reading/writing data. What I am doing now, which works but feels sub-optimal, is manually declaring a variable in each linker script that contains the base address of a section of memory that both processors can access. Then there is a code file that is common to both processors that reads that address variable and assigns it to a struct pointer that defines my FIFOs. That makes both processors access the FIFO structs at the same memory location which basically works. But there is nothing stopping some other code from also declaring a variable in that location which would lead to a real fun bug. Is there a better way to do this?
|
# ? Apr 13, 2024 02:41 |
|
Casting an integer to a pointer to your struct is by far the easiest and most portable way.
|
# ? Apr 13, 2024 02:50 |
|
Your linker scripts should define two separate memory segments: - One for memory that's private to that processor, which should accept all sections that aren't explicitly targeted elsewhere - One for memory shared with the other processor For the definitions of locations within the shared memory segment, include the exact same file from both linker scripts. This file should declare your FIFO section and tell the linker to place it in the shared memory segment. Enforce (through code review or tooling) that nobody explicitly targets the shared memory segment from outside the common file.
|
# ? Apr 13, 2024 03:00 |
|
giogadi posted:I always find it sad when we have to give context like “it’s for an assignment” to justify doing something in a weird (or worse) way. Surely if something is worth learning about in school, then there must be some way to apply it that actually makes sense in practice too. And so on, Sure. I'd tend to agree
|
# ? Apr 13, 2024 04:00 |
|
rjmccall posted:Casting an integer to a pointer to your struct is by far the easiest and most portable way. I agree with this. Also, if at all possible, the integer should come from a header file supplied with your platform instead of being copied into your source code from a pdf
|
# ? Apr 13, 2024 10:21 |
|
Thanks for the replys!rjmccall posted:Casting an integer to a pointer to your struct is by far the easiest and most portable way. Qwertycoatl posted:I agree with this. OK, that sounds pretty much like what I was doing, just with the extra step of getting the value out of the linker script because I was thinking that that is the place memory architecture should be described. I like the idea of getting the memory address out of the chip header file though, I'll take a look and see if it's defined in there. Jabor posted:Your linker scripts should define two separate memory segments: That's kind of the setup I started with, but then had the paranoid thought that if future-me ever forgot about the details and allocated another bit of memory in this shared bank to be used by only one processor, that' processors linker might stack things in memory from the base address as (new item, FIFOs) while the second processor's linker would just have (FIFOs) and they wouldn't agree on the FIFOs address. This makes me think that maybe it would be a good idea to comment out references to the shared memory entirely from the linker scripts while adding a note stating why I did that. Then future me can't would not be able to put anything else there by just giving it an attribute, I'd have to open up the linker script and (hopefully) run across my old warning comments.
|
# ? Apr 13, 2024 17:03 |
|
PDP-1 posted:Thanks for the replys! if you want to be that paranoid, declare a custom section the size of your fifo in each linker script that doesn't get initialized, then declare the fifo data structure by value in each place with an attribute(section) and take the address of that instead of binding a pointer to a linker symbol. the compiler will treat that memory as used and fail to compile because it doesn't have enough room if you forget and try to put something else there.
|
# ? Apr 13, 2024 21:00 |
|
What's the preferred way to define macros that influence the behavior of headers you include? For example, an application I work with uses Armadillo without the wrapper, so we link directly against libblas and liblapack via:C++ code:
code:
But then I saw that if we make this configuration in armadillo's own headers, then CMake can correctly figure out what to link without me having to specify it: https://cmake.org/cmake/help/latest/module/FindArmadillo.html. I can't think of a sane step in our build though to set this via editing the file include/armadillo_bits/config.hpp, as recommended. https://arma.sourceforge.net/docs.html#config_hpp Thoughts?
|
# ? Apr 29, 2024 22:00 |
|
You could set up a header file that defines the symbol and includes all of the Armadillo headers, and then just include that elsewhere in your application.
|
# ? Apr 29, 2024 22:58 |
|
Twerk from Home posted:
I think that - if you’re not controlling the armadillo source (like it’s an open source project and the reader says “install armadillo-dev before building” imo you’re stuck with using a define, and probably you should do what ultrafilter said, and probably you should have a full definition set there not just that one - if you’re controlling the armadillo source, like downloading it with external_project or a prescript, then sed it in place in the bits header, i guess Idk I kind of hate configuration like that but if it’s all under my control I’d do the second
|
# ? Apr 29, 2024 23:11 |
|
ultrafilter posted:You could set up a header file that defines the symbol and includes all of the Armadillo headers, and then just include that elsewhere in your application.
|
# ? Apr 30, 2024 02:10 |
|
Twerk from Home posted:Thoughts? The idiomatic thing is to set the define via your build system.
|
# ? Apr 30, 2024 16:33 |
|
Ralith posted:The idiomatic thing is to set the define via your build system. This is what my gut says, but I wanted some outside confirmation. OneEightHundred posted:This is what I've been doing for windows.h for a while, and it works well. Only need to update one file if you need to adjust the preprocessor defs needed to make it behave not-stupidly. This feels OK for libraries like armadillo that expose everything through a single header, but feels really awful for libraries with finer-grained headers because you'd end up including the complete set of what every file needs, and it would break tools like https://include-what-you-use.org/ that are designed to keep your includes clean. I despite configuration like this, almost as much as I hate compile-time options.
|
# ? Apr 30, 2024 18:54 |
|
How about #include "all_my_configuration_defines.hpp" #include "the_finer_grained_library_header.hpp"
|
# ? Apr 30, 2024 20:24 |
|
One major drawback to defining configuration macros anywhere but in your build system is that you'll probably miss them if you include any third party headers that transitively include the header you want to configure.
|
# ? Apr 30, 2024 21:23 |
|
It's also just way more complicated in general. Setting configuration defines is a very basic thing that every build system handles well because it's something that every non-toy C project needs to be able to do.
|
# ? May 1, 2024 00:13 |
|
|
# ? May 2, 2024 22:12 |
|
Once you start getting more than a dozen or so -D flags, yeah consider making it part of a configuration step. I've used Kconfig for a few larger projects that peppered -D flags everywhere in bashfiles and makefiles. Everytime you find yourself writing "if X set, make sure Y is also set" type of statements in your build system, do yourself a favor and use KConfig to generate a nice header with #defines for you.
|
# ? May 1, 2024 20:11 |