Internet programming...

Enygma

Originally posted by Trojan

But there is room for an elitist attitude when you're in the pub with your Java/C#/html-loving mates, and there is room for an elitist attitude when you're slagging on a BBS

LOL! yeah I suppose there is

Trojan

Originally posted by Enygma

LOL! yeah I suppose there is

Finally, somebody gets it - ye were all getting a bit too serious back there!

Reply to MoonHawk: it's C I'm doing at the moment, and it isn't mad low-level or anything, it's above the kernel (most of the time), but still what I'd term system programming. We don't do much assembler, leave it to the compiler 99% of the time.

That's not to say that I agree with Meh...

Originally posted by Meh

My point is that compilers generate more efficient assembly code than humans do

Nice one. But wrong.

Perhaps what you intended to say was "compilers will, in certain circumstances,[0] generate more efficient assembly code than humans do".

You application programmers have things too easy with your flashy IDEs and tab-completed keywords - it shows in your laziness in language!!

Al.

0: I would also accept any of: "sometimes", "usually", "a lot of the time", "normally" and one or 2 other terms. It's in no way black and white.

Greenbean

Now, I have to admit I'm no expert in this field - but it would seem to me that the optimisations that compilers can do today can only be "local" optimisations and generally things that are clear to the average programmer. But I would doubt that a compiler could start optimising code at assembly level for the more fancier tricks that surely exist. We're talking about, I dunno, throwing in instructions when you know there will be a .02ms gap in the bus, that only you can know about - due to the design of your program, that the compiler could never really see.. something thats part of the bigger picture. I had assumed that this was where the main gains in assembly language would come from - check out some of the old 64kb intros from the demo scene, they are definitely doing things with the cpu that programmed from even C would not be possible.

About the "trendy"-ness of high level programming languages - yep, no point in messing around doing work you don't need to be doing, but from an educational view point they are a big barrier. I reckon the more basic the language you learn the greater the understanding you can aim to get. Its only now that I see what the hell is going on with Java and why we declared everything on the heap - not that I knew I was doing that at the time. Even the basics of the range of values you can represent with a signed and unsigned int are rarely focused on in college - its good to get down to the nitty gritty and see why your programs in higher level keep breaking - no matter how level they seem, they always end up being restricted by lower level details and you're screwed if you don't know why.

edited for clarity

no matter how level they seem, they always end up being restricted by lower level details and you're screwed if you don't know why.

My point exactly greenbean, although nowadays we will do our programming through graphical editors and all that, we will need to know what's happening "behind the scenes" to fully understand what's happening.

bonkey

Originally posted by Trojan
Nice one. But wrong.

Perhaps what you intended to say was "compilers will, in certain circumstances,[0] generate more efficient assembly code than humans do".

<snip>

0: I would also accept any of: "sometimes", "usually", "a lot of the time", "normally" and one or 2 other terms. It's in no way black and white.

I would actually argue for a much simpler replacement.

Compilers will, on average, generate more efficient assembly code than humans do.

There will always be specific places where hand-optimising will be the way to go, typically where optimisation can make use of knowledge of the type of data which will be used.

Of course, compiling code with a compiler has been empirically proven to be a far more time-efficient approach as well, making it the desirable solution in the vast majority of situations.

On the other hand, its hard to brag about your l33t VB skillz when faced with a x86 assembly guru

jc

Hobbes

TBH I think asm is way easier then most languages to learn, but it's god awful slow to physically write anything (unless you have libraries) and not very portable.

I did a bit of x86 back in my DOS days and then it was only for speed reasons and I would normally call the asm from a VBDOS or batch file process already set up. I certainly wouldn't try to do a whole application in it when there are much easier alternatives.

In a good language (or OS?) the programmer should never have to worry about how the OS/processor works.

Trojan

*sigh*

Now even Hobbes is doing it...

Originally posted by Hobbes
In a good language (or OS?) the programmer should never have to worry about how the OS/processor works.

In a good language (or OS?) the application programmer should never have to worry about how the OS/processor works.

Otherwise we'd all be going around with nobody knowing what was going on

bonkey: nice one, agree with your points.

Al.

Well I agree with Trojan, we need to have SOME understanding of how the PC operates, in order for us to become more efficient...just another thing, is C or C++ closer to the architecture than other higher level languages?

I've done a bit of C, moving into C++ shortly and I've noticed that you can call ASM code from the program itself for various different parts of the code...is this beneficial in C/C++?

Greenbean

C++ is a subset of C, they're both pretty much based on the same code. In general a huge program made out of C should be faster than C++, though in theory you should make the program quicker in C++, and in reality it should be easier to maintain. The object orientated nature of C++ is another layer of code between it an the CPU - but there are plenty of techniques that can keep it a fairly thin layer, combined with optomised compilers. Taking a quick look at ASM it seems to me that C is far closer to the architecture than I ever thought. If you program with care it could almost be as good as ASM.

Hecate

Taking a quick look at ASM it seems to me that C is far closer to the architecture than I ever thought. If you program with care it could almost be as good as ASM.

Indeed, we were using the code below in a lab the other day to turn a fan on and off


#include "hc11.h"
void OnSerialInterrupt(void);
void FanOn(void);
void FanOff(void);

void SerialISR(void)
{
/* NOTE: X is pushed automatically by c-compiler */
/* If any local variables are used don't forget to
re-adjust the stack */
OnSerialInterrupt();
/* stack cleanup and rti */
asm(" rti");
}
void OpenSerialPort(void)
{
fptr *ISRPtr;
asm(" sei ") /* temporarily disable interrupts */
BAUD = 0x30; /* set data rate to 9600 */
SCCR1 = 0x0; /* 8 databits, 1 stop bit */
SCCR2 = 0x2c; /* enable receiver, transmitter and
receiver interrupts */

ISRPtr = (fptr *)(unsigned)0x00C5; /* vector is at $00C5 */
*ISRPtr = SerialISR;
asm(" cli "); /* re-enable interrupts */
}
void TransmitString(char *Str)
{
int i;
i = 0;
while(Str) {
SCDR = Str;
while(!(SCSR & 0x80)); /* wait for tx buffer to empty */


i++;
}
}
void DisplayMenu(void)
{
TransmitString("Welcome to the 68HC11 control menu\r\n");
TransmitString("Choices:\r\n");
TransmitString("1. Turn Fan On\r\n");
TransmitString("2. Turn Fan Off\r\n");

}
void FanOn(void)
{
PORTA = PORTA | 0x40;
}
void FanOff(void)
{
PORTA = PORTA & 0xbf;
}
void OnSerialInterrupt(void)
{
BYTE UserCommand;
if (SCSR & 0x20) /* Has data Arrived */
{
UserCommand = SCDR;
switch(UserCommand) {
case '1': FanOn(); break;
case '2': FanOff(); break;
}
DisplayMenu();
}
}
main()
{
DDRA = 0xff; /* set up port A as an output port */
PORTA = 0; /* clear port A at startup */
OpenSerialPort();
while(1); /* now sit in idle loop */
}