Click here to Skip to main content
13,627,551 members

Welcome to the Lounge

   

For discussing anything related to a software developer's life. Technical discussions are encouraged, but click here to ask your programming questions.

The Lounge is rated PG. If you're about to post something you wouldn't want your kid sister to read then don't post it. No flame wars, no abusive conduct, no programming questions and please don't post ads.
 
GeneralRe: Hello everyone Pin
CodeWraith12-Jul-18 21:39
memberCodeWraith12-Jul-18 21:39 
GeneralRe: Hello everyone Pin
Rage12-Jul-18 22:29
professionalRage12-Jul-18 22:29 
GeneralRe: Hello everyone Pin
OriginalGriff13-Jul-18 3:57
protectorOriginalGriff13-Jul-18 3:57 
GeneralRe: Hello everyone Pin
CodeWraith12-Jul-18 21:31
memberCodeWraith12-Jul-18 21:31 
GeneralRe: Hello everyone Pin
‭011111100010‬13-Jul-18 1:41
professional‭011111100010‬13-Jul-18 1:41 
GeneralRe: Hello everyone Pin
Rage13-Jul-18 3:01
professionalRage13-Jul-18 3:01 
GeneralRe: Hello everyone Pin
KennethKennedy12-Jul-18 22:25
memberKennethKennedy12-Jul-18 22:25 
GeneralDoes This Carbon Unit Thinks Like A Silicon Unit? Pin
David A. Gray12-Jul-18 10:10
memberDavid A. Gray12-Jul-18 10:10 
Over the last year or so, I have enjoyed many of the articles that came my way courtesy of the X-Team weekly newsletter. This week's newsletter brought JavaScript Essentials: Why You Should Know How the Engine Works, which included a demonstration to drive home some great points about how modern JavaScript engines work, and how they can work against you unless your design takes into account how the engine that runs your carefully crafted code works.

As I read the article, I noticed that the example is something that I know intuitively is suboptimal. The article explained exactly what made it suboptimal, which confirmed the my intuitive suspicion. This caused me to realize how many times that such intuitive understanding has kept me away from many suboptimal design choices throughout my career. Though I don't often write in Assembly Language, apparently, my understanding of the machine is such that it helps me steer clear of many inefficient patterns without much conscious effort.

A long time ago, when I was in graduate school, I had the opportunity to work with an electrical engineer who was working on his master's degree, from whom I learned a great deal about how the CPU on the Sperry Univac 1100 that we used at The University of Alabama worked, and how to take advantage of that knowledge to write high performance code. Though we did most of our production work in Fortran, he encouraged me to learn Assembler, which I did, and I put that knowledge to use in the work that I did for the Center for Business and Economic Research.

Since then, I have made some effort to learn and use the assembler for almost every computer for which I have developed software. Indeed, the first job I had following graduate school was at a company whose programs, which ran on a Burroughs B-4700 mainframe, were written entirely in its assembly language. Since then, the only significant exception was the IBM System/34, for which I didn't have access to an assembler. That exposure to the assembler has paid dividends on every platform by enabling me to solve problems that would almost certainly have otherwise eluded me.

Though I prefer to use the highest level programming language that can express the solution of the problem at hand, there are countless times when my grasp of the underlying machine code that comes from learning the assembler for a CPU has enabled me to solve a problem quickly on my own, without having to wait for a specialist to find time to work with me on the problem.

To this day, I often find myself running the debugger in the Disassembly view, when the source view would almost certainly suffice. When I can get away with it, I stay there, even if I mostly hit F10 or F11 to execute the next instruction or function call, because I learn something useful from so many of these sessions.

For example, just this week, I needed to solve a problem that arose when I rewrote one of the first ANSI C functions that I ever wrote from scratch to make it thread-safe. That routine uses another of my early ANSI C functions that emulates the stream I/O routines in the standard C runtime library by treating blocks of memory as if they were file streams. Since the change caused that memory stream routine to return an error, I traced into it. Tracing in disassembly view, I noticed something in the calling routine that initially startled me; immediately after the stream I/O open routine returned, it copied the contents of the emulated FILE structure from the location in the stream I/O routine's address space into the address space of the calling routine, to populate the emulated FILE structure that was defined therein, and occupied memory within its address space.

Taking a closer look at the stream open routine, I noticed that its return type was FILE (actually emulated FILE), the structure, itself, rather than a pointer to it. I had forgotten that such an operation was even legal, but I was dismayed by how and why it works. Before I called the library update done, I rewrote that module, which I developed for that library, so that the opener allocates memory to store the structure from the default process heap, and returns a pointer to that memory. In the new version of the module, the other routines take an opaque pointer to the structure, and the close routine disposes of the memory that was allocated from the heap. The new routine is a more faithful emulation of the CRT routine whose interface it copied, and the inefficient memory copy is gone from the routines that use it. The new library, with its thread-safe routines, will soon find its way into a new GitHub repository.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting

GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
Nelek12-Jul-18 20:31
protectorNelek12-Jul-18 20:31 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
CodeWraith12-Jul-18 22:23
memberCodeWraith12-Jul-18 22:23 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
Nelek12-Jul-18 22:30
protectorNelek12-Jul-18 22:30 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
David A. Gray13-Jul-18 6:54
memberDavid A. Gray13-Jul-18 6:54 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
BillWoodruff13-Jul-18 3:10
mentorBillWoodruff13-Jul-18 3:10 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
David A. Gray13-Jul-18 6:28
memberDavid A. Gray13-Jul-18 6:28 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
BillWoodruff13-Jul-18 9:12
mentorBillWoodruff13-Jul-18 9:12 
GeneralRe: Does This Carbon Unit Thinks Like A Silicon Unit? Pin
David A. Gray13-Jul-18 9:14
memberDavid A. Gray13-Jul-18 9:14 
GeneralWoz's quote about Jobs' failure Pin
raddevus12-Jul-18 9:31
mvpraddevus12-Jul-18 9:31 
GeneralRe: Woz's quote about Jobs' failure Pin
Mike Mullikin12-Jul-18 9:49
memberMike Mullikin12-Jul-18 9:49 
GeneralRe: Woz's quote about Jobs' failure Pin
Rick York12-Jul-18 9:54
memberRick York12-Jul-18 9:54 
GeneralRe: Woz's quote about Jobs' failure Pin
‭011111100010‬12-Jul-18 10:27
professional‭011111100010‬12-Jul-18 10:27 
GeneralRe: Woz's quote about Jobs' failure Pin
raddevus12-Jul-18 10:30
mvpraddevus12-Jul-18 10:30 
GeneralRe: Woz's quote about Jobs' failure Pin
Mike Mullikin12-Jul-18 10:44
memberMike Mullikin12-Jul-18 10:44 
GeneralRe: Woz's quote about Jobs' failure Pin
raddevus12-Jul-18 11:48
mvpraddevus12-Jul-18 11:48 
GeneralRe: Woz's quote about Jobs' failure Pin
raddevus12-Jul-18 12:07
mvpraddevus12-Jul-18 12:07 
GeneralRe: Woz's quote about Jobs' failure Pin
pwasser12-Jul-18 13:48
memberpwasser12-Jul-18 13:48 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.


Advertise | Privacy | Cookies | Terms of Service
Web01 | 2.8.180712.1 | Last Updated 17 Jul 2018
Copyright © CodeProject, 1999-2018
All Rights Reserved.
Layout: fixed | fluid