hardware is still coded with machine/assembly language for efficiency, speed, etc.

[jlpelect5]

Hello Ratchit,

My first assembly programming was the X86 using masm6.11
Now your getting to how old I am

The intel processor had 2 modes of operation, the protected mode and the unprotected mode.

In the protected mode, the Code segment, Data segment, Stack segment and the Extra segment registers were within the same 64k block
which produced a XXX.com file.

In the unprotected mode the segment registers had there own 64k block which produced a XXX.exe file .

So being the fossil that I am, I would like to see that.

jlpelect5

 

[Ratchit]

jlpelect5,

The intel processor had 2 modes of operation, the protected mode and the unprotected mode.

The Intel processor has real mode and protected mode.

In the protected mode, the Code segment, Data segment, Stack segment and the Extra segment registers were within the same 64k block
which produced a XXX.com file.

In the unprotected mode the segment registers had there own 64k block which produced a XXX.exe file .

Protected mode uses Segment Descriptor Registers to implement virtual addressing and extends the addressing range.

So being the fossil that I am, I would like to see that.

Are you a Windows programmer? If not, you probably won't get much out of it. Are you familiar with the book I referenced? Did you have a program from the book in mind? Protected mode eliminates worrying about loading code segment and data segment registers.

Ratch

 

[jlpelect5]

Hello Ratch,

I used to be a windows programmer, and you right, I would not get anything out of it. But let's get back to the subject of new guy's getting into programming.
I feel that asm is the best way to go, learning the architure of the desired processor and or microcontroller.

Take the program that I have posted previously, using avrstudio of your choice. You can start a new program and paste that program in, with debug, stepping it through to watch the register do what is expected of the program flow.

I have nothing against hll programming as it is the industry standard, but, get these new programmers to start at the begining using free resources like Atmel
assembly programming. Learn the guts of "one" microcontroller and you will know them all Hll will be snap after that.

jlpelect5

PS. Atmel debugger is the best in the industry that I have seen !!!

 

[Ratchit]

jlpelect5,

I think it all comes down to how much can be made and sent out the door with the bare minimum of resources. That includes material things besides software. Of course expenses have to be kept in check, but nowadays greed has become incorporated, thereby taking that principle too far. Producers too often sacrifice long term benefits for short term gains. Unfortunately, many times the bad results don't always get reflected back to the management responsible. Not taking the time to produce a quality coded program is a manifestation of the problem.

What I can't understand is why folks think that Assembler takes so much longer than a HLL. Perhaps it does when starting green, but afterwards it is just a matter of how fast you can type. You can see it in the ASM code I translated. It doesn't take much longer to do it low level than high level if you have the high level aids in place.

Ratch

 

[nsaspook]

jlpelect5,
What I can't understand is why folks think that Assembler takes so much longer than a HLL. Perhaps it does when starting green, but afterwards it is just a matter of how fast you can type. You can see it in the ASM code I translated. It doesn't take much longer to do it low level than high level if you have the high level aids in place.

Ratch

About 40 years ago when I first touched a computer and had access to a box with toggle switches and a paper tape loader I felt the same way. Most of us who have been up and down the hill a few times have moved on as we turned from green to grey.

 

[misterT]

misterT, from your previous post, you even said that you have to resorte to assmebly language
in your hll programming to get the job done.

If you have started with assembly in the first place, you would not have to back track to the
language that created the hll in the first place.

The need to be productive and manage large programs created the C language. I have never said that ASM is useless. I totally agree that there is no competition when it comes to raw computing power and code size.. asm is a obviously a clear winner. But that is the only point ASM gets. I use ASM in my C programs only when it is the only choice. If I can get the job done with C or hll, why should I waste my time with ASM?.

EDIT: Ok. I give ASM another point because of what jpelect5 said. ASM is very educational. Knowing ASM makes you a better C writer. C still gets the points for productivity, maintainability, portability and good abstraction of data structures and algorithms.

This quote is from the book "The Scientist and Engineer's Guide to Digital Signal Processing".

Which language is best for your application? It depends on what is more important to you. If you need flexibility and fast development, choose C. On the other hand, use assembly if you need the best possible performance. As illustrated in Fig. 28-10, this is a tradeoff you are forced to make. Here are some things you should consider.

- How complicated is the program? If it is large and intricate, you will probably want to use C. If it is small and simple, assembly may be a good choice.
- Are you pushing the maximum speed of the DSP? If so, assembly will give you the last drop of performance from the device. For less demanding applications, assembly has little advantage, and you should consider using C.
- How many programmers will be working together? If the project is large enough for more than one programmer, lean toward C and use in-line assembly only for time critical segments.
- Which is more important, product cost or development cost? If it is product cost, choose assembly; if it is development cost, choose C.
- What is your background? If you are experienced in assembly (on other microprocessors), choose assembly for your DSP. If your previous work is in C, choose C for your DSP.
- What does the DSP's manufacturer suggest you use?

 

[Mr RB]

...
What I can't understand is why folks think that Assembler takes so much longer than a HLL. Perhaps it does when starting green, but afterwards it is just a matter of how fast you can type.
...

I've been using both for plenty enough years to not be "green" and believe me C is many times faster to build most applications in for PIC 16F and 18F.

Here's an example I used in another thread, which came from a real world RPM meter project that was coded in C in a number of minutes;

// display RPM, input period in uS is already in var in_period
// math; RPM = 60 million / period in uS
unsigned int rpm;
unsigned long math32;
math32 = (60000000 / in_period);
if(math32 > 65000) math32 = 65000;  // safe limit at 65k RPM
rpm = math32;
WordToStr(txt,rpm);   // format 16bit var to 5 text char digits
display_lcd(0,0,txt);    // display it

Even leaving out display_lcd() which would be a library function in both ASM and C how long does the rest of that code take you to code in ASM? I've done many years PIC ASM and doing 32bit/16bit division, 32bit unsigned compare, and 16bit to 5 decimal digits conversion etc are all pretty nasty things to code up (and debug!) in 8bit ASM.

 

[Ratchit]

Mr RB,

Even leaving out display_lcd() which would be a library function in both ASM and C how long does the rest of that code take you to code in ASM? I've done many years PIC ASM and doing 32bit/16bit division, 32bit unsigned compare, and 16bit to 5 decimal digits conversion etc are all pretty nasty things to code up (and debug!) in 8bit ASM. .

That is a good example of what I am talking about. I am not familiar with the PIC instruction set, but if I was into PIC coding big time, I would have a library of routines that could do division, multi-word compares, and conversion from binary to ASCII. No doubt C has those routines already. It is not fair to compare the built in routines of a HLL with an Assembler suite where those routines are not readily available. True, it takes time to write those routines once, but they are reusable later.

Ratch

 

[3v0]

This quote is from the book "The Scientist and Engineer's Guide to Digital Signal Processing" mentioned by misterT.

A key advantage of using a high-level language (such as C, Fortran, or Basic) is that the programmer does not need to understand the architecture of the microprocessor being used; knowledge of the architecture is left to the compiler.

The key advantage is that with HLL the programmer does not have to bother with the architecture. Decoupling the language from the architecture allows one to focus on the task rather that the task and the nuts and bolts of the processor. But, given the choice I would prefer a programmer that understood the architecture regardless of the language he was using.

What I can't understand is why folks think that Assembler takes so much longer than a HLL.

Because you have to deal with the processors architecture. The sheer number of lines of code is much greater with ASM. It is more complex. It takes more time to document. It takes longer to modify.

I prefer an embedded programmer to use a HLL for productivity and maintainability, I want him to know the architecture as an insurance policy.

 

[misterT]

It is not fair to compare..

But that's what this thread is all about. Comparing two languages. Is it unfair that I can write "result = (double)a * (double)b", when you "have to" write hundred lines ASM.

 

[nsaspook]

I've been using both for plenty enough years to not be "green" and believe me C is many times faster to build most applications in for PIC 16F and 18F.

Where a HLL really shines is where you need a common model of data between architectures. Data abstraction seems to be a point that gets glossed over but any large program that makes decisions based on past or present data and maybe tries to predict future actions from that data benefits from it.

Example of just one C header file from my solar monitor project. It defines the data structure interface between a PIC18 chip and a PIC32 chip using a simple serial port protocol. The complexity of this program is not in brute computation, it's mainly in the interaction of the data needed to manage energy production while charging several sets of batteries with the limited resources of a small solar energy source.

#ifndef MBMC_H_INCLUDED
#define MBMC_H_INCLUDED
/*
   This program is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation, either version 3 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

// defines and structures for MBMC networking
#define	__MBMCAPP_H

#include "mbmc_defs.h"
#include <GenericTypeDefs.h>

typedef struct harvesttype {
    LONG energy, usage, prev_energy, prev_usage, e_total, u_total;
    LONG count, charger, c_total, prev_charger, diversion;
} volatile harvesttype;

typedef struct battparmtype {
    WORD esr, current, voltage, ah, temp;
    BYTE soc, cef, flags;
} volatile battparmtype;

struct battmodeltype {
    struct battparmtype soc[MODEL_SLOTS];
};

typedef struct SDCARD {
    WORD magic;
    BYTE sdtype, sdinit, sddetect, DAYCLOCK;
    DWORD sdpos, sdnext, timekeep, time;
    struct harvesttype harvest;
    SHORT h[H2][H9]; // battery history data
} SDCARD_TYPE;

typedef struct SD_VOLUME_INFO {
    DWORD size_MB;
    DWORD sector_multiply, read_block_len;
    DWORD sector_count, serial;
    BYTE name[SDNAME_SIZE];
} VOLUME_INFO_TYPE;

typedef struct SDDUMP {
    BYTE dumping, type;
    DWORD sdpos;
} SDDUMP_TYPE;

typedef struct ccstype {
    BYTE pick, boi, boc, alert, bn;
} volatile ccstype;

struct portstype {
    BYTE PORTB, PORTD, PORTE, PORTJ;
};

typedef struct diversiontype {
    BYTE flag, power, control, alarm;
} volatile diversiontype;

#if defined(__18CXX)
typedef struct  celltype { // C18 uses byte alignment
#else
typedef struct __attribute__((aligned(1))) celltype { // force C32 to byte alignment, 32bit alignment is still critical
#endif
    WORD id,model; //      battery cell type S,M,L
    LONG voltage, current, charge, cycles, noload, date;
    BYTE cconline, online, discharged, dead, critical, valid, fresh, misc;
    float weight;
} volatile  celltype;

/*		hist[x].h[x]
 *		h0  Peukert Factor adjusted Ah usage this cycle, 			MUST BE INTERGER variable type!
 *		h1	Lowest discharge ever,
 *		h2  current lowest discharge,
 *		h3  avg discharge
 *		h4	Number of full charge cycles, h5  Number of full discharge cycles
 *		h6	Real Ah usage this cycle, 								MUST BE INTERGER variable type!
 *		h7	Min Batt Voltage
 *		h8	Max Batt Voltage
 */

#if defined(__18CXX)

typedef struct histtype { // C18 uses byte alignment
#else
typedef struct __attribute__((aligned(1))) histtype { // force C32 to byte alignment, 32bit alignment is still critical
#endif
    WORD peak, rate, usoc, bsoc, ce, cb, samplei, sampleo, ah, drate, esr, rrate, rfactor;
    SHORT h[HPARAM_SIZE]; // h[6]=cumulative battery Ah cc and inv (real),h[0]=cumulative battery Ah cc and inv (p_adj)
    LONG kwi, kwo, ttg, btest;
    LONG ahi, aho, ahir, ahop, thermo; // A stored in battery, A taken from battery, A from raw pv, peukert adjusted A
    LONG pv_eff, tot_eff; // pv generation eff factor, total system eff factor
    float peukert, cef, peukert_adj, cef_calc, cef_save;
} volatile histtype;

typedef struct buttype {
    DWORD bvi, bvo;
    BYTE boc, boi;
    LONG bii, bio, bil;
} volatile buttype; // battery voltage in/out, battery  current in/out/load ,battery on charge, battery on inverter, battery inverter load

struct almtype {
    BYTE alm_flag, alm_count;
};

struct almbuffertype {
    BYTE alm_num, bn;
};

struct mbmccmdtype {
    WORD ready, cmd;
};

struct datadefaulttype {
    DWORD data_default;
};

struct lcdb {
    CHAR b[LCDW_SIZE];
};

struct timeruntype {
    DWORD hour, day, weeks;
};

struct mbmcnettype {
    BYTE *mbmc_byte;
    WORD mbmc_index, mbmc_len;
};

#define	HOST_REQ	'0'		// request mbmc ID
#define	HOST_ACK	'1'		// data ack code, returned when finished
#define	HOST_REAL	'2'		// send mbmc realtime data
#define	HOST_CELL	'3'		// send cell data stucture
#define	HOST_HIST	'4'		// send history data structure
#define HOST_SDC0	'5'		// send a SDCARD sector
#define	HOST_CMD_F	'F'		// send FORCEOUT command to ccvoltage controller
#define	HOST_CMD_V	'V'		// send charger toggle command to ccvoltage controller
#define	HOST_CMD_v	'v'		// send charger off command to ccvoltage controller
#define	HOST_CMD_SOC	'*'		// send set SOC command to ccvoltage controller
#define	HOST_CMD_UTC_S	'6'		// start xmit of UTC time to controller
#define	HOST_CMD_UTC_E	'7'		// end xmit of UTC time to controller

#if defined(__18CXX)
#define BCRELAYS	PORTE
#define IORELAYS	PORTJ
#define	DIPSW		PORTD
#define	EXTIO		PORTB
#endif

// SDCARD data format structure using TypeDefs for pic32 host
#if defined(__18CXX)
typedef struct mbmcdata { // C18 uses byte alignment
#else
typedef struct __attribute__((aligned(1))) mbmcdata { // force C32 to byte alignment, 32bit alignment is still critical
#endif
    LONG ccvoltage, inputvoltage, primarypower_B1, primarypower_B2, systemvoltage;
    LONG currentin, current, currentload;
    LONG thermo_batt, cef_boc; // cef*100
    LONG PRIPOWEROK, DIPSW;
    LONG pick, boi, boc, alert, bn;
    LONG CHARGER_B, DIVERSION_B;
    LONG MBMCID, UTC;
    struct harvesttype harvest;
    struct portstype ports;
    struct diversiontype diversion;
    //		LONG			crc;
} volatile mbmctype;

typedef struct mbmcchart {
    struct mbmcdata data[MBMC_CHART_POINTS];
    DWORD sdate, edate, start;
    BYTE pos, gap;
    float avg;
} mbmccharttype;

#if defined(__18CXX)
#else
#endif

typedef struct mbmcflagtype {
    WORD mbmc_cmd, mbmc_data, mbmc_ack;
    WORD host_cmd, host_data, host_ack;
    DWORD cmd_timeout, host_timeout, data_timeout, data_len, data_pos;
    BYTE rx_9bit, tx_9bit, mbmc_done, host_done, *data_ptr;
} volatile mbmcflagtype;

typedef struct mbmcstatustype {
    BYTE seq;
    BYTE real_valid;
    BYTE cell_valid;
    BYTE hist_valid;
    BYTE sdco_valid;
    BYTE cmd_valid;
    DWORD sent;
    DWORD received;
    DWORD cmdsent;
    DWORD cmdreceived;
    DWORD acksent;
    DWORD ackreceived;
} volatile mbmcstatustype;

typedef struct R_data {
    long current, currentin, currentcharger, thermo_batt;
    unsigned long systemvoltage, ccvoltage, inputvoltage, primarypower[POWER_SLOTS];
} volatile R_data;

typedef struct C_data {
    long currentload;
    int temp_drate;
    float t_comp;
} volatile C_data;

typedef struct B_data {
    SHORT start_ahu, cef_raw; // must be int TYPE
    DWORD start_ahi, start_aho; // unsigned long TYPE
    BYTE yesterday, today; // Harvest quality for the whole day, 0..100, uses time of harvest (seconds) -> input power (watts) -> max power (watts).
} volatile B_data; // of each measurement during that period.

#endif /* MBMC_H_INCLUDED */

 

[misterT]

The complexity of this program is not in brute computation

Yes.. and inefficient computation is not a problem because the communication is the bottleneck. And that can not be improved even with ASM (assuming hardware UART).

A little hint for you.
If you are sending and receiving those kind of structures with uart. A union is very efficient way to deal with the 8 bit communication.

If you have a structure:

typedef struct SDCARD {
    WORD magic;
    BYTE sdtype, sdinit, sddetect, DAYCLOCK;
    DWORD sdpos, sdnext, timekeep, time;
    struct harvesttype harvest;
    SHORT h[H2][H9]; // battery history data
} SDCARD_TYPE;

You can create a union:

union SDCARD_UNION
{
unsigned char bytes[sizeof(SDCARD_TYPE)];
SDCARD_TYPE data;
};

Now you can iterate through the data byte by byte:

SDCARD_UNION var;

for(i=0; i<sizeof(SDCARD_TYPE); i++)
{
    write_data(var.bytes[i]);
}

This does not increase memory usage and results in more efficient serial transfer and more readable code.
You can still access the structure members like this: "var.data.time"

 

[Ratchit]

3vo,

Because you have to deal with the processors architecture. The sheer number of lines of code is much greater with ASM. It is more complex. It takes more time to document. It takes longer to modify.

If you are speaking about micros like the PIC, MSP430 and their ilk, whose repertoire of instructions can be counted on your fingers and toes, then the architecture is trivial. It does take a little more time to document, but not that much longer. I don't see why it takes longer to modify. All in all, I think the extra time is a good trade off to get rid of the bloat.

misterT,

But that's what this thread is all about. Comparing two languages. Is it unfair that I can write "result = (double)a * (double)b", when you "have to" write hundred lines ASM. .

Comparing them by what criteria? Availability of subroutines? If I can do that double word multiplicaton by calling a subroutine, then the comparison comes out equal. It is a shame that software developers don't invest in low level libraries instead of buying a HL compilier.

You are going to get a better product if the programmer is always thinking about the registers, stack, and memory. Using a HLL shields the programmer from those details, thereby making the programmer into a coder and promoting zombiism.

Ratch

 

[Ratchit]

nasaspook,

Looking over your header, I see definitions of variables, structures, and names. All that is available with a good assembler. The syntax of the header file would look a little different, but it would be just as clear. So I don't see how that example shows any superiority of a HL over Assembler.

Ratch

 

[nsaspook]

Yes.. and inefficient computation is not a problem because the communication is the bottleneck. And that can not be improved even with ASM (assuming hardware UART).


Now you can iterate through the data byte by byte:

SDCARD_UNION var;

for(i=0; i<sizeof(SDCARD_TYPE); i++)
{
    write_data(var.bytes[i]);
}

This does not increase memory usage and results in more efficient serial transfer and more readable code.
You can still access the structure members like this: "var.data.time"

I can't block the process with a loop so a state machine with a BYTE data pointer (a cheat), data position and length are used.

PIC18
...
	    mbmcflag.data_pos = 0; // reset the data position counter
	    mbmcflag.data_ptr = (BYTE*) & MBMC; // default data
	    mbmcflag.data_len = 1; // default len
...	    
            if (mbmcflag.mbmc_cmd == HOST_CELL) {
		mbmcflag.data_ptr = (BYTE*) & cell;
		mbmcflag.data_len = sizeof (cell);
	    }
....
	TXSTA1bits.TX9D = LOW; // clear bit 9 for data
	P1wait();
	TXREG1 = *mbmcflag.data_ptr; // send data
	mbmcdata_count++;
	P1wait();
	mbmcflag.data_pos++; // move the data pointer
	if (mbmcflag.data_pos >= mbmcflag.data_len) { // buffer has been sent
	    TXSTA1bits.TX9D = HIGH; // set bit 9 for command
	    P1wait();
	    TXREG1 = HOST_ACK; // send ack
	    mbmcdata_count++;
	    P1wait();
	    TXSTA1bits.TX9D = LOW;
	    mbmcflag.cmd_timeout = FALSE; // there is another system
	    mbmcflag.mbmc_cmd = HOST_REQ; // set to default cmd
	    HOST_COMM = FALSE; // clear the transmit flag
	    HOST_BUSY = FALSE; // clear the command flag
	} else {
	    mbmcflag.data_ptr++; // move the buffer pointer position
	}

PIC32 usart ISR
// UART 2 interrupt handler
// it is set at priority level 2

void __ISR(_UART2_VECTOR, ipl2) IntUart2Handler(void) {
    static WORD rx9data;
    // Is this an RX interrupt?
    if (INTGetFlag(INT_SOURCE_UART_RX(UART2))) {
        rx9data = ReadUART2();
        mbmc_status.received++;

        if ((rx9data & MASK9BIT) != 0) { // check for bit 9
            mbmcflag.rx_9bit = TRUE; // set command  flag
            mbmc_status.cmdreceived++;
        } else {
            mPORTDToggleBits(BIT_2); // data LED
            mbmcflag.data_timeout = 0; // reset timer
            mbmcflag.rx_9bit = FALSE; // clear command flag

            if (!mbmcflag.mbmc_done) { // we need more data
                mbmcflag.data_ptr[mbmcflag.data_pos] = (BYTE) rx9data; // move received data into buffer
                if (mbmcflag.data_pos++ >= mbmcflag.data_len) { // the data buffer is filled to data_len
                    mbmcflag.mbmc_done = TRUE; // data block has been received
                    // set a place keeper buffer
                    mbmcflag.data_ptr = (BYTE*) & dd.data_default;
                    mbmcflag.data_len = 4;
                    mbmcflag.data_pos = 0;
                } else { // nothing for now
                }
            }

        }

        if (mbmcflag.rx_9bit) {
            if (rx9data == mbmcflag.host_ack) {
                mbmc_status.ackreceived++;
                mPORTDToggleBits(BIT_1); // command LED
                mbmcflag.host_done = TRUE;
                mbmcflag.data_timeout = 0; // reset timer
            }
        }
        // Clear the RX interrupt Flag
        INTClearFlag(INT_SOURCE_UART_RX(UART2));

    }

    // We don't care about TX interrupt
    if (INTGetFlag(INT_SOURCE_UART_TX(UART2))) {
        INTClearFlag(INT_SOURCE_UART_TX(UART2));
    }
}

...

 

[nsaspook]

nasaspook,

Look over your header, I see definitions of variables, structures, and names. All that is available with a good assembler. The syntax of the header file would look a little different, but it would be just as clear. So I don't see how that example shows any superiority of a HL over Assembler.

Ratch

You're missing the point. It's how portable it is to another 8<->32 bit machine using the same source code header. I can change that one file that both compilers use to define data objects on completely different machine architectures.

 

[Ratchit]

nsaspook,

You're missing the point. It's how portable it is to another 8<->32 bit machine using the same source code header. I can change that one file that both compilers use to define data objects on completely different machine architectures.

I have always acknowledged that one big virtue of HL is its portability. If that were Assembler, some time would have to be spent on translating the program for a different machine.

Ratch

 

[jlpelect5]

misterT,
I agree with you 100% if you are programming a processer because that it what it is, just a processor unlike a microcontroller that has built in hardware functions like timer counters, adc, pwm, eeprom, spi and many other features that are built in mainly for hmi (human machine interface).

So now you are getting into the difference of a micro-processor and a micro-controller which are two different animals.
You are also comparing industry (work already in process) with new guys getting into programming.

Take a look at the program that I posted earlier for a functioning external interrupt, after the setup, it only took 11 lines of code, a far cry from "hundred lines of code". You have a set-up process for all microprocessors and microcontrollers before you even start programming.

Again, multiplying two numbers will not result in writing hundreds of lines of code. It is a simple loop!

jlpelect5

 

[3v0]

You can program in any language you like. But unless you are skilled/fluent in multiple languages you are not equipped to be telling others what language to use or even make the sort of comparisons we are making in this thread.

To some extent it is pointless in even talking about this in that most often we do not have language choice.

If you are speaking about micros like the PIC, MSP430 and their ilk, whose repertoire of instructions can be counted on your fingers and toes, then the architecture is trivial. It does take a little more time to document, but not that much longer. I don't see why it takes longer to modify. All in all, I think the extra time is a good trade off to get rid of the bloat.

The instruction set may be 'trivial' but using it to write code is cumbersome A processor with a small instruction set results in a larger machine code program regardless of the language used. In a HLL we are insulated from this, with ASM we have to code the program using the small instruction set and it is more work. It takes longer. I would much rather write ASM for a PDP11 then a PIC.

An ASM program takes longer to modify for the same reason it took longer to write it. Now there are cases where ASM programmers have written some very nice libs and can crank out code. But their system is unique to them and anyone else having to understand it is at a huge disadvantage. HLL's like C reduce the learning curve when looking at other peoples code.

 

[misterT]

misterT,
I agree with you 100% if you are programming a processer because that it what it is, just a processor unlike a microcontroller that has built in hardware functions like timer counters, adc, pwm, eeprom, spi and many other features that are built in mainly for hmi (human machine interface).

So now you are getting into the difference of a micro-processor and a micro-controller which are two different animals.
You are also comparing industry (work already in process) with new guys getting into programming.

Take a look at the program that I posted earlier for a functioning external interrupt, after the setup, it only took 11 lines of code, a far cry from "hundred lines of code". You have a set-up process for all microprocessors and microcontrollers before you even start programming.

I have been talking about microcontroller world 99% of the time. If microcontrollers didn't have build in hardware peripherals, I would probably program only with ASM. But, because modern microcontrollers have these efficient peripherals, I can tolerate an inefficient initialization code.. because I have to do it only once!

My point with with the "multiplication of two double numbers" wast that I can try it out and test it very easily if I want. Takes me under five minutes to see how efficient it is. I know it is most of the time crazy to use double precision floats, but at least I can evaluate it with no effort. Would you spend whole week coding the same routine with ASM just out of curiosity?

Again, multiplying two numbers will not result in writing hundreds of lines of code. It is a simple loop!

That method is about 50% slower than straight line code. And while the machine code is some ~40 instructions, you would need to write couple of hundred lines documented code.