SASM – Simple Crossplatform IDE for Assembly Languages | Hacker News Reader

SASM – Simple Crossplatform IDE for Assembly Languages

dman95.github.io

120 pointsHalienja35 comments

This is pretty neat. Neat enough to make me use it over Emacs? ...maybe. But Emacs+GDB is pretty hard to beat. Unless you're an MDB user, I suppose. Other than syntax, I never really saw the difference.

GAS support is nice. I actually like AT&T syntax, but I seem to be in the minority on that.

Emacs + gdb is something I have absolutely never seen in any "featurful IDE." It's an absolutely incredible development experience!

I never saw it like that in the days I had to change Borland, Zortech and VS experience by UNIX one in the late 90's, and from my latest experiences it hardly changed.

DDD was always one of the gdb frontends I installed to make things somehow better.

> I never saw it like that in the days I had to change Borland, Zortech and VS experience by UNIX one in the late 90's,

I'm not sure I understand what you mean by this. Can you explain? Also, what did you not like about the experience?

gdb is ok if your needs are simple, and great if you have very complex needs where your need the scripting etc. But it's awful if you want to e.g. quickly step through a bunch of assembler and get a thorough overview of registers + stack frames + dereferencing random chunks of memory.

You can do all of it, and with emacs you can do all of it in buffers, but it feels terribly clunky to me, coming from e.g. Amiga assembly IDE's like AsmOne, that while overall more primitive than gdb, has good defaults for the UI that makes the information most people want very easily available.

Emacs + gdb is like getting your debugger delivered as flatpack and having to assemble it yourself. Great when finally get it just the way you want it, but the learning curve is horrible.

Vidarh already explained it quite good.

Also there was no support to display structures graphically (ddd could do it though).

Nowadays modern graphical debuggers also provide a very nice set of features to debug multi-core code.

Don't many GDB frontends provide this, however?

Back then it was only DDD in regards to data structures. I mean converting a struct into a visual tree, navigable between nodes, think UML like.

As for parallel debugging I am not aware of any front-end with the same feature set as modern IDE debuggers.

Okay. Well, then, now we know.

I was a fan of DDD back in the day (long ago, when the Motif based UI was OK), but that was because I really didn't know how to use plain gdb.

I'm actually surprised that DDD continues (somewhat, there was a release in 2009).

I still think the Motif GUI is OK. It's ugly by modern standards, but it's functional, fast, and works wayyyy faster over the network than anything GTK- or Qt-based. Any toolkit that renders with X primitives tends to actually be functional over the network; anything that renders with pixmaps not so much. That pretty much leaves Athena, Motif, Tk, and a handful of custom GUIs like the one you find in xv. They're mostly all ugly, but there's really no reason an Xlib/XCB/Xt-based GUI must be ugly -- it's just that at some point everyone decided to start rendering via pixmaps so the ones that don't are all old at this point. Personally, I'll deal with the ugliness if it means I have a responsive UI! Bonus points for small binary, small memory footprint, and stable API.

Heh. Given how Athena itself seems to be run atop ubuntu these days, I wonder how MIT gets all the GUIs working.

Unless the architecture of Athena has changed radically, and it's no longer using networked X...

I mean libXaw ("X Athena Widgets", and its siblings Xaw3d, Xaw3dXft, neXtaw, etc.). I'd be very surprised if the total Athena project even still uses it for any new code given how old-skool it is.

I doubt they do either. I was just wondering how Athena runs over a network, given it's using GUIs with pixmap primitives.

libXaw[3d[Xft]] don't use pixmap primitives, but geometric primitives. The X protocol has messages like: "draw a polygon with these vertices and this visual". Sometimes a bitmap or pixmap might be used to render an icon or something, but most of the window is drawn via these primitives. Contrast to GTK (for example, but most "modern" toolkits do this) everything is rendered to a pixmap (via, e.g., GDK or Cairo), and the final pixmap representing the entire window is handed off to X to display with a single message like: "draw this pixmap at (0, 0)".

The primary reason Xaw and kin (along with Motif, Tk, and other toolkits that make good use of X's drawing primitives) get better network performance is perhaps obvious at this point: a handful of serialized polygon objects is smaller than a TrueColor pixmap. Basically, windows drawn with GTK and friends are practically streaming video with lossless compression (if any), while windows drawn with Xaw and friends are more like SVGs.

The end result is that the X-primitive-based toolkits use much less bandwidth than the pixmap-based ones, and the difference is usability is often enormous.

I know. However, Project Athena itself isn't using Xaw. It seems to be running an awful lot of GTK apps. So I'm starting to wonder if it's really networked anymore.

It was using Xaw, way back when :)

But you're right: it's probably not running X apps over the network anymore. Back when the X protocol was designed, it was still common that terminals were pretty spartan, whereas the servers they connected to were beefy machines. Nowadays, "terminals" with decent compute power are common (this has been the case for quite some time now), so it makes more sense to run the X clients locally in most cases.

That being said, I for one still run X apps over the network fairly often, and would do so more often if many of the apps I used didn't suck so much over the network.

For comparison, try running an xterm tunneled over ssh side-by-side with a gnome-terminal or something else GTK-based (also over an ssh tunnel). Play some emacs tetris or something in both. The difference is even larger when the clients in question make more use of various widgets, but I'm having a hard time coming up with a fair comparison (I'd suggest gvim compiled with Xaw or Motif versus gvim compiled with GTK2 or GTK3, but I gather you're an emacs user so that might be a poor exercise -- perhaps emacs's GUI has similar options?).

You do know that GDB has a curses interface, similar to the Borlands one? It's on on by default, but it exists.

I was referring to the Windows 3.x versions, not MS-DOS.

Ah.

Do you have any resources you can link for learning? I tried to learn Emacs before and I ended up with cramped pinkies. Conversely, gdb looks like black magic to me.

I found it was straight forward enough to not necessitate any tutorials, even at a young age. I would say maybe just watch a video on the topic. I know for one thing a lot of colleges have recorded sessions explaining. The only real black magic I ever found was GDB script, which is also kind of straightforward

GDB has fairly complete documentation. Like most FSF projects, the documentation is amazingly complete, and also fantastically comprehensible. If you want to use GDB, it's a good place to look. Brendan Gregg had a blog post about using GDB that was on HN a few months back, which also helps explain some of the basics. Finally, Google is, of course, your friend.

As for Emacs, the first step is remapping control onto your your capslock key. It ought to stop your pinkies from cramping. xmodmap, xkbcomp, or xkb rules all provide relatively simple ways to do this. Which one you'll use depends on your distro. It's a fairly common procedure, so you can probably find instructions for your system online.

The next step is to install useful elisp packages, configure your settings, and learn all the bindings, as well as how to do the above. The excellent emacswiki can help with this.

If you're interested in a more vi-like experience, spacemacs is apparently an excellent starting config/package for this. If you're not a vi fan, however, I'd stay away from it. You can find it on github.

Remapping caps lock to control is one of the best things I've ever done in terms of configuration (along with switching to a tiling window manager). I'm not even (primarily) an emacs user, but have been a vim user for over a decade. It wasn't even an awkward switch -- it felt natural almost immediately, and I never get any kind of finger or wrist pain anymore. I do it on all of my systems. Here's a cheat sheet:

X11: Stick `setxkbmap -option 'ctrl:swapcaps'` in your ~/.xsession (if using a display manager), ~/.xinitrc (if using startx or xinit), or your startup programs if you're using a fancy-schmancy desktop environment.

Linux vtty: Run `loadkeys emacs.map` (provided it's available in /usr/share/kbd/keymaps/). It's a good idea to stick this in your rc.local or rc.conf.local or whatever the hell the systemd equivalent is.

OpenBSD vtty: Run `kbd us.swapctrlcaps` (there are similar variants for uk and some other keyboards). To make it "permanent", `echo 'us.swapctrlcaps' >/etc/kbdtype`.

OSX / macOS: There's a dropdown menu in the System Preferences under "Keyboard & Mouse".

Windows: You'll need to edit the registry. Follow the instructions here: http://superuser.com/a/916887 .

I don't have info for other systems handy, but it's most likely just a quick Google search away.

emacs.map is a thing? I used to just edit the keymap by hand. It was... unpleasant. So thanks for that.

It is on Slackware, at least! :)

I'm on arch :(.

Is Arch missing emacs.map?

No, it has it. I just didn't know that when I wrote the above comment.

It's not a very good cheat sheet. I recommend something like https://emacswiki.org./emacs/MovingTheCtrlKey instead. Whilst that has its share of problems, such as getting Linux and NetBSD mixed up, it's better.

It's actually a bad idea to stick a loadkeys command in /etc/rc.local, since that's a system that van Smoorenburg rc itself superseded, back in the 1990s. It's between 2 and 4 init/rc system overhauls in the past, at this point. It also has no guaranteed ordering relative to native mechanisms; and on many systems there are native services that configure the kernel's terminal emulator.

And /etc/rc.conf.local is a configuration settings file that largely hasn't been around on Linux operating systems since those pre-van Smoorenburg rc days. (BSDs retain /etc/rc.conf.local . Some of them actually have a strict rule about not putting anything other than a map of name=value settings in there, though.)

On Linux operating systems, the kernel's terminal emulator's configuration hasn't been done by explicitly writing a loadkeys command for almost as long.

* /etc/default/keyboard has been the Debian mechanism since roughly the turn of the century, and one has to work out what XKBLAYOUT, XKBVARIANT, and XKBOPTIONS combination means "swap capslock and control". The Debian people designed it to do both the kernel's terminal emulator and X11 in one. So one probably uses XKBOPTIONS='ctrl:swapcaps' and ignores what you wrote about X11 entirely. (-:

* The vanilla systemd mechanism is /etc/vconsole.conf , which doesn't have the internally complex Debian approach of trying to have the kernel terminal emulator and X11 configured in lockstep, and the variable to change is named KEYMAP .

On FreeBSD/PC-BSD one just sets the keymap variable in /etc/rc.conf . Out of the box, FreeBSD/PC-BSD only comes with a few keymaps that swap capslock and control, and their names aren't regular. So one will have keymap="uk.iso-ctrl" but also keymap="bg.bds.ctrlcaps" .

The nosh user-space terminal emulator uses FreeBSD/PC-BSD keymaps. But it supports overlaid keymaps. Using an overlay, the configuration import subsystem makes both a vanilla (.kbdmap) and a swap-capslock-and-control (.capsctrl.kbdmap) compiled keyboard map from each of the FreeBSD/PC-BSD keymap source files.

Thanks for the info!

You're definitely right about rc.local -- I mostly mentioned it as sort of the "greatest common denominator" of boot-time config across Linux distributions. Systemd notwithstanding, every distribution has (had?) its own method of setting the vtty keymap. I didn't know that about Debian's config, though -- that's really neat, and imho how such config should be done (though I'm a Slacker myself).

A couple of the more "BSD-ish" distributions do have an rc.conf.local (CRUX comes to mind, and iirc Arch had one in the pre-systemd days). Slackware, at least, still has an rc.local, and it's always the last step in multiuser boot (init 3, or just before the display manager is launched in init 4).

Thanks for the FreeBSD info, as well. Unfortunately, my (admittedly ancient) HDD crashed in my FreeBSD box recently (relatedly, if you know where I can find some big-ass IDE/PATA HDDs, I'm on the market... seems like NewEgg doesn't even sell IDE drives anymore, and Amazon's selection is rather shit).

nosh sounds really cool. How have I not heard of this before?!

Anyway, thanks for the learning :)

Since I started using Emacs, I adopted Xah Lee's advice: use a keyboard with symmetric Control and Alt keys so that there is access with either hand. This greatly reduces contortion...oh and use the thumbs on the Alt keys.

This winds up meaning I use Thinkpads for laptops and Microsoft Natural Ergonomic 4000 at the desktop. The upside of it is that much of the software I use allows Emacs keybindings.

I agree that using thumb on alt is a good idea, but I didn't find the extra hardware necessary: A simple control/capslock swap on my Unicomp Model M is all it took to make emacs perfectly usable.

I also used to map lshift to alt. I find it convenient. I don't know if anybody else would.

I've used Vim + GDB quite successfully.

When i was a teaching assistant for a Microprocessors course(undergrad), I used SASM and the students really liked the low entry barrier. Combined it with masm for Assembly fundamentals.

Recommend it.

Reply on news.ycombinator.com