4 ms·

For one person working 8 hours a day, that's roughly one line of assembly language per minute. If you know assembly language, and you know the algorithms you'r

by ken 6y ago

For one person working 8 hours a day, that's roughly one line of assembly language per minute. If you know assembly language, and you know the algorithms you're implementing, that doesn't seem especially fast.

HeyLaughingBoy 6y ago
You find me someone who can code assembly for 8 hours a day continuously for two months and I'll hire them on the spot.
- unnouinceput 6y ago
  There are plenty that do, especially in embedded. I did assembly at Siemens half the day (the other half was C) when I worked for Siemens VDO in 2005-2006. It's not that hard, especially if you do simple stuff, opposed to high algorithms I usually implement these days in higher programming languages.
- CamperBob2 6y ago
  I've had jobs where that level of productivity would have gotten me fired for goldbricking. Gotta love the game industry...
- ken 6y ago
  Is that a serious offer? It's been a couple years but I'm sure with a little practice I could get up to speed again, and (like half the country) I do happen to find myself out of a job right now.
  - HeyLaughingBoy 6y ago
    No, I was trying to make a point. Namely, that no one produces that kind of output consistently over time. I apologize for not taking current economic conditions into consideration with what was clearly a poorly-worded post.
m463 6y ago
how long would it take you to write a fast circle routine in assembler? (with stack overflow blocked)
- vidarh 6y ago
  In general I'd rely on symmetry per 1/8th I think, because within each quadrant you can mirror half by swapping x and of offsets. Then basically use the same approach as Bresenhams line algorithm adapted to integer, but instead of calculating a fixed slope, look it up in a table and adjust based on radius. There is Bresenham's circle algorithm - I don't know it, but I'd guess it's not that far off the above, because the above is a pretty obvious solution when you know even the idea behind Bresenham's line algorithm and you know basic trigonometry. Basically "everyone" that has done anything graphics related pre-fast floating point and pre-fast general multiplication/division in CPUs are used to the fact that you can boil anything involving trig down into tiny tables of number of steps in one direction before the next step in the other direction to avoid multiplication. You can often forego the tables for a few shifts, but it's often not worth it. You then look for mirroring as a means to avoid replicating computations wherever possible. It'd certainly take a bit of time to get it just right, but at a few dozen instructions at least, you have a reasonable amount of time to figure it out. But more importantly: Most of the code will include a lot of pieces that takes far less than a minute per instruction. I wouldn't be able to do it fast enough now given that it's 30+ years since I last wrote much assembler by hand and it'd take me a few days to get back up to speed, but this isn't a difficult challenge. Of course it'd also depend on CPU. One thing you need to keep in mind is that the code density of assembler is very low. Once you know you need to add two 16 bit numbers together on an 8 bit CPU for example, you know what to write for several instructions. E.g. you might end up with something like this (roughly 6502, though I don't remember all the details of the assembler syntax; I'm assuming the use of <var to address the low byte of a 16 bit pair, and >var to address the high byte as at least some assemblers used that as shorthand to indicate address offsets), assuming two 16 bit values in var1 and var2, with result stored in var1 CLC ; Clear carry flag; can be ommitted if you know carry will be clear LDA <var1 ; Low byte of var1 ADC <var2 ; Add with carry of low byte STA <var1 LDA >var2 ; High byte ADC >var2 STA >var2 That's 7 instructions that you'll do "automatically" when you're programming these CPUs daily and know you need an addition. But even on much higher level CPU's like the x86 or M68k the density of high level concepts to assembly instructions is pretty low.

by ken 6y ago

HeyLaughingBoy 6y ago

You find me someone who can code assembly for 8 hours a day continuously for two months and I'll hire them on the spot.

unnouinceput 6y ago
There are plenty that do, especially in embedded. I did assembly at Siemens half the day (the other half was C) when I worked for Siemens VDO in 2005-2006. It's not that hard, especially if you do simple stuff, opposed to high algorithms I usually implement these days in higher programming languages.
CamperBob2 6y ago
I've had jobs where that level of productivity would have gotten me fired for goldbricking. Gotta love the game industry...
ken 6y ago
Is that a serious offer? It's been a couple years but I'm sure with a little practice I could get up to speed again, and (like half the country) I do happen to find myself out of a job right now.
- HeyLaughingBoy 6y ago
  No, I was trying to make a point. Namely, that no one produces that kind of output consistently over time. I apologize for not taking current economic conditions into consideration with what was clearly a poorly-worded post.

m463 6y ago

how long would it take you to write a fast circle routine in assembler? (with stack overflow blocked)

vidarh 6y ago
In general I'd rely on symmetry per 1/8th I think, because within each quadrant you can mirror half by swapping x and of offsets. Then basically use the same approach as Bresenhams line algorithm adapted to integer, but instead of calculating a fixed slope, look it up in a table and adjust based on radius. There is Bresenham's circle algorithm - I don't know it, but I'd guess it's not that far off the above, because the above is a pretty obvious solution when you know even the idea behind Bresenham's line algorithm and you know basic trigonometry. Basically "everyone" that has done anything graphics related pre-fast floating point and pre-fast general multiplication/division in CPUs are used to the fact that you can boil anything involving trig down into tiny tables of number of steps in one direction before the next step in the other direction to avoid multiplication. You can often forego the tables for a few shifts, but it's often not worth it. You then look for mirroring as a means to avoid replicating computations wherever possible. It'd certainly take a bit of time to get it just right, but at a few dozen instructions at least, you have a reasonable amount of time to figure it out. But more importantly: Most of the code will include a lot of pieces that takes far less than a minute per instruction. I wouldn't be able to do it fast enough now given that it's 30+ years since I last wrote much assembler by hand and it'd take me a few days to get back up to speed, but this isn't a difficult challenge. Of course it'd also depend on CPU. One thing you need to keep in mind is that the code density of assembler is very low. Once you know you need to add two 16 bit numbers together on an 8 bit CPU for example, you know what to write for several instructions. E.g. you might end up with something like this (roughly 6502, though I don't remember all the details of the assembler syntax; I'm assuming the use of <var to address the low byte of a 16 bit pair, and >var to address the high byte as at least some assemblers used that as shorthand to indicate address offsets), assuming two 16 bit values in var1 and var2, with result stored in var1 CLC ; Clear carry flag; can be ommitted if you know carry will be clear LDA <var1 ; Low byte of var1 ADC <var2 ; Add with carry of low byte STA <var1 LDA >var2 ; High byte ADC >var2 STA >var2 That's 7 instructions that you'll do "automatically" when you're programming these CPUs daily and know you need an addition. But even on much higher level CPU's like the x86 or M68k the density of high level concepts to assembly instructions is pretty low.