I didn't say it was very clear or even a logical description of computer programming today to use Assembly Line terminology but early on programmers were seen as just clerical workers or technicians hired to do the repetitive job of cranking out traditional manufacturing products in a traditional automated process.Yes. For clarity, I shall use this in the future. In fact, I will endeavor to obscure (in a clarifying way, of course) it further.
Should go over well with the noobs.
I am desperately in need of a sarcasm font.I didn't say it was very clear or even a logical description of computer programming today to use Assembly Line terminology but early on programmers were seen as just clerical workers or technicians hired to do the repetitive job of cranking out traditional manufacturing products in a traditional automated process.
Not sure about that... but I do qualify as a CPU:ASM - Analists, Smartasses, and Masochists. Anyone here qualify for membership based on any one of the pillars?
I had a friend that was a unibrow. She used to have two brows, but she shaved the top one off.Not sure about that... but I do qualify as a CPU:
- Compulsive
- Perfectionist
- Unibrow
And assembly is a group of code mnemonics organized together ("meeting") for the processor they are defined for."Assembly" is a meeting as in United Nations. "Assembler" is a program which assembles the machine code. It uses it's own language - "Language of Assembler" or "Assembler Language".
That would imply some form of 'self-actualization' or independent action, no?And assembly is a group of code mnemonics organized together ("meeting") for the processor they are defined for.
Only if you're paranoid. Luddite!That would imply some form of 'self-actualization' or independent action, no?
There are Luddites on this board. I could name two extreme examples off the top of my head, but I won't -- they know who they are. I am not one of them.Only if you're paranoid. Luddite!
Ludd·iteOnly if you're paranoid. Luddite!
Sure... I'll applaud until my hands hurt.... if you tell us what it does or what it's forMy latest .asm project is now complete. It is a PIC18F65K90 based design. This one is going to be a big winner.
Here are the stats:
13 include (header) files
22 assembler (assembly?) files
9,976 total lines, including comments and white space
13,187 program memory bytes used
Absolute (as opposed to relocatable) build.
Lots and lots of 32/56 bit floating point math (IEEE notation) -- including statistical data analysis, 2nd order polynomial regression, matrices, etc.
Bug free and fast as lightning.
You may now applaud.
You have no idea how badly I want to give details.Sure... I'll applaud until my hands hurt.... if you tell us what it does or what it's for![]()
... if you tell us what it does or what it's for![]()
;*******************************************
;** REGRES -- Compute A, B, C for **
;** y=A*x^2 + B1*x + C using **
;** posted data **
;** Exit: FMEM2=A, FMEM1=B, FMEM0=C **
;*******************************************
regres cpfloat num, mat00 ;fill matrix for D
cpfloat sx , mat01
cpfloat sx2, mat02
cpfloat sx , mat10
cpfloat sx2, mat11
cpfloat sx3, mat12
cpfloat sx2, mat20
cpfloat sx3, mat21
cpfloat sx4, mat22
call determ ;get D
popfl det ;save as denominator
cpfloat sy, mat00 ;fill matrix for Dx
cpfloat sxy, mat10
cpfloat sx2y,mat20
call determ ;get Dx
pushfl det
call divf ;compute B0
popsto 0 ;save 'C' coefficient in FMEM0
cpfloat num, mat00 ;fill matrix for Dy
cpfloat sx , mat10
cpfloat sx2, mat20
cpfloat sy, mat01
cpfloat sxy, mat11
cpfloat sx2y,mat21
call determ ;get Dy
pushfl det
call divf ;compute b1=Dy/D
popsto 1 ;save 'B' coefficient in FMEM1
cpfloat sx, mat01 ;fill matrix for Dz
cpfloat sx2, mat11
cpfloat sx3, mat21
cpfloat sy, mat02
cpfloat sxy, mat12
cpfloat sx2y,mat22
call determ
pushfl det
call divf ;compute b2=Dz/D
popsto 2 ;save 'A' coefficient in FMEM2
return
I do all my programming in assembly, but only on the 8051 architecture... so far. And yes, since most of my applications are timing-critical (where things must be kept in sync) I haven't even remotely considered using C, or any other language for that matter.You have no idea how badly I want to give details.
Someday, I'd like to transition from entrepreneur to professor where I'd pass my .asm coding techniques (and a great deal of other knowledge) to the next generation of engineers. Yes, I do believe there will always be a need for .asm -- even for the next generation.

I programmed professionally for about three years (many years ago). However, higher level languages can still do the job assembly can, even for real-time critical applications. As long as the language has appropriate constructs for accessing devices and such (even accessing program status words and setting/processing interrupts). Modern compilers generate extremely efficient machine code. Besides, its not the high level language that slows things down, its the OS and its overhead.I do all my programming in assembly, but only on the 8051 architecture... so far. And yes, since most of my applications are timing-critical (where things must be kept in sync) I haven't even remotely considered using C, or any other language for that matter.
And I know the feeling when one finishes an important and complex project that required a humongous amount of effort, and one is constrained from giving out the details.... kind of frustrating when you can't share your success with your peers.
You're right, there will always be a place for assembly in the market. (assembly, assembler... tomato, potato... whatever)
EDIT: here's your applause, by the way View attachment 93245
Mostly true... my only objection is when one has to count the exact number of cycles between instructions and routines to perform certain tasks.Modern compilers generate extremely efficient machine code. Besides, its not the high level language that slows things down, its the OS and its overhead.
Here we go again!I programmed professionally for about three years (many years ago). However, higher level languages can still do the job assembly can, even for real-time critical applications. As long as the language has appropriate constructs for accessing devices and such (even accessing program status words and setting/processing interrupts). Modern compilers generate extremely efficient machine code. Besides, its not the high level language that slows things down, its the OS and its overhead.
Sorry, Jim, but which OS are you referring to?...its not the high level language that slows things down, its the OS and its overhead.