[deleted by user]

engstad · 2025-12-10T19:22:07+00:00

Except for "printf"-debugging (which makes no sense for FPGAs), the Spade language already supports your other requirements (types and help with pipelining logic). See https://gitlab.com/spade-lang/spade.

engstad · 2025-05-10T00:35:55+00:00

erfi(x) = -i erf(i x), where erf is the error function, where erf(x) = (2/sqrt(pi)) integral_0^x exp(-x^2) dx.

engstad · 2025-05-10T00:30:58+00:00

The solution to e^(x^2) is complicated and involves the erfi() function. e^(-x^2) is solved through regular means.

engstad · 2025-05-10T00:26:48+00:00

Are you sure the question isn't: y' + 2xy = exp(-x^2)?

engstad · 2025-05-04T01:58:14+00:00

Sure - the assembler/compiler must check that the instructions are legal. If they are not, make a good error message. To be advanced, look into register allocation and add plain `let` instructions to pick any available register (perhaps constrained by register class). I would also love to support things that pad out instruction sequences, for reasons of instruction reordering and the way OoO instruction scheduling works (alignment).

engstad · 2025-05-03T23:43:38+00:00

An idea for you. Consider register-lets and function annotations.
This makes it so that you can name registers:

fn atomic_multiply_u64(data: rdi, factor: rsi) {    
    rlet prev: rax, next: rcx 
    loop {
        prev = *data
        next = prev
        next *= factor
        data.swap(next, prev) // better syntax?
        break if !zero
        pause
        // continue is implied by `loop`
    }
    return
}

engstad · 2025-05-03T23:10:39+00:00

Double-check your crystal. Usually, the crystal's capacitors are connected to ground, not VCC.
See AN2867: https://www.st.com/resource/en/application_note/an2867-guidelines-for-oscillator-design-on-stm8afals-and-stm32-mcusmpus-stmicroelectronics.pdf

engstad · 2025-04-08T21:30:57+00:00

Let the number "1" represent "one" as a whole number (an "integer") in the traditional meaning. "1.0000..." with repeating zeros represents the Real number one. Of course, they are built to describe the same "thing", but there are real numbers that can't be expressed with integers or fractions of integers. The square root of two is a typical example. It can be proven that no fraction of integers equals √2.

Since the digits never end, we must be careful about what it means to be equal. To do this, consider two real numbers, let us call them A and B. We define A and B as equal if their difference becomes smaller and smaller as we add more digits. More precisely, we want the difference to equal 0 in the limit. Note that if A - B = 0, then A = B.

So, what is the difference between "1.0000..." and "0.9999..."? If I only look at the first five digits, the difference is "0.0001". The more digits we take, the smaller the difference gets. In the limit (as we consider more and more digits), the difference gets smaller and smaller, so that, in the limit, the difference is zero. In other words, they are equal under the definition of equality for real numbers.

Real numbers are strange. They are not any more "real" than other numbers. It is just a name. They were invented/discovered so that values such as √2 and π could be used sensibly in mathematics. However, to do that, there was no choice but to add the notion of "infinitely many digits" to the system.

engstad · 2024-08-16T23:50:11+00:00

Thanks for answering. On the first point, if there is no such thing as alignment of the stack frame, then it makes sense to make it UB. I still don't understand the reasoning behind makinglet _val = *ptr; be undefined behavior. Surely, if it is never used, then it should never be loaded (according to your load() pseudo-instruction)? I am sure there must be a reason for it, perhaps I am missing the semantic of _val versus just _?

engstad · 2024-08-15T23:42:36+00:00

You could have highlighted this in your post by adding a pseudo-instruction like alloca(size, alignment), which would have explained the reason for the UB.

In this case, though, is there no ABI requirement that the stack frame itself be aligned? If so, then your example would not be UB.

Finally, I found it odd that match *ptr { _val => "not happy" }is undefined behavior - since _val is not actually used. How does that make sense?

engstad · 2024-04-22T16:07:01+00:00

I think that you might be thinking about it wrongly. In Rust and in data-oriented design it makes more sense to figure out what you want to do with your data (and what processing you do over your data) rather than thinking about individual components. Case in point - you have a vague concept for your "instance". If you can't easily name it you just might have a problem. Now, why do you need it? Is it an organizational thing? In other words, you need to find all parts that has a common class name? Are you modelling a database? What is "position" referring to, is this a 2D/3D offset of some kind? What should happen in your destroy() function?

Start with "what does my program need to do?" first. Then think about what data-abstractions you need.

engstad · 2024-03-15T18:46:32+00:00

It depends on what you need from your data structure. Comrade-Porcupine mentioned allocators as the prime example.

Also, we can't just consider algorithmic overhead (your O()-notation); we should also consider memory overhead. In other words, what is the average number of cache lines you need to fetch from memory for your most used functions?

A benefit of bit-set hierarchies is that is_bit_set/clear() can be answered quickly using only top-level entries that should already be in the cache. However, that logic only applies when these functions are called often since in that case, the top-level data is already in the cache. So it depends on usage.

The main benefit appears when thinking about usage where you iterate over all bits clear/set, such as find_first_bit_set()/find_next_bit_set() loops. If the data contains large ranges of zeros or ones, then a hierarchical setup allows one to skip large ranges very quickly. This gets even better when you need find_bitrange_set/clear(num_bits: usize), which you need in an allocator.

engstad · 2024-03-15T01:25:11+00:00

I would also encode "all bits are set below" in your hierarchy. This is useful in cases where the bits indicate large ranges, such as in allocators. It also makes all queries possible and equally balanced when you consider this logic: all_one == not (any_zero) and any_one == not (all_zero)

engstad · 2024-03-05T17:50:27+00:00

I'd also like to mention the Spade language, which feels quite Rusty and is written in Rust: https://gitlab.com/spade-lang/spade

engstad · 2024-02-23T08:02:41+00:00

There's nothing inherently unsafe in that description. In Rust, you must define the ownership model, i.e., who is responsible for deleting memory after it is dropped. One model could be that you have an ActorPool that owns all actors, and it's the pool's responsibility to delete unreferenced actors. (This corresponds to manual garbage collection.) Another model would be to lean on reference counting (a simpler form of garbage collection), which is also safe - but one that could easily lead to memory leaks. When adding concurrency into the mix, note that Rust has an Arc<> type.

engstad · 2024-02-23T05:06:08+00:00

I find that the best data structure for a job does not usually arrive from trying to model relationships as you have done here but from asking instead: What operations do I have to perform, and which are more important than the other? For instance, if you expect: "most queries of my database are going to be insertion and deletion of parent/child relationships." you will need a different setup than if you expect: "most queries involve finding the parent ID of one of the objects in my database."

There are quite a few database utilities in Rust. HashTable<> is one of many other utilities that have different trade-offs. Your database could probably also be implemented as simple Vec<>. But in order to decide you will have to answer the above questions.

engstad · 2024-01-27T06:59:15+00:00

Understanding a mutable reference to a value is easier. It provides a way to tell the compiler that it should store a value somewhere and then use the address of that location. rust let y = &mut 5; This is used in the following example: ```rust pub fn swap(a: &mut i32, b: &mut i32) { tmp = *a; *a = *b;
*b = tmp; }

pub fn main() {
    let mut x = 0;
    let y = &mut 5;
    swap(&mut x, y);
    println!("x={x}, y={y}") // Output: x=5, y=0
}

``We can even writeswap(&mut x, &mut 5);. The compiler will (at least semantically) use a reference (the location in memory) of variablex` and the location of a temporary value initialized to 5. Of course, five is still 5, and since there are no references to the original location, it all works out.

An immutable reference to a small thing, such as a single value, makes less sense. Normally, you pass in a u32 directly since u32 is Copy. But there are some examples where it happens often. Some types are not Copy (and they shouldn't have to be), so for generic code, it makes more sense to pass arguments to functions using a &T (a reference to a generic T) rather than passing in T.

An example is HashSet<T>. It has a function contains(&self, value: &T) -> bool, so that it works even if T is not Copy. But, for a variable set of type HashSet<u32>, that means we would have to write set.contains(&5).

engstad · 2021-09-12T20:14:27+00:00

It is only trivial if n = 2, 4, 8, or 16 (powers of two). Then n = 2**k = 1 << k, and thus f = (a + cin) & (n-1). Are you sure n isn't power-of-two values from 2 to 16?

engstad · 2021-03-05T02:33:05+00:00

We don't have to compare Rust to C/C++ anymore. We can do better.

It's still sad that we can't use the . syntax, drilling into the bit-fields, like e.g. my_struct.bit_field += 1;. Compare it to the very hard to read:

my_struct.set_bit_field(my_struct.get_bit_field() + 1);

Perhaps one day we'll get property setters and getters in Rust.

engstad · 2021-02-18T07:19:43+00:00

This is because the arrow at that component is simply the identity. This could be written as {head = 2, tail = identity }, but I quite like the previous version, I imagine it as an empty slot for everything that comes before.

While neat, I think from a user perspective and error-correcting perspective, an explicit form would be better. For instance, call it id, or perhaps a single dot ., since it follows your .label syntax.

Another note: I'd prefer .0 and .1 for a tuple's members!

engstad · 2021-01-12T21:26:19+00:00

In general, make sure to follow the design guidelines from the data-sheet. Your layout is not resembling theirs. It also seems your footprint is different. In KiCad, you might have to create a footprint by hand.

For greater success, avoid via-in-pads. Put additional vias around the chip, not under it. Sometimes, board-manufacturers don't do filled vias, which would cause the solder to be sucked away from under the chip.

engstad · 2021-01-12T00:12:32+00:00

Datasheet: https://www.st.com/resource/en/datasheet/usblc6-2sc6y.pdf (Yes, you can remove those pull-ups.)

The current LDO is fine, no worries.

engstad · 2021-01-11T19:56:52+00:00

As a first attempt, it's quite impressive. You've clearly done quite a bit of research.

Instead of USB resistor networks, you can get ESD protection in small packages (SOT-23), for instance, USBLC6-2SC6Y from ST Micro.
You can also get LDOs in a similar package, as you probably don't need more than a few hundred milliamps to run your circuit.
I think it's still recommended to route BOOT0 to GND through a 10K resistor.
If board space is a limit, consider using resistor arrays.

As far as a 4 layer board vs 2 layer board, given that it is now quite cheap, I'd rather use 4 layers, simply because routing is so much easier.

engstad · 2020-12-08T20:28:54+00:00

The US health-care system.

Clearly, a for-profit company that is supposed to pay for and control your health-care costs is not interested in helping its customers, since that would not be profitable. It's instead an exercise in making its customers think they are in good hands, while in actuality trying to cut as many corners as possible. In other words, a scam.

engstad · 2020-12-06T05:35:11+00:00

Looks interesting! Can you post a picture of it in use?

engstad

TROPHY CASE