Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Linux Modules in Ada (2016)

nihamkin.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Writing Linux Modules in Ada (2016)

#61

Post by [deleted] »

sttaft wrote: post #21
ajxs wrote: post #7

Earlier quoted context omitted.

I completely agree. 'Design-by-committee' gets a bad rap, but Ada's designers got a lot of things right when it came to bare-metal programming. The ability to specify the in-memory representation of a type is one of my personal favourites. I don't think Ada's syntax has aged well. I wish it would get a 21st-century overhaul. I don't think that's likely though, but we can all dream. AdaCore do great work, and contribu…

For what it is worth, Ada was not "designed by committee" more than most languages. It was designed by a design team, and in each revision, there was a strong technical leader of the design team, with the whole design team sharing a strong design aesthetic. I doubt you could say even that about many mainstream languages these days.

[deleted]

Re: Writing Linux Modules in Ada (2016)

#62

Post by Jtsummers »

Galanwe wrote: post #57
glacia01 wrote: post #44

Earlier quoted context omitted.

There are a lot of aspects where Ada is better than C. Just a few things that came to mind: General lack of dumb C stuff like switch fallthrough, null terminated strings (Arrays in Ada are passed with fat pointers), undefined behavior, no need for memcpy, no preprocessor bullshit etc. Ada is more like C++ in functionality so it has Generics, Tasks (Threads), Exceptions, Packages, Strong types, Design by contract etc…

I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment... > Ada is better than C > lack of dumb C stuff Back to your comment, strong types and generics look super nice for embedded. Not sure I would like fat pointers, exceptions and threads in my embedded code though.

Tasks in Ada aren't threads, per se, unlike how many people describe them. They can be implemented with threads, but they don't have to be. For embedded and real time systems you likely have a task system suitable for that sort of environment (I'd hope) and Ada compilers targeting such systems will use an appropriate task system.

Re: Writing Linux Modules in Ada (2016)

#63

Post by butterisgood »

docandrew wrote: post #47
butterisgood wrote: post #46

I want to like Ada, but the lack of support for Mac OS on anything Apple Silicon related is a huge reason to skip it and do something else (for me). One thing I still haven't wrapped my head around is how "dynamic" memory allocation and cleanup works in Ada. It doesn't seem as important to mention that early in any documentation anywhere. And, maybe it's the C/C++ programmer in me, but that strikes me as a bit odd. O…

There’s a GNAT release for M1 now. The FSF Ada compiler is based on GCC so it has worked for RISC-V and other ARM CPUs for a little while now as well. Ada’s dynamic memory principles are definitely unique. For heap allocation its based around memory pools, at least in GNAT. For the most part it’s RTTI but you can do manual new/free style too (though discouraged). Ada uses a secondary stack as well for variable-length…

Thanks for this... I'll take a look at how to get started on Mac OS with GNAT.

I went down a bit of a rabbit hole recently looking to see if there was a LLVM way to do this. It looked like it was being worked, but I'm not sure it's the best way to get started with Mac OS and Ada on Apple Silicon.

I'll check out homebrew and macports too... again, just in case!

Thanks again!

Re: Writing Linux Modules in Ada (2016)

#64

Post by OneWingedShark »

butterisgood wrote: post #46

I want to like Ada, but the lack of support for Mac OS on anything Apple Silicon related is a huge reason to skip it and do something else (for me). One thing I still haven't wrapped my head around is how "dynamic" memory allocation and cleanup works in Ada. It doesn't seem as important to mention that early in any documentation anywhere. And, maybe it's the C/C++ programmer in me, but that strikes me as a bit odd. O…

Memory management in Ada is such that you need pointers (and the heap) far, far less than in other languages: the language allows the return of values to objects of unconstrained subtypes to provide the constraints; example:

    Text : Constant String := Read_Chapter( Book );
Additionally, nesting DECLARE blocks and subprograms allows a fairly fine-tuned memory-usage/cleanup using the stack. The above example could, for example, be part of an outer DECLARE block, which has an inner DECLARE, perhaps with "Paragraphs : Constant String_Vector := Get_Paragraphs( Text );" in its declarative region and "For Paragraph of Paragraphs loop" in its body... as soon as the block is exited, the stack is popped, reclaiming the used memory. This, in turn, means that the need for heap allocation is greatly reduced.

Here's an excellent presentation on Ada's memory management: https://archive.fosdem.org/2016/schedule/event/ada_memory/

Re: Writing Linux Modules in Ada (2016)

#65

Post by MarcusE1W »

butterisgood wrote: post #63
docandrew wrote: post #47

Earlier quoted context omitted.

There’s a GNAT release for M1 now. The FSF Ada compiler is based on GCC so it has worked for RISC-V and other ARM CPUs for a little while now as well. Ada’s dynamic memory principles are definitely unique. For heap allocation its based around memory pools, at least in GNAT. For the most part it’s RTTI but you can do manual new/free style too (though discouraged). Ada uses a secondary stack as well for variable-length…

Thanks for this... I'll take a look at how to get started on Mac OS with GNAT. I went down a bit of a rabbit hole recently looking to see if there was a LLVM way to do this. It looked like it was being worked, but I'm not sure it's the best way to get started with Mac OS and Ada on Apple Silicon. I'll check out homebrew and macports too... again, just in case! Thanks again!

Not sure how well it works (I don’t have a Mac), but there is this repository that describes how to compile the whole gcc/gnat ada system in MacOS.

https://github.com/simonjwright/building-gcc-macos-arm-eabi

Bonus point is that you get the compiler for ARM bare metal

Re: Writing Linux Modules in Ada (2016)

#66

Post by touisteur »

another2another wrote: post #56
touisteur wrote: post #18

Earlier quoted context omitted.

Recent work have introduced lifetimes and an ownership model into SPARK (the reduced easier-to-prove Ada subset) https://blog.adacore.com/using-pointers-in-spark and hopefully it'll trickle down soon in Ada. Edit: there's also reference counting and controlled types of course. And the secondary stack makes many uses of heap allocation go away.

That secondary stack is cool! I want it for my C++ programs, particularly std::string which always heap alloc. begin return "Forty Two"; end Get_Answer;

Yes the secondary stack is this thing that make many (most?) heap allocations inexistant in Ada. So when you're talking about memory safety to an Ada dev as if it was the biggest pain, they might look strangely at you.

Yes indeed, heap allocated pointers are a PITA but we don't use so many of them. In 16 years as an kinda embedded dev on multiple MLOC codebases, I can count on my fingers the times I had to reach to pointers (and unchecked_deallocation) and didn't have a safer alternative (usually Controlled scoped pointer types, but also containers, indefinite types, and if really stuck reference-counted things if really you must murky the scope - but I'd flag the last one as 'need to show why you can't just copy the data around' at code review...).

Not saying it's not missing but I wish we spent more energy on automated proof of absence of runtime errors, large-scale whole-system static analysis, and even more stringent runtime or compilation checks. And better tooling/language support around network, threading, and distributed processing, improved test and coverage tools.

Re: Writing Linux Modules in Ada (2016)

#67

Post by docandrew »

butterisgood wrote: post #63
docandrew wrote: post #47

Earlier quoted context omitted.

There’s a GNAT release for M1 now. The FSF Ada compiler is based on GCC so it has worked for RISC-V and other ARM CPUs for a little while now as well. Ada’s dynamic memory principles are definitely unique. For heap allocation its based around memory pools, at least in GNAT. For the most part it’s RTTI but you can do manual new/free style too (though discouraged). Ada uses a secondary stack as well for variable-length…

Thanks for this... I'll take a look at how to get started on Mac OS with GNAT. I went down a bit of a rabbit hole recently looking to see if there was a LLVM way to do this. It looked like it was being worked, but I'm not sure it's the best way to get started with Mac OS and Ada on Apple Silicon. I'll check out homebrew and macports too... again, just in case! Thanks again!

Happy to help! I can also recommend alire (alire.ada.dev), the open source package manager for Ada. It can manage your toolchains for you and makes it very easy to get started and create new projects. It works well on M1s.

Re: Writing Linux Modules in Ada (2016)

#68

Post by glacia01 »

Galanwe wrote: post #57
glacia01 wrote: post #44

Earlier quoted context omitted.

There are a lot of aspects where Ada is better than C. Just a few things that came to mind: General lack of dumb C stuff like switch fallthrough, null terminated strings (Arrays in Ada are passed with fat pointers), undefined behavior, no need for memcpy, no preprocessor bullshit etc. Ada is more like C++ in functionality so it has Generics, Tasks (Threads), Exceptions, Packages, Strong types, Design by contract etc…

I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment... > Ada is better than C > lack of dumb C stuff Back to your comment, strong types and generics look super nice for embedded. Not sure I would like fat pointers, exceptions and threads in my embedded code though.

>I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment...

Sorry about that, English is not my first language so i might sound rude sometimes. I actually dont hate C, but if you used it you know its flaws. I think stuff i mentioned about C is objectively bad, hence why i called them dumb stuff.

>Not sure I would like fat pointers, exceptions and threads in my embedded code though

Fat pointers are just pointer + size of an object. You have to pass array size anyway, so its just convenient. Obviously, if you need to just pass a pointer there are ways to do that.

As for exceptions and threads: As i said, you can disable or modify them just by using Restrictions pragma. Its a language defined thing. For example, Ada 2022 defines two profiles for safety-critical hard real-time computing:

https://en.wikipedia.org/wiki/Ravenscar_profile http://www.ada-auth.org/standards/22rm/html/rm-d-13.html

Re: Writing Linux Modules in Ada (2016)

#69

Post by glacia01 »

Galanwe wrote: post #54
thesuperbigfrog wrote: post #49

Earlier quoted context omitted.

Representation clauses are by far the biggest feature for embedded programming: https://learn.adacore.com/courses/advanced-ada/parts/data_ty... http://www.ada-auth.org/standards/22rm/html/RM-13-1.html Wouldn't it be nice in C to be able to define how a struct is laid out in the machine representation? In Ada, you can and it is part of the standard, so it is portable: https://learn.adacore.com/courses/advanced-ada/par…

It's difficult for someone with 0 knowledge of the language to really understand representation clauses. It does seem to be similar to enum values in C++? // Ada for Day use (Mon => 2#00000001#, Tue => 2#00000010#, Wed => 2#00000100#, Thu => 2#00001000#, Fri => 2#00010000#, Sat => 2#00100000#, Sun => 2#01000000#); // C++ enum Day { Mon = 0b00000001, Tue = 0b00000010, Wed = 0b00000100, Thu = 0b00001000, Fri = 0b000100…

Representation clause is just language defined way of how struct (Record in Ada) Enum or Array are actually laid out in memory. So, for example, you can define a struct that represents a register, overlay that register address and use it like this:

  procedure Enable_USB_Clock is
  begin
     Registers.PMC_Periph.PMC_SCER.USBCLK := 1;
  end Enable_USB_Clock;
Example taken from here: https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev...

Re: Writing Linux Modules in Ada (2016)

#70

Post by Galanwe »

glacia01 wrote: post #68
Galanwe wrote: post #57

Earlier quoted context omitted.

I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment... > Ada is better than C > lack of dumb C stuff Back to your comment, strong types and generics look super nice for embedded. Not sure I would like fat pointers, exceptions and threads in my embedded code though.

>I know berating C is trendy, but it feels a bit gratuitous and uncalled for in your comment... Sorry about that, English is not my first language so i might sound rude sometimes. I actually dont hate C, but if you used it you know its flaws. I think stuff i mentioned about C is objectively bad, hence why i called them dumb stuff. >Not sure I would like fat pointers, exceptions and threads in my embedded code though…

> Sorry about that, English is not my first language so i might sound rude sometimes

No offense taken, not a native here either ;-)

> if you used it you know its flaws

Indeed, I've been using C for almost 20 years now. I won't say it's without flaw for sure, it has its quirks, but overall I do think it's quite okay for the job.

> Fat pointers are just pointer + size of an object

Yeah I know what fat pointers are, I even resort to handcraft some form in C for some neat performance hackery on x64.

But the thing is, we're talking embedded here. Most ucontrollers I use have 8b address space, no MMU or any form of virtual memory, separated instruction/data bus (MVHA). That kind of thing don't play well with funky fat pointers.

Sure if your definition of embedded is "64b ARM" all is good, but I guess we're on a spectrum.

Exceptions are pretty much non existing as well, since that would require some form of runtime, which you often just cannot afford on a small chip (if not just form the sheer size of it).

Threading is a no go as well. To get threads, or any form of multitasking really, you have to rely on an operating system, which by definition is a bit weird to have on an embedded IC.

Post reply on HN