News:

Download Pelles C here: http://www.pellesc.se

Main Menu

Recent posts

#11
Projects developed with Pelles C / Re: JMP: Jerbil Machine Progra...
Last post by TimoVJL - July 31, 2026, 09:42:41 PM
A good thing, that you see Pelles c useful for you.

A Watcom compiler project halted, as it lost all developers some time ago.

This site don't like any marketing purboses, so avoid them.
#12
Here is a picture of two plastic parts that I made from a mold created using JMP and a CNC mini mill. They are called OptiBurger Patty Molds. I used JMP to make aluminum molds for making plastic molds for making hamburger patties. They are made of polyethylene. One is for round patties and the other is for square-ish patties. I have made hundreds of hamburger patties from just two of these forms.



The adventure will continue with the new Pelles C version of JMP!
#13
Projects developed with Pelles C / JMP: Jerbil Machine Programmer
Last post by PabloMack - July 31, 2026, 04:27:58 PM
In the mid 2010's I seriously started thinking about designing and building a new computer hardware platform as an alternative to the PC (IBM and Mac included) as well as programmable lighting for use with compositing live action green screen video with computer animated graphics. I wanted to be able to mass produce plastic parts and even make custom metal parts. But plastic injection molds are expensive, so I decided that I needed to make my own molds. That meant I needed to get into machine tools. So I forked out the cash for a Sherline Mill and Lathe. No way was I going to get into manual machine tools. They had to be computer controlled or I was not going to be able to automate manufacturing. So I put together an inexpensive control system based on the Arduino and some free firmware called GRBL. It worked out really well. The GRBL controller only turns individual movement paths into stepper motor sequences. It takes many of these to do a whole machining job. I didn't like the CAD work flow in that you designed the whole 3D object and had to throw the whole sequence at the controller with what is called a G-Code sender. Just the sender alone doesn't tell you where you are in the sequence without some sophisticated 3D monitoring software. Instead, I wanted something more like a spreadsheet like control program within which you could write and test your machine's movements. So I wrote my own and I call it JMP which stands for Jerbil Machine Programmer. To this very date, I have been using a program based on a pretty old environment using Watcom's C compiler that I have been using since around 2010 or soon after. Both the SW tools and the targets produced by it run in 32-bit mode. Now I have decided that I am going to purchase a more robust mill from Taig Tools in Arizona. I am now planning to write this newest version of JMP in Pelles C. I will keep you posted on my progress. I just created the project in Pelles C this morning.
#14
General discussion / Re: Top Programming languages ...
Last post by MrBcx - July 31, 2026, 05:24:40 AM
Quote from: TimoVJL on July 31, 2026, 02:13:12 AMhttps://www.tiobe.com/tiobe-index/

QuoteOver the past 25 years, we have received both positive and negative feedback. Much of that feedback has helped shape the TIOBE Index into what it is today. One recurring and valid observation is that the index measures the popularity of programming languages, but it does not tell you which language is the best choice for a particular project or application.

To address this, we are introducing something new: the Programming Language Flowchart. This practical guide is designed to help developers select the most suitable programming language for their specific use case. It will be published on the TIOBE website next week.


For many years, I've held TIOBE index in high regard for reporting "...the popularity of programming languages", something which I personally find more interesting and useful.
#16
General discussion / Re: Top Programming languages ...
Last post by PabloMack - July 31, 2026, 12:32:36 AM
Python and JavaScript produce disposable code that isn't used for very long and each instance isn't used by very many people. What is Arduino doing on the list?
#17
Work in progress / Re: Code Density Comparison of...
Last post by PabloMack - July 28, 2026, 01:48:35 AM
Quote from: John Z on July 25, 2026, 09:04:34 AMSo - what actual hardware or hardware emulator is running your ϕEngine?
Using ARM?, QEMU,  custom FPGA?

John Z

I am writing a simulator I call ϕSim that runs on Windows/x86. It's main purpose is to prove out the logic of how it works. I have been using OpenWatcom for writing the SW tool chain but it only runs in 32-bit x86 mode. That's why I have been evaluating PellesC for 64-bit execution. I am also evaluating TileLink for writing a soft core to run as a standalone SOC. Of course I will have to prove it out on an FPGA. So far I am impressed with TL as it is open source and has growing support. It is the primary environment for RISC-V. But TL is not married to RISC-V and I think it could serve ϕEngine quite well.

ϕEngine's instruction set was developed and is maintained by a program I started writing in 2018. It generates C source code for the assembler (ϕAsm) as well as for ϕSim. I plan to generate Verilog source code to define the soft core and SOC. This is the natural place to do it since it has direct access to the data structures that define ϕEngine's instruction set.
#18
General discussion / Re: Top Programming languages ...
Last post by PabloMack - July 28, 2026, 01:29:11 AM
Quote from: Pelle on October 17, 2023, 11:20:33 PMSorry, I don't know enough about Rust to have a strong opinion. Over the years I have seen enough programming languages being described as "the next big thing" only to disappear after a few years. By now I'm old and skeptical enough to wait a while for things to clear up...

In my opinion there are better ways to make "most" uses of arrays and pointers safer than the way Rust does it. Purportedly, the compilation process can be horribly compute-intensive with all of the checking that has to happen. Then the build process seems to be radically different from that in the C world. I think the best way to make arrays and pointers safer is to add higher-level features to the language that will hide their use so that programmers don't have to deal with raw pointers any more. Seems that Rust tries do manage what is done with raw pointers using the Borrow Checker. Not the way to go in my opinion.
#19
Assembly discussions / Extracting binary data with Po...
Last post by Vortex - July 26, 2026, 10:06:02 AM
Simple method to extract binary executable data with Poasm. The procedure WriteFileToDisc saves the code between the two labels, MsgBox and start. This method is useful to call assembly code from languages like RapidQ Basic with no inline assembly support.

.386
.model flat,stdcall
option casemap:none

ExitProcess PROTO :DWORD

WriteFileToDisc PROTO :DWORD,:DWORD,:DWORD

.data

fname       db 'MsgBox.bin',0

.code

MsgBox:

    call    delta

delta:

    pop     edx
    mov     eax,OFFSET delta
    sub     edx,eax
    lea     eax,[edx+capt]
    lea     ecx,[edx+msg]

;   call    MessageBox

    push    0
    push    eax
    push    ecx
    push    0
    call    DWORD PTR [esp+20]
   
    retn    16

capt    db 'Hello',0
msg     db 'This is a test.',0

start:

ProcLen EQU start-MsgBox

    invoke  WriteFileToDisc,ADDR fname,\
            MsgBox,ProcLen
           
    invoke  ExitProcess,0

END start

Running the executable, it creates the file MsgBox.bin

RapidQ Basic code calling the embedded binary data :

$APPTYPE GUI

DIM s AS STRING

DIM pMessageBox as INTEGER

DECLARE FUNCTION CallWindowProc LIB "user32" ALIAS "CallWindowProcA" _
                 (Proc AS LONG, p1 AS LONG, p2 AS LONG, p3 AS LONG, _
                 p4 AS LONG) AS LONG

DECLARE FUNCTION GetProcAddress LIB "kernel32" ALIAS "GetProcAddress" (hModule AS LONG, lpProcName AS STRING) AS LONG
DECLARE FUNCTION LoadLibrary LIB "kernel32" ALIAS "LoadLibraryA" (lpFileName AS STRING) AS LONG

DefInt ptrMsgBox

FUNCTION MsgBox1(pointer As Long) As Long
    Result=CallWindowProc(ptrMsgBox,pointer,0,0,0)
END FUNCTION

$RESOURCE ResourceName AS "MsgBox.bin"

DIM Mem AS QMEMORYSTREAM

Mem.ExtractRes(Resource(0))
Mem.Position=0
s=Mem.ReadBinStr(Mem.Size)

ptrMsgBox=varptr(s)

pMessageBox = GetProcAddress(LoadLibrary("user32.dll"), "MessageBoxA")

MsgBox1(pMessageBox)

Compiling the RapidQ code :

RC.EXE -LC:\Rapidq\lib MBox.bas
#20
Work in progress / Re: Code Density Comparison of...
Last post by John Z - July 25, 2026, 09:04:34 AM
So - what actual hardware or hardware emulator is running your ϕEngine?
Using ARM?, QEMU,  custom FPGA?

John Z