ikskuh · HackerTrans

ikskuh

no profile record

Submissions

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

343 pointsby ikskuh6 anni fa296 comments

comments

12 mesi fadiscuss

Creator here!

Yes, the OS is highly opinionated, as just making another linux is incredibly boring for me!

The 32-bit only constraint is mainly due to my focus on smaller architectures, especially microcontrollers.

x86_64 and aarch64 both have much more complex initialiastion schemes, and also use much more complex page table setups.

Thus, i wanted to keep that out of the system, considering i'm targeting systems with a tiny fraction of the 4 GiB memory limit.

The co-op multitasking is a part of the OS, and the OS doesn't give you preemptive multitasking. I never said i won't implement sanity safeguards! Just killing off a hanging process that doesnt yield for more than 1-5 secs is totally i scope and increases user friendlyness. but considering the system reboots in 1.2 s on target hw right now, the user will maybe just have hit reset by then :D

12 mesi fadiscuss

Module spec should be around 85x28x100 mm size, so we'd have a deep module with around 15mm of "front extrusion" to fit the modules.

It's definitly possible to re-layout the backplane into a different mechanical design, and reduce the number of slots

Final specs will be shared soon, i have to do another revision of the hardware design as i figured mechanical properties like that the "stickyness" of PCIe slots is good enough so you dont actually need mechanical screws to fasten the modules

12 mesi fadiscuss

Creator here!

You're absolutely right! I wasn't there either, and i wouldnt want a terminal-only machine.

My goal is providing means and knowledge to those that want it. The Ashet is more meant for technical schools, apprenticeship and "the interested", and definitly requires an initial spark that will make that project interesting to you.

It's here to fill a (percieved) gap and wants to sit more in the professional education part than the "get the kids to computing".

I'd love to have had such a hands-on device in school instead of the bare theory of circuit operation and basics of programming.

12 mesi fadiscuss

Lua is planned! It's an interpreted language with a lightweight compiler which is one of the next things on the "large scale" todo list!

12 mesi fadiscuss

Creator here!

Wanna hop onto my crazy train and make a second main board?

I wanna make the Ashet Home Computer an open and free platform, so if you implement the backend control interface, you can use all of the environment yourself.

> I am way worse than OP and have no documentation at all.

I confess guilty at the currenr point. I do have planned a large phase in development where i will create entry-level docs for everything, as these are an essential part of the project.

The video is incredibly cool! Ashet started as a SoC in a ECP5, but the RP2350 basically hit all my spec requirements better than i could've done it myself, which made it a no-brainer to ditch the FPGA

12 mesi fadiscuss

Creator here!

I did consider Euro Rack, 19" racks, MiniATX and other case standards. But with any of these options, i wouldnt be able to keep the price low. The case including all parts and assembly cost is roughly at 20€ per device. It's an off-the-shelf part, with only lasercutted parts in two materials, and a single custom component which is yet to be determined what's the cheapest manufacturing option.

I wanted to keep the price low and any of the options above would increase the price by at least 40€, which is a subatantial part of the components

12 mesi fadiscuss

Creator here!

I'm also having ADHD but you can get help with the focus problem ;)

It's incredible to work for many years on the same thing and it's so pleasing to have steady progress.

So: Go, start building a vision for your cyberdeck! Having a clear goal helps you working towards building it, and you cam embrace the ADHD by jumping around between the many aspects of such a project.

sw design, hw design, visual design, mechanical design, handcrafting, soldering, programming, making websites, asking people, ...

12 mesi fadiscuss

Creator here!

You can subscribe to the E-Mail newsletter linked on the front page (or on Community)

12 mesi fadiscuss

Creator here!

I know, i know! This is what makes me a bit sad. I dont know of any modern compiler i can use on the platform, as most hobby compilers target aarch64 or 32/64 bit x86.

What i need tho is a compiler that targets Arm/Thumb-2.

My research tells me that this confines me to: - A non-complete patch series for TCC (maybe) - LLVM - GCC

As twonof them obviously won't run on 8 MB, my options are stripped down to:

- Evaluate CBE and write my own backend and add 32 bit support - Write my own compiler + backend

Both options don't sound viable before the release as they would increase the scope greatly.

12 mesi fadiscuss

Note taken!

Will add a new "cleaned up" photo that isn't also entangled with kids stuff, and other desk content :D

Sadly, it really looks atrocious and it's currently a 3D build which is hard to photograph.

12 mesi fadiscuss

Creator here.

Please take a look at the gallery, where there are photos of the actual electronics setups!

Also don't the mechanical mockups count as hardware? A pile of jumperwires, breadboards and devices don't make a good hero image, but physical hardware mockups do.

Also the electronics design in its current form is actually iteration 5 of the system, while the OS development started with iteration 2.

The OS does boot on the electrical prototype

12 mesi fadiscuss

Creator here!

That sounds exactly what i had in mind, and i really wanna do the same when my boy is old enough for computers.

It's a teaching tool and a fun toy to tinker with

4 anni fadiscuss

If everything goes according to plan, Zig will be the only language that is capable of actually utilizing the AVR 24 bit address space properly, while also allowing you to make nice optimizations with the smaller 16 bit address spaces (Zig has first class address spaces on memory)

Also, RISC-V support is working quite fine, and i don't see much problems with that.

> But I don't think we need more AVR going forward. It's rather proprietary, no?

AVR is Arduino. It would be a bad action to basically say: "well, zig is not going to support the most widespread maker hardware on the market"

4 anni fadiscuss

Then you definitly should check out MicroZig!

I will push my bugfixes for current master branch tomorrow or later, so you can directly play around!

4 anni fadiscuss

Zig is not perfect on targeting AVR, but it's capable enough to not be a PITA.

Since we've made microzig supporting AVR targets (currently atmega328p only, feel free to add more), i'm not using anything else.

Oh and: We can target an ATtiny1616 without problems. avr-libc doesn't officially support the Tiny2 family yet.

4 anni fadiscuss

This is sadly very badly worded.

Zig provides a global allocator when running tests that will check for memory leaks and double frees. This allocator is only available in the test suite tho, if you want to compile an executable, one has to chose between several allocators and instantiate them explicitly.

There are three allocators that are globally available in the standard library: - `std.heap.c_allocator`, a wrapper around malloc/free. only available when linking libc - `std.heap.page_allocator`, a wrapper around VirtualAlloc/mmap. Can only allocate in OS page size granularity and is quite slow. A good backing for other allocators tho. - `std.testing.failing_allocator`, an allocator that will always yield OutOfMemory.

For the use in an application, there's the std.heap.GeneralPurposeAllocator type that needs to be explicitly instantiated, and it provides a good portion of debugging features right now. High-speed implementations are planned for release modes

4 anni fadiscuss

> Zig is harder to learn than C with more difficult concepts.

I'm using Zig and C for a good amount of time now and i disagree. Zig has simpler concepts as C, but in C you can just ignore them.

Consider

   char buf[4];
   float * f = buf;
   *f = 32;

Seems simple, compiles, and even executes. Everyone is happy. But that code will just explode randomly on non-x86 platforms as it violates alignment rules. In Zig, this code will give you a compile error, as []u8 does have alignment 1, while a []f32 will have alignment 4. This means you have to learn about alignment before accidently writing code that will randomly crash at runtime depending on the stack position of buf.

And Zig has a lot of these things that require implicit knowledge in C as explicit knowledge implemented in the language itself. Same goes for integer casting, shifting more than sizeof() bits, and so on.

It moves the footguns from the code to the user, and so the user has to learn about all of these concepts before writing Zig code. In C, the code will silently compile and misbehave at runtime. This might feel like additional complexity in a lot of places, but the complexity is there in both languages. One just makes it explicit.

But this is obviously not true for all things in Zig. comptime is a whole new feature that wasn't seen in a lot of languages before and afaik not as it is used in Zig, so it's something new to learn even if you already can do perfect C. The same goes for more precise data types (struct vs extern struct) and so on.

One hard footgun in Zig right now is implicit aliasing of parameter types, which sometimes get passed as a reference and sometimes as a value. This is a known footgun is already on the table to be adressed by better semantics and more safety guards

For me, writing Zig feels way less complex than C because a lot of brain load that went into writing correct C was offloaded to the compiler, which is good. But it also increases the friction when writing code as the compiler forces you to think about alignment and such.

5 anni fadiscuss

> One thing to note is that usvg doesn't preserve text at the moment (will be converted into paths automatically) and Quadratic curves.

I mean, that sounds perfect in my ears as TinyVG doesn't has text/font support anyways and you need to perform the conversion at one point or another.

> Probably a day, as long as you know Rust. I can take a look into it if you're interested

That would be rad! I'll try to do that myself as well, but my last experience with Rust is over two years away, so i'd be happy to see a pro doing the work!

5 anni fadiscuss

I wasn't talking about text in that case. Here's a screenshot of that image:

https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...

5 anni fadiscuss

Oh, hi!

> A small nitpick as the resvg author: the repo located here https://github.com/RazrFalcon/resvg

Oh, i didn't see this. Thanks for some more correct and real numbers, i will correct them in the article later!

> I'm not sure why the author linked some random, outdated fork.

because it appears way higher up on the google search if you search for "svg rendering library". Sorry i didn't recognize that it's a fork!

Nice work then! I should check it out for SVG rendering and parsing.

How much work would it be to port over the C# SVG→TinyVG converter to Rust based on resvg? Considering that you already have a well done parser compared to mine...