▲ 51 points
back
8 comments
My professor for Compilers 101 in grad school tasked us with working on an Ada subset compiler. I work best alone, but he insisted on making me work on a team. My experience with "teams" in college was a couple of us doing the work, and others claiming, "We worked on the organizational aspects and wrote some tests, so we didn't have much time for meetings or coding." Anyway, punster that I am, I told the prof that our team was the "NOOPs" (we spelled it differently back then).
So my group's project was writing the VM in C, and only two of us contributed as predicted. Our VM passed the prof's test suite (actually written by our adversary, "Team Lambda", IIRC). So I have a "It all started with a NOOP" story too.
This prof really was a genius himself and an expert in his field. He introduced many of us to the wisdom of Knuth. Our professor once recounted a story about having written an earnest letter to Knuth asking, "I know you are busy, but do you have time to do a lecture on compilers for my class?" He received back in the mail the original letter and envelope, enclosed in another with the "I know you are busy" underlined. My puns are kind of dumb, so I'm not sure he ever understood what I meant. He did ask us what our individual contributions were, and proof there of. My teammate followed me to State U.'s security headquarters begging for some of my test cases.
Have a nice day everyone!
I had similar experiences with every group project, where one or two people have to do all the work. I asked a teacher about it once, and his explanation is that it's a lesson for working in the real world. Really drives home the saying "those who can't do, teach". I think it would have been more moral to do what your teacher did and actually validate contribution, instead of intentionally teaching students that you can screw around at someone else's expense and get away with it.
Back in college, for 90% of the "team projects", I just assumed that I had to do all the work solo, and nobody else would contribute.
One of my friend had a 3-person team, and one of the teammate kept procrastinating, and one day before the deadline, decided that he would just take a "fail", leaving the other two teammates completely in despair. It was a hardware-related project and without 1/3 of the work, nothing could be bought together at all. And the professor didn't give a shit; they had to beg to get a 60/100, despite having done their work perfectly.
The big difference between group projects and real life work, is that the professors don't really have a stake in whether the work is being completed. In real jobs, the boss would really care about it if one of the colleagues just refuse to work and cause the whole product to fail to launch.
The Vivante family of 3D GPUs are available as IP cores, developed by the same named company[1].
Vivante GPUs are used in some ARM SoCs like the NXP i.MX6 and i.MX8.
Etnaviv is the name of the reverse engineered FLOSS Mesa driver. It's support for OpenGL/ES features is sadly lagging quite a bit behind[2].
This article discusses shader compilation and ISA documentation in the Mesa driver using auto-generated code from a high-level, formal specification of the instruction set (in XML), rather than a tons of hand-written C code. A merge request for auto-generated ISA documentation is currently pending [3].
[1] https://en.wikipedia.org/wiki/Vivante_Corporation
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23...
Vivante GPUs are the only godawful thing about i.MX. I hate having to get NXP's BSPs to use the official, higher-performance driver. On i.MX6 the supported kernel was released over a decade ago, which makes it tough to upgrade glibc.
Sometimes I miss not having to do graphics in embedded systems.
At a previous employer we generated assemblers and disassemblers for various DSP cores based on an Excel spreadsheet that the software tools team shared with the processor architects. The spreadsheet cells described the layout of the various instruction fields; this was converted with a script to an architecture description DSL, from which the assembler, disassembler, and other tools could be generated. Another DSL described the pipeline stalls and hazards, and code generated from the combined descriptions drove instruction schedulers and code checkers.
Alastair Reid has also done quite a bit with formal verification and specification of the ARM instruction set:
See https://alastairreid.github.io/using-asli/ and cross-references there in
How does isaspec affect the effort to get better OpenGL/ES support?
I'd like to use FF webrender on a device that uses the GC7000Lite. Without webrender a lot of the web just takes too long on layout.