# IA-32

Published articles for IA-32.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Red/System: New Features

DevFeed: [Red/System: New Features](<https://devfeed.tech/articles/red-system-new-features-22378.md>)

Original publisher: [Read original article](<https://www.red-lang.org/2020/08/redsystem-new-features.html>)

Author: Nenad Rakocevic (noreply@blogger.com)

Published: 2020-08-20T10:54:00Z

Content type: release

Language: en

Sources: [Red](<https://devfeed.tech/sources/red.md>)

Topics: [Red](<https://devfeed.tech/topics/red.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [arrays](<https://devfeed.tech/tags/arrays.md>), [atomic](<https://devfeed.tech/tags/atomic.md>), [bugfixes](<https://devfeed.tech/tags/bugfixes.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [features](<https://devfeed.tech/tags/features.md>), [floating-point](<https://devfeed.tech/tags/floating-point.md>), [fpu](<https://devfeed.tech/tags/fpu.md>), [ia-32](<https://devfeed.tech/tags/ia-32.md>), [literal-arrays](<https://devfeed.tech/tags/literal-arrays.md>), [math](<https://devfeed.tech/tags/math.md>), [new-features](<https://devfeed.tech/tags/new-features.md>), [pointers](<https://devfeed.tech/tags/pointers.md>), [red-system](<https://devfeed.tech/tags/red-system.md>), [runtime-errors](<https://devfeed.tech/tags/runtime-errors.md>), [vfp](<https://devfeed.tech/tags/vfp.md>)

### AI overview

An overview of recent Red/System features, including subroutines, atomic and stack intrinsics, FPU status access, and changes to literal arrays.

### Source excerpt

In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to solve that. They act as the GOSUB directive from Basic language. They are defined as a separate block of code inside a function's body and are called like regular functions (but without any arguments). So they are much lighter and faster than real function calls and require just one slot of stack space to store the return address. The declaration syntax is straightforward: <name>: [<body>] <name> : subroutine's name (local variable). <body> : subroutine's code (regular R/S code). To define a subroutine, you need to declare a local variable with the subroutine! datatype, then set that variable to a block of code. You can then invoke the subroutine by calling its name from anywhere in the function body (but after the subroutine own definition). Here is a first example of a fictive function processing I/O events: process: func [buf [byte-ptr!] event [integer!] return: [integer!] /local log do-error [subroutine!] ][ log: [print-line [">>" tab e "<<"]] do-error: [print-line ["** Error:" e] return 1] switch event [ EVT_OPEN [e: "OPEN" log unless connect buf [do-error]] EVT_READ [e: "READ" log unless receive buf [do-error]] EVT_WRITE [e: "WRITE" log unless send buf [do-error]] EVT_CLOSE [e: "CLOSE" log unless close buf [do-error]] default [e: "<unknown>" do-error] ] 0 ] This second example is more complete. It shows how subroutines can be combined and how values can be returned from a subroutine: #enum modes! [ CONV_UPPER CONV_LOWER CONV_INVERT ] convert: func [mode [modes!] text [c-string!] return: [c-string!] /local lower? upper? alpha? do-conv [subroutine!] delta [integer!] s [c-string!] c [byte!] ][ lower?: [all [#"a" <= c c <= #

## LLVM Weekly - #56, Jan 26th 2015

DevFeed: [LLVM Weekly - #56, Jan 26th 2015](<https://devfeed.tech/articles/llvm-weekly-56-jan-26th-2015-42955.md>)

Original publisher: [Read original article](<https://blog.llvm.org/2015/01/llvm-weekly-56-jan-26th-2015.html>)

Author: Alex Bradbury

Published: 2015-01-26T06:56:00Z

Content type: news

Language: en

Sources: [LLVM Project](<https://devfeed.tech/sources/the-llvm-project-blog.md>)

Topics: [LLVM](<https://devfeed.tech/topics/llvm.md>), [clang](<https://devfeed.tech/topics/clang.md>), [Cross-Compilation](<https://devfeed.tech/topics/cross-compilation.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [debugging](<https://devfeed.tech/topics/debugging.md>), [Numba](<https://devfeed.tech/topics/numba.md>), [Python](<https://devfeed.tech/topics/python.md>), [Open Source](<https://devfeed.tech/topics/open-source.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [IRC](<https://devfeed.tech/topics/irc.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [avx](<https://devfeed.tech/tags/avx.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [c](<https://devfeed.tech/tags/c.md>), [clang](<https://devfeed.tech/tags/clang.md>), [compilation](<https://devfeed.tech/tags/compilation.md>), [cross-compilation](<https://devfeed.tech/tags/cross-compilation.md>), [debug](<https://devfeed.tech/tags/debug.md>), [features](<https://devfeed.tech/tags/features.md>), [ia-32](<https://devfeed.tech/tags/ia-32.md>), [irc](<https://devfeed.tech/tags/irc.md>), [lldb](<https://devfeed.tech/tags/lldb.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [llvmweekly](<https://devfeed.tech/tags/llvmweekly.md>), [news](<https://devfeed.tech/tags/news.md>), [numba](<https://devfeed.tech/tags/numba.md>), [python](<https://devfeed.tech/tags/python.md>), [system](<https://devfeed.tech/tags/system.md>), [weekly](<https://devfeed.tech/tags/weekly.md>)

### AI overview

The 56th LLVM Weekly issue rounds up developments across LLVM and related projects, including tutorials on LLVM specialization for Python and the LLVM C API, LLDB support for Windows, an IA-32 processor ABI draft, LLVM/Clang 3.6-rc1, and the ELLCC cross-compilation toolchain.

### Source excerpt

Welcome to the fifty-sixth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by Alex Bradbury. Subscribe to future issues at http://llvmweekly.org and pass it on to anyone else you think may be interested. Please send any tips or feedback to asb@asbradbury.org, or or @llvmweekly or @asbradbury on Twitter. I'll be talking the lowRISC project to produce a fully open-source SoC at FOSDEM this coming weekend. Do come and see my main track talk and read my speaker interview for more background. There is of course an LLVM toolchain devroomon the Sunday. The canonical home for this issue can be found here at llvmweekly.org. News and articles from around the web Stephen Diehl has written an absolutely fantastic tutorial on writing an LLVM specializer for Python, guiding you through the process of creating something like Numba. A new tool, Dwgrep (DWARF Grep) may be of interest to many LLVM Weekly readers. This blog post gives an intro to using it. Paul Smith has a blog post on getting started with the LLVM C API. A post on the official LLVM Blog announces that LLDB is coming to Windows, announcing to a wider audience that it is now possible to debug simple programs with LLDB on Windows and giving a rationale for investing effort into porting LLDB to Windows and adding support for the MS debug format. The post also features a todo list indicating what's next for Windows support. A draft version 0.1 of the IA-32 psABI (processor specific application binary interface) is available. This aims to supplement the existing System V ABI with conventions relevant to newer features such as SSE1-4 and AVX. Comments are welcome. LLVM/Clang 3.6-rc1 is now available. Get testing and filing bugs. ELLCC 0.1.8 has been released. ELLCC is an LLVM/Clang-based cross compilation toolchain. LLDB now has it's own IRC channel. You'll want to join #lldb on irc.oftc.net. On the mailing lists Cha

## Restricted Transactional Memory on Haswell

DevFeed: [Restricted Transactional Memory on Haswell](<https://devfeed.tech/articles/restricted-transactional-memory-on-haswell-12451.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2013/12/16/intel-rtm.html>)

Author: Marc Brooker

Published: 2013-12-16T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's](<https://devfeed.tech/sources/marc-brooker-s-blog.md>)

Topics: [strict-serializability](<https://devfeed.tech/topics/strict-serializability.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [synchronization](<https://devfeed.tech/topics/synchronization.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [bugs](<https://devfeed.tech/tags/bugs.md>), [builtins](<https://devfeed.tech/tags/builtins.md>), [clojure](<https://devfeed.tech/tags/clojure.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [ia-32](<https://devfeed.tech/tags/ia-32.md>), [intel](<https://devfeed.tech/tags/intel.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [languages](<https://devfeed.tech/tags/languages.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [memory](<https://devfeed.tech/tags/memory.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [performance](<https://devfeed.tech/tags/performance.md>), [processor](<https://devfeed.tech/tags/processor.md>), [programming](<https://devfeed.tech/tags/programming.md>), [serialization](<https://devfeed.tech/tags/serialization.md>), [software](<https://devfeed.tech/tags/software.md>)

### AI overview

On the tested Haswell hash table, Restricted Transactional Memory (RTM) was marginally slower than a spinlock with one thread but faster with multiple threads, taking 63% of the spinlock's time at two threads. RTM tries a lock-protected critical section transactionally when the lock is free, then aborts and falls back to the spinlock if the lock is held or a conflict occurs. The author tested one million random insertions into a 100,000-bucket separately chained table, with tail insertion to increase work; each test ran 100 times with under 5% variance. Compared with the baseline spinlock, which slowed under contention, RTM improved performance across the tested thread counts and remained faster than single-threaded through four threads. HLE was 18% slower with one thread but had a larger advantage through eight threads and prevented slowdown; the author notes its speedup plateaued beyond three threads. These results are specific to this benchmark, and the article says it remains unclear when each feature is best used.

### Source excerpt

Restricted Transactional Memory on Haswell Exploring the performance of Intel's RTM In my last post, I looked at the performance of HLE on Intel's Haswell processor, and found that while it offered a nice speedup in some cases, it can cost performance in others. Still, Intel's TSX is an extremely exciting technology. In this post, I look at the other half of TSX, which Intel calls Restricted Transactional Memory. If you've never heard of transactional memory before, it's worth reading up. As usual, the Wikipedia article isn't a bad place to start. Some languages, like Clojure, offer software transactional memory out of the box. When it fits, STM can be an extremely nice way to write concurrent programs. The programming model can be simpler, and some classes of bugs (correctness, mostly, rather than liveness) are easier to avoid. Unlike all the great STM libraries, the current interfaces available to RTM, at least in the form of compiler builtins, don't offer much in the way of a simpler programming model. They do, however, offer us a great way to taste some of the performance benefits that Intel promises for RTM. First, let's take a look at what Intel says about RTM. Starting with the Intel® 64 and IA-32 Architectures Optimization Reference Manual: Intel® Transactional Synchronization Extensions (Intel TSX) aim to improve the performance of lock-protected critical sections while maintaining the lock-based programming model OK, so a simpler programming model isn't really Intel's aim here. I'm still pretty sure that there are great opportunities for TM libraries, some of which are already starting to appear, like xsync. Some more from the manual: Intel TSX allows the processor to determine dynamically whether threads need to serialize through lock-protected critical sections, and to perform serialization only when required. This lets hardware expose and exploit concurrency hidden in an application due to dynamically unnecessary synchronization through a technique know

## Are volatile reads really free?

DevFeed: [Are volatile reads really free?](<https://devfeed.tech/articles/are-volatile-reads-really-free-12444.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2012/09/10/volatile.html>)

Author: Marc Brooker

Published: 2012-09-10T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's](<https://devfeed.tech/sources/marc-brooker-s-blog.md>)

Topics: [x86](<https://devfeed.tech/topics/x86.md>)

Tags: [1-6](<https://devfeed.tech/tags/1-6.md>), [assembly](<https://devfeed.tech/tags/assembly.md>), [atomic](<https://devfeed.tech/tags/atomic.md>), [c](<https://devfeed.tech/tags/c.md>), [cache](<https://devfeed.tech/tags/cache.md>), [coherency](<https://devfeed.tech/tags/coherency.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [experiment](<https://devfeed.tech/tags/experiment.md>), [ia-32](<https://devfeed.tech/tags/ia-32.md>), [java](<https://devfeed.tech/tags/java.md>), [load](<https://devfeed.tech/tags/load.md>), [overhead](<https://devfeed.tech/tags/overhead.md>), [store](<https://devfeed.tech/tags/store.md>), [variables](<https://devfeed.tech/tags/variables.md>), [x86](<https://devfeed.tech/tags/x86.md>)

### AI overview

The excerpt shows that volatile reads in Java on x86 are not necessarily free. In the tested JRE 1.6 setup, generated assembly for a volatile read looked the same as for a normal read, but a benchmark found volatile reads about 25 times slower when another thread was writing, with substantial run-to-run variation. The account attributes this to multicore memory access and cache coherence enforcing visibility, effects not apparent from instruction count alone. It also reports that volatile writes were nearly 100 times more expensive than normal writes. In a separate example, volatile access constrained compiler optimization: the non-volatile loop was unrolled and kept values in registers, while the volatile version did more work per step and was less aggressively unrolled. These measurements describe the tested setup, not a universal performance ratio.

### Source excerpt

Are volatile reads really free? Some claim that reads from volatile variables are free in Java on x86. Is that claim true? There is a somewhat common belief among Java programmers that reads from volatile variables are free. Are volatile variable 'reads' as fast as normal reads? from StackOverflow is a perfect example, because it's the top result I get from Google for most related searches. The top answer says: On an x86, there is no additional overhead associated with volatile reads. and goes on to say: JSR-133 classifies four barriers "LoadLoad, LoadStore, StoreLoad, and StoreStore". Depending on the architecture, some of these barriers correspond to a "no-op", meaning no action is taken, others require a fence. There is no implicit cost associated with the Load itself, though one may be incurred if a fence is in place. In the case of the x86, only a StoreLoad barrier results in a fence. Reading Doug Lea's The JSR-133 Cookbook for Compiler Writers gives the same impression. It says: Issue a StoreStore barrier before each volatile store. and Issue a StoreLoad barrier after each volatile store. Note that you could instead issue one before each volatile load, but this would be slower for typical programs using volatiles in which reads greatly outnumber writes. Alternatively, if available, you can implement volatile store as an atomic instruction (for example XCHG on x86) and omit the barrier. This may be more efficient if atomic instructions are cheaper than StoreLoad barriers. and Issue LoadLoad and LoadStore barriers after each volatile load. Doug lists the StoreStore, LoadLoad and LoadStore barriers as noops on x86. It makes some sense to read this as a validation of the idea that volatile reads are free. No extra instructions are issued for the reads, and instructions are what makes computers take time, so no more time is taken. Right? The first step to answering that question is seeing if the Java JRE 1.6 actually behaves like Doug says it should. Possibly the e