* Gnat for ARM : are these bugs?
@ 2015-05-19 7:54 jan.de.kruyf
2015-05-19 8:42 ` jan.de.kruyf
2015-05-19 8:44 ` Egil H H
0 siblings, 2 replies; 3+ messages in thread
From: jan.de.kruyf @ 2015-05-19 7:54 UTC (permalink / raw)
Hallo,
I was doing some code patterns for a little Oberon compiler, as a diversion in my free time.
And 2 most extraorinary features popped up :
1. its seems to be illegal to to assign 2 ** 0 ( = 1) to a mod type.
2. on a illegal assignment like 2 ** 32 to a 32 bit mod type the answer is a big fat zero with no questions asked.
Does anybody have an explanation that I might have overlooked?
Thanks
j.
---
here is the relevant code and the assembler output from gcc
-- compiled with arm-eabi-gcc -S -mtune=cortex-m4 -mfloat-abi=hard patset.adb
procedure Patset is
type Set is mod 2**32;
N : Integer; -- stored at stackpointer + 4
S : Set; -- stored at stackpointer + 0
begin
S := 2 ** N;
end Patset;
----------------------------------------------------------
_ada_patset:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
push {r7, lr} -- procedure start
sub sp, sp, #8
add r7, sp, #0
ldr r3, [r7, #4] -- load 'N'
cmp r3, #0 -- if 0 then exception
bge .L2 -- else .L2
movw r0, #:lower16:.LC0 -- last chance handler set up
movt r0, #:upper16:.LC0
mov r1, #8
bl __gnat_last_chance_handler
.L2:
ldr r3, [r7, #4] -- load 'N'
cmp r3, #31 -- if N > 31 then .L3
bgt .L3
ldr r3, [r7, #4] -- else normal processing
mov r2, #1
lsl r3, r2, r3
b .L4
.L3:
mov r3, #0 -- on error my set becomes {}
.L4:
str r3, [r7, #0]
Nop -- procedure end game
add r7, r7, #8
mov sp, r7
pop {r7, pc}
--------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Gnat for ARM : are these bugs?
2015-05-19 7:54 Gnat for ARM : are these bugs? jan.de.kruyf
@ 2015-05-19 8:42 ` jan.de.kruyf
2015-05-19 8:44 ` Egil H H
1 sibling, 0 replies; 3+ messages in thread
From: jan.de.kruyf @ 2015-05-19 8:42 UTC (permalink / raw)
ok,
i was too much in a rush.
Reading the right books enlightened the issues.
Issue 1 is explained by correctly reading the assembly: BGE means signed 'equal or greater'.
issue 2 follows from the definition of a mod type. it will automatically roll over when the result of an operation is too big for the type to contain.
In any case: All, thanks for listening.
j.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Gnat for ARM : are these bugs?
2015-05-19 7:54 Gnat for ARM : are these bugs? jan.de.kruyf
2015-05-19 8:42 ` jan.de.kruyf
@ 2015-05-19 8:44 ` Egil H H
1 sibling, 0 replies; 3+ messages in thread
From: Egil H H @ 2015-05-19 8:44 UTC (permalink / raw)
On Tuesday, May 19, 2015 at 9:54:32 AM UTC+2, jan.de...@gmail.com wrote:
>
> 1. its seems to be illegal to to assign 2 ** 0 ( = 1) to a mod type.
Works fine for me (on x86, though).
No expert on ARM-assembly but I read bge as greater or equal, so:
cmp r3, #0 -- if N<0 then exception
bge .L2 -- else .L2
>
> 2. on a illegal assignment like 2 ** 32 to a 32 bit mod type the answer is a big fat zero with no questions asked.
All operations on modular types are performed modulo the modulus, ** is no exception from that rule.
If you want it to fail, try instead to assign a named number:
bar : constant := 2**N;
begin
S := bar;
--
~egilhh
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-19 8:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-19 7:54 Gnat for ARM : are these bugs? jan.de.kruyf
2015-05-19 8:42 ` jan.de.kruyf
2015-05-19 8:44 ` Egil H H
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox