+1dwelch67 wrote: ↑Wed Jan 10, 2018 3:36 amStanding on my soap box the biggest problem we have is not enough folks care about how things work, not enough actual/real bare metal programmers (thank the gods for this forum) not enough assembly programmers not enough folks that can understand how a compiler works or how to manipulate it to change the output.
The world will literally come to a screeching halt if the next generation doesnt pick up where the old timers left off. Including having strong assembly language and instruction set architecture knowledge to be able to write an application. (soapbox off).
Last time I checked, gcc is written in C. I doubt ANY high level language compilers have ANY assembler in them as it would tie them to that archetecture. AFAIK they are mostly written in C for good performance and maximum portability.
Thread title is "What can be realistically programmed in assembler today?" History lessons are not really what we are talking about..
Nil if you write your program in a HLL. In assembler, write it for the v6 and it should mostly work on a v8, obviously ARMv8 has new instructions that the older CPU's don't have. I prefer 64-bit mode which provides a decent baseline, for example NEON is guaranteed always present (and its a much better version), as of course are basic things like integer division and 31 registers. Aarch64 is more similar to other modern processors, so what you learn will carry over.
Christopher Strachey (NATO) once famously said "you can push a pea up a mountain with your nose, but ...". Writing a large program in assembler is a bit like that nowadays I think.I know only Java, Free Pascal and pondering about dive into ASM pool... FOR FUNZIES, mostly, on PI of course.
GCC is in C/C++ but Microsoft compiler was in assembler up until Visual Studio 2015 it was covered in a writeup
There is actually very little problem with backward compatibility it takes a handful of macros and function pointers, it's dead simple to detect the Pi model and adjust memory pools for it. My boot code has been doing it since I first started working with the Pi.
Code: Select all
/* I borrowed this trick from Ultibo because ARM6 code running on an ARM7/8 needs this opcode */ /* The ARM6 compiler does not know these instructions so it is a way to get needed opcode here */ /* So our ARM6 code can drop an arm7 or arm8 out of HYP mode and run on an ARM7/8. */ /* Native ARM7/8 compilers already understand the OPCODE but do not mind it this way either */ .long 0xE12EF30E ;@ "msr ELR_hyp, lr" Set the address to ELR_hyp .long 0xE160006E ;@ "eret" Elevated return which will exit at .NotInHypMode in SVC_MODE
I can't see any explicit mention of when it stopped being written in assembler in that article.LdB wrote: ↑Thu Jan 11, 2018 3:51 amGCC is in C/C++ but Microsoft compiler was in assembler up until Visual Studio 2015 it was covered in a writeup
https://blogs.msdn.microsoft.com/vcblog ... -compiler/
Good point ! But the early versions probably were in assembler, unless they cross compiled from a UNIX compiler of some sort onto x86.
That everything could be written in assembler doesn't mean it's realistic or practical to do so. Likewise that most compilers generate assembler code is neither here nor there; those compilers are used because they make it easier to create code and applications.
Even then I would use C. With your experience and considerable effort, you might possibly match GCC for a small program, but the compiler will never get tired or bored and will continue generating efficient code for millions and millions of lines - no human can do that.
Purely for fun and education perhaps.There would have to be a very compelling argument to use assembler for that.
ARMv8 (Pi3 and new Pi2) is the latest and is current (and can do A64 which is great).
Your over thinking it GCC is effectively the same you take the high level language spit assembler macro blocks and then run it thru the assembler which microsoft called MASM
So the history of it was built around assembler NOT C/C++ or any other languageWith the 6.15 release in 2000, Microsoft discontinued support for MASM as a separate product, instead subsuming it into the Visual Studio toolset.
Originally, the compiler was a 16-bit DOS executable compiled by Turbo Pascal. After two years, the compiler was able to compile itself and became a 32-bit executable.