Forum

Forum

Robbert Haarman

2020-11-28

Posted by inglorion
at 2020-10-26 17:48:24

I have a monitor that does not work 100% reliably in the highest resolution it claims to support. I'm happy to use a somewhat lower resolution, but it wasn't immediately clear to me how to do this in the modern world where X.org does not need a configuration file anymore. Surely there is a way to set this without also having to specify the driver to use and the timings? Turns out, there is:


Section "Screen"
   Identifier "screen0"
   SubSection "Display"
      Modes   "1920x1080"
   EndSubSection
EndSection

  • View this thread (0 comments)
Posted by inglorion
at 2019-05-26 05:04:10

Several years ago, I came up with the deadbeef random number generator - so named because it uses the constant 0xdeadbeef. It gained some popularity with people programming for 8-bit systems like AVR microcontrollers. Now that I have some experience programming for 8-bit CPUs like AVRs and the 6502, I decided to design a pseudorandom number generator specifically for those systems. The result is Micrornd.

Micrornd is not based on the deadbeef random number generator, but a comparison between the two may still be instructive. Deadbeef operates on 32-bit quantities and shifts bits 7 or 25 positions. This would require many instructions on a 6502 or AVR, so Micrornd instead performs simple 8-bit operations and a single bit shift. This makes Micrornd quite a bit smaller and faster than deadbeef_rand would be on these systems.

  • View this thread (0 comments)
Posted by inglorion
at 2019-02-07 06:35:08

I have designed and built an 8-bit microcomputer similar to those of the late 1970s. The project now has a website with source code and instructions for building the computer: homemicro.net.

  • View this thread (0 comments)
Posted by inglorion
at 2016-10-12 15:24:08

Lego, Raspberry Pi, and Arduino? I think this project wins the Internet. Built by Cory Guynn, this is a city built from Lego, automated and animated using Arduino and Raspberry Pi. The Getting Started post describes how it was built, and the Facebook page has a lot more posts and information.

  • View this thread (0 comments)
Posted by inglorion
at 2016-10-07 16:00:09

Checking in files that relate to your specific development environment along with the source code of the project is often harmful. A common example of this are files generated by an IDE, especially if that IDE has a habit of changing those files in ways that have nothing to do with the project. However, it also applies to configurations that are specific to your organization for projects that are worked on in multiple organizations (e.g. open source projects). The corollary to this is that your tools should not require that their configuration files be checked into the same repository as the source code.

  • View this thread (0 comments)
Posted by inglorion
at 2016-10-07 15:57:57

Have an Android phone? Try saying "Ok Google. What do you get when you multiply 6 by 9?"

  • View this thread (0 comments)
Posted by inglorion
at 2016-01-06 17:56:48

DataDraw looks very interesting. It claims to be so fast that it even beats native C data structures, and it can be both in-memory and persisted to disk. I have been meaning to experiment with it, but haven't gotten around to it yet.

  • View this thread (0 comments)
Posted by inglorion
at 2015-09-09 20:24:17

Crystal is a programming language with syntax and expressiveness inspired by Ruby, but with static typing, macros, and an implementation that compiles programs to native code. Types are automatically inferred, so code can be written without type annotations, although annotations can be added to restrict the types accepted by methods or to implement ad-hoc polymorphism. Macros allow a fixed subset of the language to be used to transform source code, allowing metaprogramming without run-time overhead. Ruby programs can often be transformed to Crystal programs with small modifications.

There is a self-hosting implementation of Crystal, using LLVM to generate native code. An foreign function interface is available to allow Crystal code to call C code and vice versa.

  • View this thread (0 comments)
Posted by inglorion
at 2014-11-10 02:28:17

I just released version 1.1.4 of the Voodoo Compiler. This is a maintenance release, and contains the following bug fixes and improvements:

- References to symbols are now always position-independent, even if the symbol is not exported or imported. This means shared libraries can now have symbols that are not externally visible.

- On AMD64, tail-call now restores all callee-save registers in the active frame to their saved values before transferring control to the function being called. Before this fix, calling code generated by the Voodoo compiler from code generated by a different compiler would, under certain circumstances, cause callee-save registers to have wrong values upon return to the code from the other compiler.

- On AMD64, rbx is now a callee-save register, as required by the ABI.

- More rigorous tests for expressions have been added. These exposed some bugs in the generated code on AMD64, which have been fixed.

- The ARM code generator now emits constant pools as necessary to keep them within limited distance from the code that uses them. Previously, constant pools were only emitted at the end of blocks, which could cause the offset between a constant and an instruction that uses that constant to be larger than what can be encoded in the instruction.

  • View this thread (1 comments)
Posted by inglorion
at 2014-10-28 12:51:23

As on other architectures, position-independent code for MIPS on GNU/Linux is accomplished with the help of a global offset table. This table contains the addresses of symbols used by the code. Instead of using the address of a symbol directly, as one would in non-position-independent code, a reference to a symbol is resolved by looking up the symbol's entry in the global offset table and then using the address stored there. Of course, we still need to find the address of the global offset table (abbreviated GOT).

On Mips on GNU/Linux, functions are passed the address of their entry point in register $25. The global offset table is at a fixed offset to this. By convention, $28 is used to hold the address of the GOT. The correct value can be computed as follows:


lui $28, %hi(_gp_disp)
addiu $28, %lo(_gp_disp)
addu $28, $28, $25

This is what the GNU assembler's .cpload $25 pseudo-op expands to.

Once you have the address of the global offset table in $28, you can get the address of a symbol that your object imports or exports by doing something like


lw $2, %got(foo)($28)

where foo is the name of your symbol. This would store the address foo is at in register $2, assuming $28 holds the address of the GOT.

However, for symbols that are defined in your object but not exported, the situation is slightly different. For such symbols, you need to also add the %lo of your symbol's address to the address you get from the GOT. So, for symbols that aren't imported or exported, but defined in the same object as your code, the position-independent way to get the address of the symbol is


lw $2, %got(foo)($28)
addiu $2, %lo(foo)

  • View this thread (0 comments)

View 10 earlier threads

Valid XHTML 1.1! Valid CSS! Viewable with Any Browser