Everything Else

Oberon was interesting in that Xilinx actually had a version of reprogramable hardware that used Oberon as a Hardware Description Language. One could conceive of not just self-modifying code, but self-modifying hardware. I worked on some ideas that utilized this aspect to create self repairing logic systems. It also yielded some other interesting ideas in just massively reprogramable logic when considered of systems with 1,000s of such chips. In the end it just sort of died off... Too bad.

@vishnu, uunix, you guys could not be responded to safely. :-)

confirmed, the origin of the new language's name, and a far moon: names are linked !!!

Byte Magazine, 1993
as the triumphal march of C precedes and language "inertia" becomes heavier by month, the prospects for introducing a new-general-purpose programming language must seem pretty slim. However, one candidate deserves to be taken very seriously: Oberon, Niklaus Wirth's successor to Modula/2. The Oberon language was born in 1988 as Voyager was flaying past Uranus's moon of the same name. The superb precision of Voyager's navigation inspired Wirth to make this linguistic tribute.

skywriter wrote: Oberon was interesting in that Xilinx actually had a version of reprogramable hardware that used Oberon as a Hardware Description Language)

are you talking about "Lola" ?
Lola meta-compiles into Verilog

Yeah LOLA, and Spartan-4! Very cool! Stil, it wasl too expensive for one person.

sooner or later I will put Oberon on fpga, in order to have fun-redemption

I feared that the evil-C would attempt to seize my dimension, I decided to strike first
and I resurrected the following board, to be programmed in 80s assembly



Now, I would attempt to square a five-digit number in assembly - and apparently I can -
while unfortunately most calculators and MPUs programmed in C cannot X__________X

You hardware guys are weird...

ivelegacy wrote: sooner or later I will put Oberon on fpga, in order to have fun-redemption

I feared that the evil-C would attempt to seize my dimension, I decided to strike first
and I resurrected the following board, to be programmed in 80s assembly :D :D :D

Now, I would attempt to square a five-digit number in assembly - and apparently I can -
while unfortunately most calculators and MPUs programmed in C cannot X__________X

While I learned a lot has changed in the field of calculator design researching my response to this post, none of it brought any weight to the comment

Now, I would attempt to square a five-digit number in assembly - and apparently I can -
while unfortunately most calculators and MPUs programmed in C cannot X__________X

perhaps it lies in ones interpretation of "cannot X__________X"?

vishnu wrote: You hardware guys are weird... :lol:

we're the ones that makes software guys even weirder!! :-)

skywriter wrote:

vishnu wrote: You hardware guys are weird...

we're the ones that makes software guys even weirder!!

For funzies I just did a regexp for "weird" in the mozilla codebase and got 571 hits in 400 files...

look for "bozon" :-)

skywriter wrote: perhaps it lies in ones interpretation of "cannot X__________X"?

while unfortunately most calculators and MPUs, programmed in C, cannot

I had forgotten a few comma

I meant, funny things which happen when your C compiler is not smart enough(2) to support big numbers without involving voodoo magic flags, while in assembly you can joke tricks with ALU and overflow, and carry, without the need to take your daily pill against headache (1) due to too much mind contortion

as far as I have seen from youtube and people feedback, it seems that Modula/2 and Oberon give less headache than the C language, especially if the target is a RISC machine designed to be the simplest you can imagine, and specifically designed to support Oberon: no headaches, fun-redemption

skywriter wrote: X__________X

and in this (1) case that is face I have, my eyes are wide open like an "X"


(2) gcc on HC11 is not smart, it's silly, due to the fact that 68hc11 owns just the accumulator register (16 bit, composed by 2 sub registers, 8 bit each), so gcc plays its tricks with "soft registers", it uses the internal ram (68hc11E9 comes with 512byte, 68hc11K comes with 1Kbyte), but it's not so smart in such a purpose, especially when you recycle your software which comes with uint32_t.

C and C++ don't allow access to carry bits at all, which is inconvenient. There are some C compilers with extensions that allow for overflow to be trapped, in case the architecture detects overflow, which is not universal. ( http://clang.llvm.org/docs/LanguageExte ... c-builtins )
What most people do is use a pre-existing library like GMP with machine-dependent assembler files.

yes, but you have to integrate these libraries, and it's boring on 68hc11
also I had just 2Kbyte of space, including stack, heap, and code

porting clang to hc11 requires too effort

so, I implemented everything in assembly instead of cracking up with the need of headache pills because of the C language,
and more specifically because of the GNU HC11 branch.

note: machines like MIPS do not have the carry bit in its hardware design, and everything is handled in software

as motivation for new wicked plans, I believe that I'd better study, learn and master the ARINC 653 Specification

RISC family, Understanding stacks and registers in the Sparc architecture