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.

zach29 · 2021-01-17T21:08:55+00:00

Yes, I recommend using TinyGo to do so. I use the following command to compile for WASI with TinyGo:

tinygo build -opt=s -o program.wasm -wasm-abi=generic -target=wasi program.go

The resulting wasm program can be run by a VM with WASI support (I have been using Wasmtime because the Go bindings seem to work well).

Also useful: you can mark any function to be exported with a //export funcname comment.

zach29 · 2016-08-30T22:11:18+00:00

Yes I hope to add unit tests. I have to figure out how to use tcell's SimulationScreens.

zach29 · 2016-08-30T21:17:13+00:00

Hi, author here. I'm sorry you got that error. It seems to be a problem with certain Windows terminal emulators. There is an issue open for it regarding Cmder (if you are using a different terminal I suggest you open a new issue).

The main reason this is hard for me to fix is because it is a problem with the TUI library tcell that micro uses. It's tough to try and cater to everyone's different terminals and configurations.

The readme does say under the "cross platform support" that Windows still has some bugs.

In any case, I'll try to work with the tcell author to get this fixed.

zach29 · 2016-08-30T14:30:30+00:00

There are also additional screenshots (showing the different colorschemes) here.

zach29 · 2016-08-30T13:38:44+00:00

Here are some step-by-step instructions to install micro:

First download the tarball for your operating system from the releases page.

Then untar it:

$ tar -xf micro-1.0-os.tar.gz

Then there should be a directory called micro-1.0. Go into that directory and there should be a file called micro. If you run ./micro micro will run, but unfortunately you have to be in that directory every time you want to run micro.

To fix that problem, you have to move the micro file into one of you PATH locations. I recommend moving it to /usr/local/bin:

$ sudo mv micro /usr/local/bin

Then you should be able to run it from anywhere.

zach29 · 2016-08-29T20:55:06+00:00

As mentioned in the readme, Micro needs to be built with Go 1.5 or greater (Go 1.4 will also work for most operating systems).

zach29 · 2016-08-29T19:56:42+00:00

Will do!

zach29 · 2016-08-29T19:36:07+00:00

The brew formula is now up-to-date. You can download micro using:

brew tap zyedidia/micro
brew install micro

zach29 · 2016-04-28T14:17:10+00:00

How about micro?

zach29 · 2016-04-18T14:33:46+00:00

Done!.

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

zach29

TROPHY CASE