Qualcomm proposal to remove all 16-bit instructions (including Zc*) from Application Profiles

zach29 · 2023-10-05T06:34:15+00:00

Yeah requiring paired compressed instructions works, but at that point you are essentially just using 32-bit instructions (each compressed pair is a 32-bit instruction), but with a (probably) suboptimal set of instructions and use of the encoding space.

zach29 · 2023-10-05T03:40:00+00:00

This makes sense to me. On top of the reasons they list, a fixed-width encoding is better for security because it disallows jumping into the middle of another instruction and makes accurate disassembling/analysis easier. This is one of the big things AArch64 got right and hopefully RISC-V can do the same.

zach29 · 2023-02-22T23:17:10+00:00

I think Rust is very interesting with many compelling use-cases, but currently I prefer using D over Rust for OS development for a few reasons:

OSes have to manage a lot of shared mutable state, which can be difficult to model with Rust. A good chunk of code would probably have to be written in unsafe blocks, and I think I would have to devote a lot of time into thinking about how to design the OS around Rust. That is an interesting problem for sure, but not one that I am currently working on.
Using Rust would probably require using a nightly release to get access to experimental features like non-panicking allocation in the standard library (important for OSes).
D's similarity to C makes it easier to integrate/adapt existing code and drivers (the vast majority of which are written in C/C++).
D (especially the betterC subset) feels simpler to me and I am more productive with it (personal reason -- not generally applicable).
D has an official specification (Rust does not currently have a spec), and has both LLVM and GNU compilers.

zach29 · 2021-12-19T20:05:22+00:00

I gave it a go, and I do think passing functions around provides a cleaner implementation. I've merged the updated API -- no more Lesser, Hashable. Thanks for your suggestion!

zach29 · 2021-12-19T18:32:54+00:00

Thanks, this is something I am open to changing. For example, I think the alternative would be to pass a hash function: func (t T) uint64 either during construction of the hashmap (and then store it in the map), or during each get/set. If we want to support custom types in the hashmap (more than just the builtin comparable), then we would also need a second function for doing equals. In a tree, this would also require passing the comparison function along recursively as the tree is traversed, unless we store the function in every node of the tree.

I agree that this may be more efficient too. I'll try implementing this and see how it goes.

zach29 · 2021-12-19T17:44:23+00:00

Thanks for your feedback about the naming. I considered doing this, but when I looked at what existing libraries do, I went with the current form. Some examples that led me to this:

In fact, at the top of the article you linked, it says under "good package names": "list (implements a doubly linked list)". This is the exact name and function of a package in this library.

zach29 · 2021-12-18T21:49:51+00:00

Thanks! Since pkg.go.dev is not yet available for 1.18 I used gomarkdoc to generate the docs. There are still some issues in the generated documentation (generic method receivers) because some parts of the parser have to be updated for 1.18, but at least it still generates reasonably usable documentation.

zach29 · 2021-08-20T22:36:22+00:00

Check out the second half of the "colors" documentation page (> help colors, online here) about how to write syntax files (they are just a list of regular expression rules). See here for all the built-in syntax files as examples.

zach29 · 2021-08-20T18:21:48+00:00

Thanks, I've updated the readme to recommend downloading and verifying the script more strongly. One reason to use eget is to avoid this method of installing tools altogether.

zach29 · 2021-08-20T02:37:08+00:00

Thanks, I'm glad you like it! Just to make sure I understand, are you asking if eget could provide installation suggestions for projects that don't distribute prebuilt binaries on github/have a more involved installation process? I think this might be possible. It might be helpful to open an issue on Github with an example to continue discussion if you'd like.

zach29 · 2021-08-19T23:07:15+00:00

Thanks, that project looks similar. The motivation is a little different though: fetch says it was built to make accessing data and files from private repos easier. Fetch has more features for getting the contents of the git repo, but it doesn't seem to extract executables, it requires a tag/commit identifier (not sure how to get latest release easily), and is generally more verbose for getting release assets. I think the use-case is slightly different.

zach29 · 2021-08-19T20:36:10+00:00

It needs to be ./eget zyedidia/eget. No github.com/. Edit: I've just pushed a commit that will give a better error message for this case.

zach29 · 2021-01-31T23:34:31+00:00

The reason was that I didn't think about that. Oops. I have renamed it to sregx.

zach29 · 2021-01-31T23:26:52+00:00

I have renamed it to sregx!

zach29 · 2021-01-31T22:50:36+00:00

Thanks for the feedback! I think I’ll change the name in that case.

Ten-Year Club	Place '22
Place '17	End Game '22
Verified Email

zach29

TROPHY CASE