HN user
https://github.com/rswier
I suspect there is some clever base between 1 and 2 which is trivial to compute
Something like this perhaps (although this might be too much granularity):
(8 + (cap & 7)) << ((cap >> 3) + 1)
16 18 20 ... 30
32 36 40 ... 60
64 72 80 ... 120
128 ... etc.Are there any good resources for learning how to render dichroic thin films with multiple internal reflections and refraction indexes? Basically, I would love to render something like this[1] in real time.
The March 1931 issue of Television News[1] is a fantastic snapshot in time of the development of Television.
Amazing all those various silly spinning disk systems peppered throughout the magazine...and then buried on page 48 there's Philo T. Farnsworth[2] and his "scanning electric pencil"! Huzzah!
[1] https://worldradiohistory.com/Archive-Television-News/Televi...
Here are the course notes from an AT&T Compiler Construction Course by "Aho, Sethi, et. al."
https://archive.org/details/CompilerConstructionCourse_Dec83
Tiger Innovations | Herndon, VA | Spacecraft Embedded Software, VHDL | Full-time | Onsite
Tiger Innovations is a small high technology company specializing in developing spacecraft and space-related systems for a broad range of US Government customers. We have an immediate need for real-time embedded Software Engineers and Computer Engineers. Created by and for engineers, Tiger Innovations values talent and curiosity over resume buzzword bingo.
If you are interested in working on challenging technical problems in a multi-disciplinary environment (i.e. cool stuff) then take a look at our ad and apply at:
I made a branch of c4 that includes struct support. I should probably add it to the master branch so it gets more visibility: https://github.com/rswier/c4/blob/switch-and-structs/c4.c
c4.c author here - selfie seems to fill a niche between c4 and my other more full featured compiler/os swieros. Very cool!
More details on "Primeval" C can be found here: https://www.bell-labs.com/usr/dmr/www/primevalC.html
Just recently, fragments of the earliest Unix OS source code and B interpreter were discovered [0]. Now, the earliest Unix for the PDP-7 and PDP-11 [1] can run under emulation thanks to the incredible efforts of Warren Toomey and others at the Unix Heritage Society [2].
[0] https://github.com/DoctorWkt/pdp7-unix
The code appears to be some of the most ancient Unix Kernel Source Code yet found. This is previous to the PDP-11 1st Edition. Still, many of the familiar bits are there (ed, cat, etc..) A pretty historically significant chunk of code!
Warren Toomey from The Unix Heritage Society (TUHS) posts:
http://minnie.tuhs.org/pipermail/tuhs/2016-February/006622.h...
With the link:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc...
From the Readme:
The structure of the kernel source code is very similar to that of the 1st Edition Unix scan at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf
Here is what I can glean from the files:
01-s1.pdf contains the kernel source divided into sections S1 to S9
02-hw.pdf has hardware details of the PDP-7
03-scope.pdf has information about the PDP-7 scope
04-cas.pdf seems to be a user-mode program that uses the PDP-7 scope
05-1-4.pdf user-mode programs: adm, ald, apr, as
06-5-12.pdf user-mode programs: bl, bc, bi, cat, check, chown, chmod, cp, chrm
07-13-19.pdf user-mode programs: db, dmabs, ds, dsksav, dskres, dskio, dsw, init
08-rest.pdf user-mode programs: ed. Also at the beginning some B code (?)Once again the internet has demonstrated it's ability to (semi-)autonomously heal damage and mis-configuration by replicating data from the faulty nodes. I trust the keepers of this valuable data will occasionally admire and validate these backups, replicate sparingly, and never profit except to enrich their knowledge. Guilty twinges may be eased by giving back to the nearest struggling technical book store in your area :)
Searched for "Compiler" and was not disappointed.
Tim Budd's "An APL Compiler" is a classic.
I love the goofy title of Mads Tofte's: "Compiler Generators What They Can Do, What They Might Do, and What They Will Probably Never Do"
Paid a handsome amount for these and many others at Reiter's Books back in the day!
In the future I believe you are going to see less emphasis on the aggressive speedup of C code for traditional CPUs. Instead you will see many more gadgets with simpler processors that run C code slower in the effort to save power. GPGPUs and algorithm specific hardware (e.g. video, crypto, network, DSP, neural nets) will fill out the rest of the chip. At some point GPUs will have enough raw power and GP features for it to be possible to run an instance of a late-80's operating system within the working set of a single GPU processing element (perhaps with virtual memory emulated as in jslinux.) At that point the need for a power hungry CPU and artificial CPU/GPU distinction will start to fade away completely. Along with Peak Oil we will have Peak CPU.
So, in general I am saying that the road to better performance will not be in aggressive compiler optimization, but rather in higher level design tools to manage totally new software/hardware abstractions. Binaries will be specified at a higher level and look more like source code. At this point my crystal ball becomes admittedly a bit fuzzy.
RISC created a huge local minimum by speeding up C code to the exclusion of other languages. I predict that eventually future processors will hide more features from the higher software levels (such as number of registers, instruction types and formats) in order to improve efficiency at the machine level. I think we are seeing this trend with GPUs already. Current CPUs don't do this because they have to maintain binary compatibility with a huge installed base. We can compare notes in a decade or so :-)
Completely agree :) But even better to push C code straight down to the hardware and let it crunch on that! Let it allocate a few thousand registers, or spawn off an FPGA compiler to create a few new instructions. Crazy?
Maybe we are all better served by faster compilers that create straightforward binaries (and less bugs overall both in the compiler and application code.) Optimization researchers could focus on source-to-source transformation tools with intelligent human-in-the-loop guidance. Or else they can work at the hardware/JIT level if they prefer.
Right now compiler writers are playing in a kind of local minimum (premature optimization as I said.) This may produce 3x-5x faster binary code today but also forces CPU manufacturers to retain backward compatibility causing them to also stay stuck in this local well. Eventually a new architecture is created (with 10x the registers etc.) and the cycle continues.
I agree optimization is important. So important that it should be pushed down into the hardware. Binaries should look almost like source code. But that's just my vision for what it's worth.
IMHO aggressive optimization at compile time is an example of premature optimization. Let the hardware have access to a straightforward representation. Once the run-time hot-spots are identified, the hardware (firmware, VM, whatever) can rewrite the binary code to execute faster. Excessive compiler optimization makes this difficult or impossible (too much information thrown away.) Compilers should be designed for fast compilation speed.
Many years ago I played around with something called PRECC - A PREttier Compiler Compiler. I remember it was(is) pretty elegant. I wonder if anyone else has experience using it.
http://preccx.sourceforge.net/
This was long before I discovered the simple joys of squeezing out unnecessary CPU cycles from my own hand-rolled self-directed lexer/parsers.
I am reminded of H. R. Giger's designs for the movie Alien. They don't seem so far-fetched now.
What I find incoherent is the OP's implication that saving a historic icon means neglecting the sick and starving. I suppose the Eiffel tower should also be left to rust away.
It is frustrating that this beautiful ship is relatively unknown considering the fascination with all things Titanic. http://www.ssusc.org/ Surely Bill Gates or Jeff Bezos could free up a few million from petty cash.
Yea, even if you increase the chunk size and omit dynamic recompilation, there still may be unavoidable slowdowns due to shoving all that Javascript through the browser.
I am currently designing a software-only CPU with sliding register window (128 entries) and dirt simple instruction set. The for/switch/loop emulator for it should be quite a bit faster than any emulated silicon CPU.
A good approach might be to add a coprocessor to jor1k that validates and accepts page sized chunks of asm.js code for execution in a restricted manner. Validation would check that memory accesses go through a software MMU, all loops can escape on timeout or other events, etc. Emscripten would need modification to emit collections of restricted code blocks that make up an executable. The kernel and userspace would be incrementally ported until the regular emulator is wholly unnecessary.
No malloc/free necessary. Just pile up nodes on a stack, then "deallocate" to any saved position.
The last time I checked, tcc lacked even a simple AST. This led to some pretty weird emitted code (such as swapping parameters on the stack.) Implementing an AST is not hard, just push and pop nodes on a stack. It also makes a nice front-end/back-end interface.
archive.org has a website grab from 2013: https://archive.org/details/dmr-grab