LDX #$0F
STX $D020
STX $D021
DEX
CPX #$00
BNE $F7

Hehehehe… anyone recognize the language? Bonus points if you know what it does. Yes, I did have to lookup the BNE syntax, and yes, you do have to count.

This might be good reading.

I had a good chuckle at the Haskell and Lisp entries. Good link!

http://iwasjustcurious.blogspot.com/2007...

Was good too. Darn Nixies.

Ok, time's up. It's 6502 assembly language, and specifically written to have special meaning if you run it on a Commodore 64. That code loops through all 15 screen colors and sets the screen border ($D020) and background ($D021) to those colors… very quickly!

I've advocated teaching assembly as the first language people learn in school because, even though it's hard to do anything practical with it, it shows you exactly how the computer really works. I had zero problems understanding pointers in my first college class (I used basic and assembly before that), because I knew how pointers really worked. Most of the rest of the people in my Pascal class looked at them as magic words and didn't like the voodoo of making one magic word invoke another magic word.

The Motorola 6502/6510 CPU was an 8-bit CPU with 16-bit memory addressing. Hence the 64K limit to main memory. It had an accumulator register and two 8-bit indexing registers, called X and Y.

The only clever bits are the last two lines (not really clever, but unusual if you're not used to assembly). CPX #$00 compares the contents of the X register to the constant 0.
BNE $F7 says Brance if Not Equal to memory location offset $F7. That's actually a bug, I miscounted! $F7 is a signed number, so instead of being 247, it's the 1's compliment number, -9. It really should have been -11, I forgot to count the current instruction.

To do a loop in assembly, you do a GOTO from the current location of the program counter (In this case, the byte after the data value for the BNE instruction). So, counting the fact that every instruction is 1 byte long, and the two memory addresses are 2 bytes, to put us back at the first STX instruction, we'd walk back 11 bytes.

The code above says

char x = 15;
do
{
    *(53280) = x;
    *(53281) = x;
    x–;
} while ( x > 0 );

So, in my quickie code example, because of the bug, it would have flickered the background color, but only set the border color to 15 and never touched it again. At the end of the loop, the border will be light grey, and the background will be black. :)

Personally, I think we should make them write their code on punch cards.

In all seriousness, there are ways to adapt assembly into your C programs just fine for teaching purposes without having to go all out teaching students a dead language. Also, considering most modern languages have done away with pointers, and in C++ most large-scale projects no longer use pointers in favor of references, I think in the next 25 or so years knowledge about pointers will be about as useful as knowledge about assembly for the general public.

You see a man trying to compile a C++ mud but only has access to gcc. Remain calm.

There is a fifth dimension beyond that which is known to man. It is a dimension as vast as space and as timeless as infinity. It is the middle ground between light and shadow, between science and superstition, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination.

You've just entered the twilight zone.

Every "WOW" control I've ever seen for WinForms or some magic performance code inevitably has an unsafe, unmanaged (those are keywords) block where they're manually pinning memory and using pointers to get things done - usually copy or drawing operations. Of course, like you said, eventually we'll hit processing speeds where you won't have to do that kind of thing to avoid flicker or ungainly slowdown, though it would still be good for languages to provide those facilities - in case you know how, and do want to, do those things.

Well, I know today pointers play a key role in much development and are still wide-used. I'm talking about 25 years down the road. However, even in C++ it is possible to accomplish the same things without pointers through use of references. I've had instructors that demanded such (with good reason). Generally references can accomplish the same thing. Pointers, at this point, are still a completely valid study, but software engineering is changing at a very fast rate.

I remember when there used to be a wide use of "goto" tags in C to model it somewhat off of the "goto" principal in lower languages. It was actually pretty widespread because people thought that low level concept should be maintained, but years into it was accepted that we no longer needed to use goto because of the error and type of poorly designed code it represented. Point is, as our technology changes, so will the views of what is acceptable practice.

Being that there are existing and upcoming solutions that do the same things pointers–and the inside baseball that pointers represent for new computer programmers– I don't see a place for pointers in the long term in new languages being developed. It's more likely it will be something that is related to references.

To save this post from derailing this thread, I think pointers will continue to be used in the RaM codebase. ;)

:thinking:

Using just my first name is preferable to the above. :wink:


The problem is that that removes the focus from problem solving and throws you into nitty-gritty details that have little relevance to the problem you are trying to solve. I consider myself a fairly decent programmer, and yet my assembly experience is limited to very trivial examples. I think that the goal of understanding how the low-level system works can be accomplished by taking OS, compilers and architecture courses.

Wrenching the thread back around… anyone planning on showing up tonight? I may have to cut out early, but I'm around for an hour or two.

Just so everyone is on the spot, I've put another chunk of revision into SVN, and if my connection will handle it, I'll upload a full snapshot for those who don't like SVN. It's probably a good practice to do that once a week or so until development settles down into a real feature/bugfix model, instead of me randomly rearranging code to confuse you all mode.

I assume the usual place: sulinea.arth...

Yes, though I'm a bit late, I am planning on being there.

Howdy folks!

It's that day again… SundaySundaySUNDAY! No, not monster truck demolition, just another installment of jibber-jabber over at sulinea.arth....

Unlike previous weeks, I have nothing to bore you all with this time, since my hard drive melted this past week and I've spent my free time finding a replacement, making the blood sacrifice required to install it, watching TV while windoze re-installs, and of course, figuring out where my various backups lived, and deciding what to restore and what to re-install, and what to just not bother with.

As a result, if anyone wanders by, this meeting will focus on ways to tackle the C -> C++ conversion that I'll now be starting THIS week. If nobody cares yet, that's ok too. I really didn't have time to get the gumbo ready anyways. :)

Hey everyone!

On the plus side, my system has been mostly restored and there's a break between holidays, so I should get a few things done this week. On the minus side, I only got a little bit of planning done, and have perused a few other C++ socket type things to try and get ideas for how to proceed.

The normal mud we've been using appears to be down at the moment. Not a big deal, although if anyone did want to chat about where things are going in a more-or-less live forum, I'll point you all at wiley.shadow..., which is my dead MUD from the old days. It's not pretty, and it's not friendly, but it was fun, and if the nameserver gods are happy, you can connect to it. :)

If not, I'll again post the general ideas in a meeting log thread for people to comment upon. This is kindof an interesting point, since it's the "last chance" to change directions (not for the project, just for how the code is evolving). More on that later.

I connected to Wiley for a moment, but then it went down when I selected "enter the bloodbath", and I can't reconnect. =(

Did I break it?

Connected again, selected "Start the Bloodbath" again, and it crashed again. =(

ROFL!

You've found a bug! Apparently there's a glibc malloc corruption I missed that has surfaced now that I added SQL logging support. As you can tell, it gets very little traffic so I don't notice crashes often.

Hmmmm, ok. I'll see what I can do about that, sorry!

Hmmm, no trace information, so it wasn't a crash by my code poking something (directly) that it shouldn't have… rather it was glibc's internal routines finding memory written to that shouldn't have been. I've relaunched it in gdb to try and see what it's doing if it crashes again.

It looks like you made it through creating a character, it loaded you (no rental data), and then glibc stopped the show somewhere after that.

This codebase originally ran on a Sun 3/60 in 1993 (Motorola 68020 CPU around 20MHz, 8 Megs of RAM, SunOS 3 and gcc 2.1 or thereabouts), so it's been through a lot.

Hmmm, here's a nice one from the malloc man page… apparently if you set MALLOC_CHECK_ to 2, it calls abort() instead of just stopping.
Hopefully that will help. I see you advanced to level 1 this time, so that's progress? :) It does only seem to happen for new characters.

This is all the fault of gcc 4.2 for changing internals again…. *sigh*

Interesting:



It's crashing in realloc()… almost there. :)

Hmmmm, I used realloc() to try and optimize a spot I probably shouldn't…. resizing a string buffer. Stupid C strings. Anyways, I'll replace it with a free() and strdup() pair and see if that works better.

Now I connect, but I never see the splash appear… =P

#session new wiley.shadowlord.org 3000

#Trying to connect to wiley.shadowlord.org port 3000.

#SESSION 'new' CONNECTED TO '2.0.11.184' PORT '3000'

Yep, that's it hanging in the debugger while I poke at stuff. It's recompiling now and we'll see if a free/strdup makes gcc happier than a (used to be perfectly valid) realloc.