Live data from Hacker News

Assembly Language for Beginners [pdf]

yurichev.com

71–80 of 101 posts

Re: Assembly Language for Beginners [pdf]

#71

I actually got paid a salary for learning & programming in IBM mainframe assembler (BAL or Basic Assembly Language) in 1970, for an insurance company. The CPU memory was so small (32K, yes 32,768 bytes) that the only way we could squeeze enough functionality was to write in assembler, with overlays (no virtual memory). Debugging consisted of manually toggling hex data and instructions at the control panel. What a bla…

Whenever I see some shit like 'thanks for sharing' or 'noted' I want to kill someone. These are cautionary tales: ignore at your leisure.

No matter how you feel, posting like this will get your account banned.

https://news.ycombinator.com/newsguidelines.html

Re: Assembly Language for Beginners [pdf]

#73
post #43

I feel like 6502 assembly is probably better for beginners, but that might be because that's what I'm trying to teach myself...

This sentiment is one of the reasons why I didn't bother in the past: it's apparently so complex that I have to learn something completely different and useless these days, before I can start learning something useful. I'd much rather just deep dive into x86_64 or ARM or something. These days I know that older versions are still (partly?) included in x86_64 and that they're often mostly the same, but that was not cle…

Saying that 6502 is useless is a bit harsh- I wouldn't call it an employable skill, but it's great for hobbyists who are into retrocomputing (like me).

You could deep dive into x86_64 or ARM, but in the general case you would never actually code in those (i.e., most folks trust the compiler) unless you were writing a driver or writing something with crazy performance like MenuetOS.

Re: Assembly Language for Beginners [pdf]

#74

I actually got paid a salary for learning & programming in IBM mainframe assembler (BAL or Basic Assembly Language) in 1970, for an insurance company. The CPU memory was so small (32K, yes 32,768 bytes) that the only way we could squeeze enough functionality was to write in assembler, with overlays (no virtual memory). Debugging consisted of manually toggling hex data and instructions at the control panel. What a bla…

Ooo! I have a question! Where do I learn more about overlays? The BSD 2.11 code I've read has comments about overlays, but I have no idea where to learn more about how to understand the topic. I came across it while I was seeing if I could get newlib to compile for the PDP-11.

Game consoles supported the concept a whole lot longer than other domains. ROM bank switching can be thought of as overlay loading, and beyond that most consoles supported overlays up until 360/PS3. The Nintendo DS cartridge format natively supported overlays for instance.

Re: Assembly Language for Beginners [pdf]

#75
post #24
post #17

Now do that for the GPU.

To be fair to NVIDIA, they have done a pretty good job here. https://docs.nvidia.com/cuda/parallel-thread-execution/index...

I thought that PTX is an intermediate format, kind of like a Nvidia specific LLVM bitcode for GPUs.

Re: Assembly Language for Beginners [pdf]

#76
post #43

Earlier quoted context omitted.

This sentiment is one of the reasons why I didn't bother in the past: it's apparently so complex that I have to learn something completely different and useless these days, before I can start learning something useful. I'd much rather just deep dive into x86_64 or ARM or something. These days I know that older versions are still (partly?) included in x86_64 and that they're often mostly the same, but that was not cle…

Saying that 6502 is useless is a bit harsh- I wouldn't call it an employable skill, but it's great for hobbyists who are into retrocomputing (like me). You could deep dive into x86_64 or ARM, but in the general case you would never actually code in those (i.e., most folks trust the compiler) unless you were writing a driver or writing something with crazy performance like MenuetOS.

"Saying that 6502 is useless is a bit harsh. I wouldn't call it an employable skill"

It must be both useful and a job skill for some people:

https://wdc65xx.com/chips/

I wouldn't study it to get a job. There's apparently still utility in it, though, with WDC's versions of it.

Re: Assembly Language for Beginners [pdf]

#77
post #56

Earlier quoted context omitted.

Forgive me, but I'm struggling to understand how much useful work one could extract from a computer with only 32k of RAM. A microcontroller for an appliance, sure, but a mainframe? Could you tell us more about the work you were doing?

In 1970, a company named Telemed built an Electrocardiograph analysis service where hospitals would call in from all around the country and send ECGs over the telephone line with analog FM signals, three channels at a time. The computer located near Chicago would accept the incoming call, digitize the three analog signals every 2ms to 10 bits, write them to disk, and decode the touch-tone patient ID. When the call wa…

I would not have guessed that there were automatic ECG analysis in 1970! Was it good? Are today's methods any better?

Re: Assembly Language for Beginners [pdf]

#78
post #56

Earlier quoted context omitted.

In 1970, a company named Telemed built an Electrocardiograph analysis service where hospitals would call in from all around the country and send ECGs over the telephone line with analog FM signals, three channels at a time. The computer located near Chicago would accept the incoming call, digitize the three analog signals every 2ms to 10 bits, write them to disk, and decode the touch-tone patient ID. When the call wa…

Thank you, that's brilliant! It is unfortunate that the source code is lost to humanity, as an example of what is possible.

Ah, I could replicate it with a bunch of time and likely emulators. There wasn't anything secret about it, just good engineering with an innovation or two. The one that was the coolest was to use coroutines to kind of invert the inner loop. In the middle of the loop was a macro call that said "Get interrupt from the OS" which simply translated as a WAIT that would fire when the particular interrupt came in. We wrapped coroutine around this to properly save and restore state.

By the way, this was significantly easier than what folks have to go through with C or using that dratted asynsc/await pattern.

This particular code that used the coroutine was the outbound call processing low-level stuff. I was second fiddle on that one, and the lead was a fellow who is quoted in TAOCP. We had zero single-thread errors and one multi-thread error when we stood it up. Keep in mind that this was in the days of no debuggers other than console switches.

Re: Assembly Language for Beginners [pdf]

#79
post #56

Earlier quoted context omitted.

In 1970, a company named Telemed built an Electrocardiograph analysis service where hospitals would call in from all around the country and send ECGs over the telephone line with analog FM signals, three channels at a time. The computer located near Chicago would accept the incoming call, digitize the three analog signals every 2ms to 10 bits, write them to disk, and decode the touch-tone patient ID. When the call wa…

I would not have guessed that there were automatic ECG analysis in 1970! Was it good? Are today's methods any better?

We were the first commercial offering. There was one or two working at universities.

It was quite good.

I would imagine that they are--I haven't kept track.

Re: Assembly Language for Beginners [pdf]

#80

I actually got paid a salary for learning & programming in IBM mainframe assembler (BAL or Basic Assembly Language) in 1970, for an insurance company. The CPU memory was so small (32K, yes 32,768 bytes) that the only way we could squeeze enough functionality was to write in assembler, with overlays (no virtual memory). Debugging consisted of manually toggling hex data and instructions at the control panel. What a bla…

Forgive me, but I'm struggling to understand how much useful work one could extract from a computer with only 32k of RAM. A microcontroller for an appliance, sure, but a mainframe? Could you tell us more about the work you were doing?

A key thing to remember is that 32k of RAM isn't the only memory available; often there was all sorts of longer term storage, and in many cases the data for a job was separate than the machine running the program, which could feed that data in using a number of methods. Today's programs load entire files into RAM because it's available; back then you might load a single record from the file at a time, and there were routines to seek through the offline data (subject to optimization) and manage the working memory more effectively.

It's also worth remembering that, at the time, a machine with 32k of RAM was one of the most powerful on the market, was still considerably expensive, and the alternative was paying (a team of) humans to do the work by hand. For all its shortcomings and the insane complexity required to get the machines to work properly, they were generally much faster than humans performing the same task and generally (assuming they were programmed correctly) could be relied on to make fewer mistakes. Their utility was remarkable, especially their ability to perform arithmetic very quickly, which was (and still is) quite tedious to perform by hand.

Post reply on HN