|
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
|
|
|
|
| # ? Apr 19, 2024 19:25 |
|
|
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
|
|
|
|
| # ? Apr 19, 2024 19:25 |
|
|
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
|
|
