5 ms·
I once had - a super-fast assembler - a super-fast way to get the assembled code over to a target system ... and my turnaround time was on the order of five
by kabdib 10y ago
I once had
- a super-fast assembler
- a super-fast way to get the assembled code over to a target system
... and my turnaround time was on the order of five seconds: Edit, hit a button making the target ready to receive the code, assemble: Running.
It almost didn't matter that I was writing 6502 assembly; things just fell together and it was magic.
Years later I was in a place where it was common to have half-day builds (30 minutes if you arranged things well). In fact, my last three weeks on that job I never got a working build at all, despite our group having an entire source control team whose job it was to make builds work.
Current big project, it's about 30 seconds of tool churning, then another 30 of startup time. Could be better.
- kyled 10y agoCan you go into more details? Why did something take 30 minutes or longer to build? Was the environment being cleaned every time? Was an artifact server not being used?
- kabdib 10y agoI've had long turnarounds (other than the artificial punchcard hell that is really just economics surfaced by IT budgets) in many projects. The ones that come to mind: - Burning EPROMs for the hardware bring-up of a consumer 68000 machine. Download and burn time for six EPROMs was well over 45 minutes. Things got better when we wrote a downloader, but initial bring-up was kind of painful for a couple of months. - An unbelievably crappy and development-hostile environment for set-top boxes. Getting 900K of code to a device could take 20-30 minutes, and the transfers often just abjectly failed. "Working as designed" said the people running the head-end. If you wonder why set-top-box software sucks so hard, this is one of the reasons. The whole TV industry is a fractal of shitty practices. Not that I'm bitter. [I did a work-around that let us do dynamic code loading over a different pipe that we theoretically weren't supposed to use "for network stability purposes" and got a biiig bonus after our team's productivity went way up] - Game development using a cross-assembler on a minicomputer,. The mini was also used as the department's email and office memo system. 45 minutes during the day turned into less than 5 minutes at night, so you can imagine the hours I kept. - Working on some Windows internals, the less said about this, the better. The common thread: When bad decisions and designs were institutionalized, things never got better. When it was possible for individuals to improve things, they did.
- agumonkey 10y agoI always laugh thinking that Turbo Pascal was so quick I didn't understand the difference between build and "build then run". And that was statically typed code on Pentium class computer.
- bananaboy 10y agoTurbo Pascal was blazingly fast even on a 286 or 386! Such a great IDE.
- FreeFull 10y agoI think Pascal was specifically designed in a way that allowed a compiler to go straight from the source code to machine code in just one pass (although the output wouldn't be particularly well optimised).
- agumonkey 10y agoTrue, I've read that they made both the syntax easier to parse, and kept the compiler relatively simple to avoid intermediate structures/allocations etc. I took a look at Wirth first Pascal compiler too, it's just too files, of acceptable length, lot of coupling though, but it's easy to guess that it's an imperative style that brings a lot of mechanical sympathy.