I've been working with FPGAs for 4 years and shortly on ASICs before that, did software in a previous life (and still do), do you have something specific in mind?
No, I personally don't. I was into reconfigurable computing for a while, sort of where I think intel is going with their combined CPU/FPGA project. Just In Time logic configuration.
But I figured I would throw my offer out in case there were people thinking they could solve or enhance something with an FPGA, but didn't have the experience to get started.
Looking forward to where this goes... For work I had to implement arp, icmp, udp and our protocol on top of udp, for 10G ethernet, in an fpga, it would have been fun to add dhcp and tcp but the time and priority weren't there.
My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)
...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;)
Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.
Didn't know they started out with Wirth's compiler. Picked the best one. Then market rejected it. Then pivoted to a more successful approach supporting whatever crud was popular. The recurring pattern. Also didn't know they supported that many platforms. Impressive.
So, my after-work project these days is a language that transpiles to C++ and can do all that current C++ can do.
The grammar is completely regular, and the syntax maps 1:1 with the ast in memory, I can generate one from the other idempotently.
The main reason I am doing this is that I wanted a language that is easy to build tooling for (including of course code transformations) while being compatible with existing C++ libraries out there.
This kind of articles give me hope there might actually be demand for my crazy thing once it grows up.
I read that paper a long time ago and it was certainly an inspiration :)
Originally, the language started out quite different but I can now see why SPECS looks the way it does, I do not agree with everything they did and my effort these days is towards making it simpler and smaller but there's some convergent evolution indeed.
So basically a CoffeeScript for C++? That sounds like a pretty good idea in fact. But doesn't "compatible with C++ libraries" imply compatible with .h files, and thus with the preprocessor?
Dealing with the preprocessor is a lost cause, so I just don't, the idea at the moment is to let the preprocessor do its thing and pipe the output into ctags (and if a better ctags comes out in the future it will be trivial to put that in instead), the result is not 100% perfect but is good enough to capture most of the declarations present in the included headers and make them visible to this language.
If a library absolutely requires preprocessor macros to be useable, someone will have to make equivalent hygienic macros in this language but at least you won't have to make a huge wrapper for everything.
Incidentally, this is exactly what I am working on, grammar and parser are mostly done (the grammar is _regular_ and programs can rewrite themselves starting from their AST, because I really want something like `go fmt` one day), doing the transpiler at the moment, it's... interesting to say the least.
(it will be foss of course but nothing is published yet)
It is indeed expensive but salaries can change wildly depending on your position.
I think I could afford to go out and eat out but I decided not to. This way I save money to bootstrap my own thing afterwards and I can find some free time to teach myself the skills I will need to do so.
The procedure to start a venture depends on the canton, expect to put in at least 10k to start, plus whatever the notarial fees will be. I do not think I will be incorporating here.
I wrote mine, but I track tasks and milestones rather than time spent.
Time tracking makes sense for freelancers and other people who bill by the hour but personally I tried rescuetime & co. and I do not see the point in knowing how long I was on facebook or how long I spent editing a particular file.
Milestones require manual input but I find that information much more relevant.
This is EXACTLY what I needed right now for a project.
Does it already have a module to do the equivalent of an lspci? If not, where would I have to look to learn how to implement such a feature?
Note that PCI enumeration is a bit of an arcane art; if you want to know how to do it in practice on real systems with all their quirkiness, I'd suggest looking at how the Linux kernel enumerates PCI devices. (lspci in Linux userspace just walks the kernel-enumerated devices.) In particular, BITS doesn't have code to handle PCI-to-PCI bridges and enumerate the other side of them, or handle any quirks that crop up in real systems.
We have a very tiny Python pci module, which contains a brute-force bus-walk to find devices with a specific class; we're using that to find PCI-attached USB host controllers so that we can force them to "hand off" to the OS, which then causes the BIOS to stop polling them, which often causes the BIOS to stop doing frequent SMIs. (That allows us to tell if a BIOS's out-of-spec use of long-running SMI handlers is caused by USB handling.)
Simple PCI enumeration, though, is effectively just "walk every possible device, read the first four bytes of configuration space from function 0, if they're not 0xffffffff then they're vendor and product IDs, and then read the same from functions 1-7".
