Hello !
Trace: • Energy Efficient Programming • AVR Mikrocontroller • Vectorisation • Advanced Assembly Programming • Addressing Modes in Instructions • ToDo • Robootika Kodulabori võrgustik ja tugikeskkond • Authors • Modern Processors: Pipeline, Superscalar, Branch Prediction, Hyperthreading • DC motor

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:multiasm:papc:chapter_6_9 [2025/06/14 07:33] – pczekalskien:multiasm:papc:chapter_6_9 [2025/06/14 19:20] (current) – [Programming in Assembler for Windows] pczekalski
Line 6: Line 6:
 Windows OS historically supports unmanaged code, written primarily in C++. This kind of code runs directly on the CPU. Since the introduction of the .NET framework, Windows has provided developers with a safer way of executing their code, called "managed code". The difference is that managed code, written commonly in C#, is executed by a .NET framework interpreter rather than being compiled to machine code, as unmanaged code is. The use of managed code brings multiple advantages for developers, including automated memory management and code isolation from the operating system. This, however, raises several challenges when integrating managed code and assembly code. Windows OS historically supports unmanaged code, written primarily in C++. This kind of code runs directly on the CPU. Since the introduction of the .NET framework, Windows has provided developers with a safer way of executing their code, called "managed code". The difference is that managed code, written commonly in C#, is executed by a .NET framework interpreter rather than being compiled to machine code, as unmanaged code is. The use of managed code brings multiple advantages for developers, including automated memory management and code isolation from the operating system. This, however, raises several challenges when integrating managed code and assembly code.
  
 +<note tip>Code written in assembler and compiled to machine code is always unmanaged one!</note>
 +
 +<todo pczekalski>Continue here</todo>
 +
 +**Programming for applications written in unmanaged code**
 +
 +
 +**Programming for applications written in managed code**
 +In the case of managed code, things get more complex. The .NET framework features automated memory management, a mechanism that automatically releases unused memory (e.g., objects for which there are no more references) and optimises the location of variables for improved performance. It is known as a .NET Garbage Collector (GC). GC instantly traces references and, in the event of an object relocation in memory, updates all references accordingly. It also releases objects that are no longer referenced. This automated mechanism, however, applies only across managed code apps. The problem arises when developers integrate a front-end application written in managed code with assembler libraries written in unmanaged code. All pointers and references passed to the assembler code are not automatically traced by the GC. Using dynamically allocated variables on the .NET side and accessing them from the assembler code is a very common scenario. GC cannot "see" any reference to the object (variable, memory) made in the unmanaged code; thus, it may release memory or relocate it without updating the reference address. It causes very hard-to-debug errors that occur randomly and are very serious (e.g. null pointer exception).
 +Luckily, there is a strict set of rules that must be followed when integrating managed and unmanaged code. We discuss it below.
  
  
 ===== Programming in Assembler for Linux ===== ===== Programming in Assembler for Linux =====
en/multiasm/papc/chapter_6_9.1749886399.txt.gz · Last modified: 2025/06/14 07:33 by pczekalski
CC Attribution-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0