Skip to content

simplify battery percentage calculation#658

Open
nschloe wants to merge 1 commit intopvvx:masterfrom
nschloe:simplify-battery-code
Open

simplify battery percentage calculation#658
nschloe wants to merge 1 commit intopvvx:masterfrom
nschloe:simplify-battery-code

Conversation

@nschloe
Copy link
Copy Markdown

@nschloe nschloe commented Jun 5, 2025

No description provided.

@pvvx
Copy link
Copy Markdown
Owner

pvvx commented Jun 5, 2025

https://en.wikipedia.org/wiki/Structured_programming -> Early exit

One "return" at the end of the function or three?
Structured programming says that there should be one "return".
It's a matter of religion, and in this case, when the compiler optimizes the code, the result does not change.
But it remains possible to add or use a fragment of this code. With multiple "returns" this is impossible.
My version is written taking into account that the compiler optimizes the code poorly. That is, the function code is optimized for performance (and size) already in the initial description, regardless of the compiler - Shows how this will be executed in processor codes.

_attribute_ram_code_
u8 get_battery_level(u16 battery_mv) {
	u8 battery_level = 0;
	if (battery_mv < MAX_VBAT_MV) {
		if (battery_mv > MIN_VBAT_MV) {
			battery_level = (battery_mv - MIN_VBAT_MV) /
				((MAX_VBAT_MV - MIN_VBAT_MV) / 100);
		}
	} else
		battery_level = 100;
	return battery_level;
}

_attribute_ram_code_
u8 get1_battery_level(u16 battery_mv) {
	if (battery_mv >= MAX_VBAT_MV) 
		return 100;
	if (battery_mv <= MIN_VBAT_MV) 
		return 0;
	return (battery_mv - MIN_VBAT_MV) / ((MAX_VBAT_MV - MIN_VBAT_MV) / 100);
}

In the end we still get one "return" (and the execution algorithm, as described in my version):

00001d28 <get_battery_level>:
get_battery_level():
    1d28:	f403      	tshftls	r3, r0, #16
    1d2a:	fc1b      	tshftrs	r3, r3, #16
    1d2c:	a064      	tmovs	r0, #100	; 0x64
    1d2e:	0a06      	tloadr	r2, [pc, #24]	; (1d48 <get_battery_level+0x20>)
    1d30:	0293      	tcmp	r3, r2
    1d32:	c807      	tjhi.n	1d44 <get_battery_level+0x1c>
    1d34:	a000      	tmovs	r0, #0
    1d36:	0a05      	tloadr	r2, [pc, #20]	; (1d4c <get_battery_level+0x24>)
    1d38:	0293      	tcmp	r3, r2
    1d3a:	c903      	tjls.n	1d44 <get_battery_level+0x1c>
    1d3c:	0a04      	tloadr	r2, [pc, #16]	; (1d50 <get_battery_level+0x28>)
    1d3e:	e898      	tadds	r0, r3, r2
    1d40:	f540      	tshftls	r0, r0, #21
    1d42:	fe00      	tshftrs	r0, r0, #24
    1d44:	0770      	tjex	lr
    1d46:	46c0      	tnop			; (mov r8, r8)
    1d48:	00000bb7 	undefined instruction 0x00000bb7
    1d4c:	00000898 	tmuleq	r0, r8, r8
    1d50:	fffff768 	undefined instruction 0xfffff768

00001d54 <get1_battery_level>:
get1_battery_level():
    1d54:	f403      	tshftls	r3, r0, #16
    1d56:	fc1b      	tshftrs	r3, r3, #16
    1d58:	a064      	tmovs	r0, #100	; 0x64
    1d5a:	0a06      	tloadr	r2, [pc, #24]	; (1d74 <get1_battery_level+0x20>)
    1d5c:	0293      	tcmp	r3, r2
    1d5e:	c807      	tjhi.n	1d70 <get1_battery_level+0x1c>
    1d60:	a000      	tmovs	r0, #0
    1d62:	0a05      	tloadr	r2, [pc, #20]	; (1d78 <get1_battery_level+0x24>)
    1d64:	0293      	tcmp	r3, r2
    1d66:	c903      	tjls.n	1d70 <get1_battery_level+0x1c>
    1d68:	0a04      	tloadr	r2, [pc, #16]	; (1d7c <get1_battery_level+0x28>)
    1d6a:	e898      	tadds	r0, r3, r2
    1d6c:	f540      	tshftls	r0, r0, #21
    1d6e:	fe00      	tshftrs	r0, r0, #24
    1d70:	0770      	tjex	lr
    1d72:	46c0      	tnop			; (mov r8, r8)
    1d74:	00000bb7 	undefined instruction 0x00000bb7
    1d78:	00000898 	tmuleq	r0, r8, r8
    1d7c:	fffff768 	undefined instruction 0xfffff768

ps: Creating human-readable code in the age of AI is sheer stupidity. A person describes a task in sentences based on images, not machine codes. No one manually climbs into the matrix of AI coefficients anymore. As a result, all the variants of programming languages ​​created for humans are not needed, as are the programmers themselves, busy translating the task into these outdated languages.
I stick to the option of writing the code as it will look in the processor codes. So far, artificial intelligence has not optimized the ALU logic according to its internal ideas. And such optimization is just around the corner... A person will soon have nothing to do in coding - translating a task into obsolete programming languages.

@nschloe
Copy link
Copy Markdown
Author

nschloe commented Jun 6, 2025

Yeah the resulting machine code is the same, I thought it was just lots more readable. For example, the case < MIN is only covered implicitly by the 0 initialization.

If you prefer assigning a variable to have only one return, you could do something like

// 2200..3000 mv - 0..100%
_attribute_ram_code_
u8 get_battery_level(u16 battery_mv) {
    u8 out;
    if (battery_mv >= MAX_VBAT_MV)  {
      out = 100;
    } else if (battery_mv <= MIN_VBAT_MV) {
      out = 0;
    } else {
      // Keep the /100 in the denominator to avoid an u16 overflow
      out = (battery_mv - MIN_VBAT_MV) / ((MAX_VBAT_MV - MIN_VBAT_MV) / 100);
    }
    return out;
}

Anyway, feel free to close if you don't like it.

@zarelit
Copy link
Copy Markdown

zarelit commented Jul 7, 2025

FWIW I feel @nschloe is clearer and does not suffer from a steady marching on the right, which makes it harder to read.

Of course if the point is to make code better for the machine we would just write assembly or generate it from high-level specifications.

Structured programming says that there should be one "return".

Wikipedia actually says for most of that section that the early exit exception is useful, except when you have to do rollbacks, and is case there is nothing to undo on return.
Structured programming has nothing to do with ALU or circuitry which, by itself, might not even be synchronous or digital, for that matter. Structured programming is just a way to express algorithms in a way that conveniently maps onto a Turing-like machine.

ps: Creating human-readable code in the age of AI is sheer stupidity

This is the most depressing statement I've read in a while about programming

A person will soon have nothing to do in coding

This was the slogan of COBOL, Visual Basic, "no code" tools... yet we're still discussing on GitHub

@pvvx
Copy link
Copy Markdown
Owner

pvvx commented Jul 7, 2025

FWIW I feel @nschloe is clearer and does not suffer from a steady marching on the right, which makes it harder to read.

Modern computers are equipped with completely different monitors, not entry-level CRT-based ones with a display of up to 80 characters per line.

Some languages ​​use a top-to-bottom, columnar writing order.
Ultimately, it's a matter of your habits and you shouldn't force it on everyone.

ps: Creating human-readable code in the age of AI is sheer stupidity

This is the most depressing statement I've read in a while about programming

A person will soon have nothing to do in coding

This was the slogan of COBOL, Visual Basic, "no code" tools... yet we're still discussing on GitHub

You are talking about programming languages ​​created for humans, not for machines. They didn’t take root because they had the same views as you - To force everyone into a framework and limit freedom.
And what does this have to do with the AI-optimized processor and the internal representation of the AI ​​code for that machine?

PS: Who's stopping you from creating your own repository and writing code there the way you like?
The world is beautiful in its diversity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants