|
I temporarily abandoned SVG processing in favor of TinyVG. I'm not done with it. The specification document for the file format is atrocious so I'm looking at the code.
But the code they provide is in Zig and although that will interface with native C, my embedded toolchains don't support Zig.
So C++ it is. Lots of porting. Zig is Rusty. That is to say, somewhat Rustish, syntactically. I don't care for it. Particularly I don't like the exception handling. Ugh. What is wrong with try catch?
And local functions (functions nested in functions) are annoying. Remind me never to use those in C# either.
I don't get why people would produce a potential standard using a newish language that hasn't really matriculated or cemented itself among developers yet.
Providing a C or even C# reference implementation would get a lot more mileage, IMO, just because more people know it, and what happens if Zig never catches on like happens to so many new languages?
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Many have tried to find a better C then C but C and C++ are so embedded in embedded that it will be almost impossible to unembed them.
Although I kinda like Rust, it's not well enough established yet to make it to production.
ZIG is interesting but I don't think it will take off.
Plus I found years ago that most developers are not willing to learn another language for day-to-day work and with the way that code is currently developed I can't say as I blame them.
If it ain't broke don't fix it.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Zig is neat, but "neat" doesn't deliver.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: Zig is neat, but "neat" doesn't deliver.
and don't buy the groceries, or rent, etc..
I once was in a large shop that used C exclusively and I was asked to rewrite a huge project, I did it in C++ and the manage called in a associate that I was friendly with and she asked him; "Does he know what he's doing?"
The project got completed and worked great.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
C++ has really endeared itself to me over the past few years. Before that I was kind of favoring C#, because for all its power, C++ can be really stodgy and finicky.
That being said, embedded kind of forced me back to it, and using it regularly again has smoothed out the rough edges for me, better than ever before, so I'm proficient and productive with it.
Well, not the STL. I'm so rusty with that, because I don't use it with embedded. Frankly I stick to the C standard libraries mostly, because they're more consistent implementationwise platform to platform on embedded. I'm pretty good with the language features though, and reimplementing basic STL functionality as I need it.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I agree, I also have been using it since doing embedded. I'm starting to use it on the STM32 platform now and really liking it. To me using C is like going back to black and white after seeing color. C++ just has so much more to offer.
I won't say I'm proficient using C++ but am picking it up as I go. Don't have any project to really challenge my skills and so I only use the basics.
I've never used STL so I don't miss it.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
The STM32s w/ CubeMX are alright. You can use them with Zephyr too.
I'm kind of disappointed in the hardware selection offered by STM32. They don't really push the envelope for ARM devices the way NXP does.
The issue with NXP is coding w/ MCUXpresso is like having your teeth pulled.
But 1GHz ARM Cortex M (not a typo) in the NXP MIMIXRT1170 that can take various types of external "flash" including - get this - m.2 storage, plus external RAM including DDR3 is an absolute beast. It has a second 400MHz lower power Cortex M core as well. It is, as far as I know, the only realtime MCU that can run Linux.
Really amazing kit. I have a $200 devkit w/ it but MCUXpresso has kept me from doing more with it.
There's scuttlebutt on the PJRC forums that the next Teensy will use this chip. If so, they will support Arduino. What a world.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
To me, Zig is to C as Rust is to C++.
The thing with Zig's exception handling is that it doesn't really have exception handling. IMO Zig having try and catch keywords just makes things confusing. I like the idea behind what they do in Zig. They give you a nice way to do Golang-style error handling without needing to write if err != nil everywhere. But calling them try and catch can add confusion given what those keywords do in other languages. Having said said, I find Zig's try, catch, defer, and errdefer are a decent but not perfect way to deal with errors.
As for what's wrong with traditional try-catch exceptions, I imagine Zig's creator would argue they violate the language's "No hidden control flow" principle. Kind of the same argument Joel Spolsky made here 20ish years ago. As a member of the Golang dev team put it: "The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about."
It's really a matter opinion, of course. It's fine to prefer traditional exceptions, too.
As for why use Zig instead of something else: I suspect that's personal to the developer. Maybe they liked the simplicity and flexibility of C, but wanted more sophisticated metaprogramming and fewer footguns. It might be that Zig gave them the little bit of extra joy that was the difference between creating and not creating the project.
I've been there. Sometimes when you're feeling a bit burned out and jaded, trying a new language brings back that little spark of joy that reminds you of why you started programming in the first place, and inspires you to take on an ambitious project you might not have been otherwise been able to muster the energy for.
|
|
|
|
|
I get it. While I still don't understand the exception handling flow vs. syntax (i've only gleaned what I have about the language from reading actual code, not the manual) I'll defer to your position that it's more elegant that C style error bubbling via return values.
I don't like the syntax of zig. "fn", types trailing the name, etc. it's like all the things i didn't like about pascal anew.
But my major sticking point here is the reference implementation provided with the TinyVG package. It should not be in Zig, even if the original proof of concept was written in Zig. It needs to be ported to a more traditional language. I'd recommend C.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
and ran across this one; Mouse Pad[^]
Suitable for when I run into coding problems. 
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
They could do a little better with the framing.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
|
I'm honored.
Would this [^] be our theme song.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
Sho nuff! 
Jeremy Falcon
|
|
|
|
|
Raccoon city cult? 
Just in case... resident evil joke
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: resident evil joke
I was about to say... I don't get it.
Had a buddy back in the day who played Resident Evil (talking like PS1 days), but I never played it. Sim City on the other hand...
Jeremy Falcon
|
|
|
|
|
Film serie (Mila Jovovic) or Animation Films (at least 5) and a Netflix Serie or 2 are out there too
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
My Mice have a pad in the garage
I know because they keep stepping on the Mouse Trap
I guess they like Peanut Butter Crunchy style
10 this summer I need a Cat NOT sorry HoneyWitch
|
|
|
|
|
I'll make some statements I believe to be true and then you can respond to each statement with true/false & reasoning.
On Windows x64 (and maybe Linux too) a (normal) process
1. gets an address space which is 4GB in size when the process starts
2. OS modules take up certain portion of that address space (1GB?)
3. The rest (3GB) is used for the stack & heap of the running process
4. As the app instantiates new objects (allocates memory for objects) on the heap, the amount of memory the process uses grows -- but it can never grow beyond the 3GB (4GB total) anyways, right?
5 ## This is a biggie ## A process can never eat up more memory than its address space allows 3GB (4GB total) so a process can never really impact another process anyways because each one is limited to 4GB anyways, right?
6. Extreme Example - If there is 128GB RAM in the hardware and we say OS (associated services) take up 28GB (to make things easy) and there are two services running (2 X 4GB = 8GB) then this machine could never run out of memory, since it would have 92GB just sitting idle
7 Driving A Point Home - So when a developer notices that the app he wrote running on the Server keeps crashing with "out of memory" error, then looks around and says, "Hey, wait a second, I think your service (which has been running on the Server long before aforementioned dev's app) is eating up memory and making mine die", then that developer doesn't understand process address space, right? Right? Right! 
This is also why
A. you can solve memory problems created by lots of processes running, by installing more memory (if hardware is further expandable)
B. You cannot solve memory problems of a service or app that crashes due to low memory (since it is simply eating it's own memory) by installing more memory (even if hardware is furhter expandable).
Agree? Agree some? Disagree? Disagree entirely?
modified yesterday.
|
|
|
|
|
The 4GB limit is a Windows 32 limit, and the default in Win32 is 4 GB with 2 GB being granted the OS, effectively limiting the application to 2 GB. There is an option to make this 1 & 3 GB but I don't remember how to do this. Exchange Server and SQL Server versions designed to run on 32 bit Windows server used this option.
For Windows 64, the limits are listed at Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn. Note that 32-bit applications are still limited to 4GB simply because 2^32 is 4GB. 64 bit application limits vary by OS version, generally growing with each new version of Windows.
|
|
|
|
|
Yes, that makes sense. I'm stuck in a Win32 mindset. 
That's all very good info. I appreciate you reading and replying.
Thanks for your time. 
|
|
|
|
|
Once upon a time Windows and x86 hardware memory management were more closely related; the hardware could be much more fully exploited. But Microsoft hoped Windows to be The OS for all different sorts of processors, so it was ported to Alpha, MIPS, PowerPC, Itanium, and I believe there were beta releases for other CPUs as well that never made it to the market. MS didn't want to build their memory management on mechanisms available on x86 only, so instead of exploiting the x86 MMS to its fullest extent, they switched to a single, flat memory space which is managed by software in several areas where x86 hardware could have been employed.
x86 hardware allows a process to have a number of segments with different properties, mapped dynamically into the address space. A DLL would be a typical case of a code segment. The contents of a database could be data segment, like a memory mapped file. The sum of the data segment sizes used simultaneously by a process must fit into the 32 bit address space (without overlapping), but in principle, a process can replace one segment (code or data) with another one at runtime, if it really requires more that 4 GB of either code or data. All of it can reside in RAM; only segment descriptors are updated. Code and data are separate address spaces. Stack is a third address space. So in principle, a process could address 4+4+4 GB of memory (but the chips of the days didn't have enough address pins to allow addressing of 12 GB physical RAM).
The 386 came with a mechanism for making calls to the OS that switched to the segments of the OS. So the OS also had, in principle, a 4+4+4 GB address space, which was like in a different dimension from the user space. There was no way that the user could address OS space, whether intentionally or unintentionally. The problem is that switching between user an OS mode (with a 4-ring graded protection, in addition to privileged/unprivileged instructions) that it took far too much time. MS refused to use the mechanism.
Raymond Chen tells in one of his blog posts that in an MS/Intel meeting, the Intel guys asked what would be MS' highest priority for performance improvement, if only a single thing could be improved. The Intel guys though the MS answer was a joke: Faster handling of the illegal instruction interrupt. It was dead serious: Developers had identified it as the fastest way to enter privileged mode, so they used it as the basic mechanism for performing calls to the OS. They also put OS code/data and user code/data into a single address space, so that no update of segment or page tables is required. All three segments - a single segment for code, data, stack - was put on top of each other, offering new and exciting possibilities for data and stack to be interpreted as code, to make a jump into a data structure and other fascinating adventures , and also half of the address space left for the OS. 2 GB should be enough for everybody. (There was an option for doing a 1+3 split, and 3 GB should most definitely be enough!)
Certainly: Today, you can map files into you address space, and DLLs are more common than ever. It is not based on the segment hardware of x86, but using the same software mechanism on all CPU architectures regardless of hardware support available. Sometimes, such as with the system call mechanism, abandoning the hardware mechanism can actually be faster, yet I have somewhat mixed feelings: Shouldn't they put some more effort into improving the hardware, rather than abandoning e.g. protection of OS code by being isolated in a different address space, when the hardware was designed for it. Maybe MS was too quick in switching to a single, flat, shared address space. (Or maybe it has to do with employing chief designers with a background from architectures that had nothing comparable to offer.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Are you the developer with the app that is dying or the app that is consuming memory like Lays/Walkers?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
I'm the one with the app that has been running on server for a long time (many years).
No out of memory errors.
Other comes along and has out of memory errors then thinks it's someone else.
Kind of annoying. I'm mostly just curious, because my main point is that "you can't really entirely effect another process (this would be almost like a malicious process which could cause another app to fault)" because your app is stuck in it's own address space.
Now if the server has 4GB memory then yes maybe my app taking memory could cause you issue since neither of us really has the correct amount of space.
|
|
|
|
|
raddevus wrote: gets an address space which is 4GB in size when the process starts
I'm not sure about the actual limit, but I don't think it's a low cap like that per process... maybe per thread. I dunno. Gonna have to check out obermd's link myself.
raddevus wrote: OS modules take up certain portion of that address space (1GB?)
Not from an application's perspective. That died out in the Win31 days. These days just about every OS uses a ring architecture, where 0 is the highest access and is usually only accessed by the kernel. Applications have the least amount of access into something called protected memory, which virtually maps addresses to make your app think it can access whatever, but it can't.
You'll never accidently overwrite the OS' memory these days, but you can have a memory leak and take the system down that way.
raddevus wrote: The rest (3GB) is used for the stack & heap of the running process
For an application, there are 3 areas of memory: static, stack, and heap. Stack and heap get all the attention, but static is just as important. Static memory is used for things like literals that is embedded in the application itself. For instance:
const char *howdy (void) {
return "Howdy";
}
int main()
{
printf("%s\n", howdy());
return 0;
}
This is perfectly valid C code. The string "howdy" can be found in a hex editor and stored in the executable itself. Unlike stack memory it's not going to get wiped out so easy, which means you can return a pointer to it directly in a function. You copy that literal over to a local variable on the stack though and return the variable, well things will start breaking if you did that.
raddevus wrote: As the app instantiates new objects (allocates memory for objects) on the heap, the amount of memory the process uses grows -- but it can never grow beyond the 3GB (4GB total) anyways, right?
Depends. The whole idea behind swap (*nix) or page files (Windows) is to get around that. The OS would extend the memory be moving things in and out of disk. Slow as dirt and not used these days nearly as much. But, if swap/paging is disabled then yes.
raddevus wrote: 5 ## This is a biggie ## A process can never eat up more memory than its address space allows 3GB (4GB total) so a process can never really impact another process anyways because each one is limited to 4GB anyways, right?
Correct, in a protected memory model. So, stay away from Win31. I don't think the exact limit is 3GB again, but an app can only screw up its own memory. However, if it does have a memory leak it could make it impossible for other apps to allocate memory and you get a crash that way. But, their memory won't be corrupted unless there's a bug in the other app somewhere.
raddevus wrote: 6. Extreme Example - If there is 128GB RAM in the hardware and we say OS (associated services) take up 28GB (to make things easy) and there are two services running (2 X 4GB = 8GB) then this machine could never run out of memory, since it would have 92GB just sitting idle
Assuming there's no memory leaks/bugs, yeah.
raddevus wrote: Driving A Point Home - So when a developer notices that the app he wrote running on the Server keeps crashing with "out of memory" error, then looks around and says, "Hey, wait a second, I think your service (which has been running on the Server long before aforementioned dev's app) is eating up memory and making mine die", then that developer is an idiot who doesn't understand process address space, right? Right? Right!
It depends. Could be, your app. Could be another app. You don't have to guess though. Every OS on the planet will tell you which processes are using the most memory. If it's Linux use top or install htop and find out. You can also write a script to monitor them.
raddevus wrote: You cannot solve memory problems of a service or app that crashes due to low memory (since it is simply eating it's own memory) by installing more memory (even if hardware is furhter expandable).
Depends on the nature of the bug in the service.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
