It's a small distinction, but surprising to see this mix up as assembly language enthusiasts tend to be sticklers for these details!
I could imagine such phrasing being done by non-native English speakers, of which I'm have no doubt that there are a significant number.
My (unresearched) guess is that this is simply different dialects of speakers emerging with respect to informal references over the decades.
Still, I don't really care what it's called.
I used 'assembler' back in high school, when I was learning about the 80x86. I remember because I was 'corrected' by fellow student who had never touched assembler, assembly language, machine code mnemonics, or whatever you want to call it.
I have no idea where I got the terminology, but I was reading a lot of books and Usenet posts on the subject at the time. I'm a native English speaker, for what it's worth.
Wow, you got the Hacker News experience 30 years in advance!
Writing compilers gets difficult, quickly. But writing assemblers is/was common enough for simple architectures and it's quite fun and relatively easy to prove/test for correctness. At least compared to most compilers.
One of my first gigs out of school involved writing a Z80 assembler because I "needed" nonstandard (Sharp/DMG/8080) instructions to be handled during a codebase port. It was enjoyable! I recommend everyone write an 8-bit assembler at least once!
Still, TFA is very interesting and I appreciate OP's share. :-)
Here are examples of such usage, from 1967 and more recent:
http://www.bitsavers.org/pdf/ibm/360/asm/C28-6514-5_IBM_Syst...
https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-assem...
As usual in natural language it's pretty clear from context which one is meant. Not sure about other (larger) European languages, it seems it's possible usage in German but it's not the primary case from a quick search.
https://www.pymnts.com/artificial-intelligence-2/2023/amazon...
Edit : link
Who knows, it might be a shot in the arm for retrocomputing enthusiasts.
This one's probably pretty well covered, actually. All of Apple's Inside Macintosh documentation is available in PDF format, and there's plenty of old programming books and magazines which have been scanned and OCRed.
Without large code examples, can a LLM write even halfway decent code?
> there's plenty of old programming books and magazines which have been scanned and OCRed.
In my memory, the heyday of printing programs in magazines was before the Mac. Macintosh programs were too large to print in a book or magazine, and other methods to distribute code were available (ftp servers, CDs)
I would think a good LLM for assisting working on the Mac toolbox needs data from ftp sites and CDs.
// Zero page variables
.const zp_x = $FB
.const zp_y = $FE
.const zp_dx = $101
.const zp_dy = $104
AI extended zero page, I see… (zp_dx and zp_dy are in 6502 hardcoded stack range, not in zero page at all).Seriously though it makes me think of how hit-or-miss Microsoft Copilot is at writing code (we have a special license to use it at work.)
For certain things such as writing short bash, CMD.EXE and PowerShell scripts it does great. It writes great list comprehensions in Python. Can convert code defining a set of typed dicts to a set of dataclasses. Can write a SQL query using an obscure (to me) feature and then rewrite it in JooQ.
But write a CTE expression in JooQ? It doesn't understand how to break the circularity.
Configure Vite? It will insist on the same wrong answers ceaselessly. On the other hand, if you look at StackOverlow the answer seems to be "you can't get here from there" or "there is this plugin that might help if it worked but it doesn't."
Combined, hardware is finally approachable down to the gate level, even when modern systems add many layers of abstraction.
I use my fingers and 9 small rocks...
Recently I have been busy writing the emulator in Golang: